Gerenciamento de arranjos

Vamos falar sobre o gerenciamento de arranjos. Por que isso é de repente? Sim, porque nós da TeamLead Conf adoramos discutir dores e problemas, mas não esquecemos as soluções. Certamente todo mundo tem problemas associados a acordos de trabalho.

"Os arranjos não estão sendo implementados", Capitão Evidence

A dor com eles, em primeiro lugar, é que os acordos não são cumpridos - todo mundo sabe disso, até mesmo nosso amigo, capitão Evidence, que nos ajudará neste artigo.

Parece, qual é o problema? Muitas coisas não estão indo como gostaríamos. Por exemplo, os dias ensolarados nem sempre são em São Petersburgo. Então, o que, a cidade fica, as pessoas vêm, adoram. O que não acontece da maneira que queremos nem sempre é um problema realmente sério.

No entanto, neste caso, Stas Mikhalsky afirma que o problema é mais do que sério. De acordo com o corte, entenderemos o que leva ao fato de o contrato não estar sendo implementado e como, no final, torná-los indestrutíveis.


Sobre o palestrante: Stas Mikhalsky atua no desenvolvimento web desde 1998. Ele passou de um programador júnior de Perl para um diretor de desenvolvimento da Biglion. Ele participou do desenvolvimento de várias dezenas de projetos com alta participação e forneceu seu apoio.

Por que isso é um problema

Negócios e liderança de nossas equipes e de nós, como líderes de equipe, aguardamos o resultado. A conclusão de uma tarefa no prazo pode não levar a um resultado, mas esta é uma história diferente.

Trabalho e resultado são duas coisas diferentes, mas vamos falar sobre isso outra vez.

O resultado é o resultado do trabalho - a conclusão de tarefas, projetos, subprojetos. São possíveis divisões diferentes, mas de uma forma ou de outra, o trabalho consiste em algumas ações, cada uma das quais é realmente uma conseqüência de um acordo.

Parece - tudo está claro: quando não realizamos ações, quebramos acordos.

Vamos considerar exemplos padrão. A conformidade com o padrão de estilo de código é um contrato com um desenvolvedor específico. Nem toda a equipe responde com uma voz: "Sim, Kaa, vamos respeitar o estilo do código", mas todo mundo diz pessoalmente que ele promete cumpri-lo. O lançamento do lançamento na sexta ou na segunda-feira também é um acordo. O que quer que façamos, alguém nos perguntou sobre isso, ou nós mesmos decidimos que isso é necessário para algo, se um resultado é esperado de nós, então essa é uma ação tomada como parte de um acordo.

- Se nós mesmos decidirmos que eles esperam isso de nós - isso é um acordo?
- Sim, um acordo consigo mesmo, mas este é um caso especial.

Agora, o mais interessante é o oposto: um acordo com falha = ação com falha.

Ou seja, nenhum contrato será interrompido se a ação não for executada, mas a ação que não for executada é o resultado de um contrato com falha . Não concordamos, porque não concordamos, realmente não queríamos ou algo mais. No centro está o problema do acordo. Assim, temos uma imagem em que um acordo fracassado leva a uma ação não realizada, que, é claro, afeta a qualidade do trabalho e, finalmente, a falta de resultado.

Quero transmitir a você a ideia de que desenvolvedores, back-end, front-end, testadores, líderes de equipe, gerentes de desenvolvimento são algumas das funções e funções nas quais fazemos algo. Mas se você parecer um pouco mais alto, todo o nosso trabalho é a conclusão de acordos e sua implementação. É como o UDP - tudo o resto está envolvido em um acordo. Se não soubermos concluir os contratos corretamente, podemos ser excelentes front-end ou back-end, escrever um código excelente, mas não haverá resultado.

Pelo contrário, se aprendermos a criar os arranjos certos, então:

• economize muito tempo;
• reduzir significativamente as despesas gerais para todos os controles, desmontagens, etc.;
• nós podemos realmente fazer nosso trabalho.

O que fazer

"Certifique-se de que os arranjos sejam implementados"

Capitão Evidence

Isso está claro para todos, mesmo o capitão da Evidence, você só precisa garantir que os acordos sejam implementados e não precisa fazê-lo para que não sejam implementados.

O modelo clássico de como isso pode ser alcançado:

1. Entenda os motivos.
   
2. Identifique e tome medidas para resolver essas causas e alterar o resultado.
   

Vamos falar um pouco mais detalhadamente. Existem três atores:

1. Um acordo para lidar.
   
2. Interrupção que acontece com um acordo.
   
3. As razões do fracasso.
   

Se você observar tudo isso de todos os lados, provavelmente poderá entender qual é o problema e como melhorar a situação. Espero que a situação exija intervenção, todos concordam.

O que é um acordo?

O arranjo consiste em duas partes: compromisso e promessa. A diferença entre eles é que um compromisso é feito, uma promessa é feita .

Uma promessa é uma miudeza, é uma mensagem para alguém que assumi um compromisso. Em princípio, ele ainda não pode ser fornecido, pois é apenas uma mensagem de notificação. Mas eu assumo esta obrigação. Portanto, um compromisso sem promessa é muito melhor do que uma promessa sem compromisso. Encontramos o último com bastante frequência.

Honestamente, parece-me que todo o problema é que nem todos (e nós também) e nem sempre, quando concluímos acordos, pensam em obrigações. Nem sempre tomamos decisões conscientemente e realmente entendemos com o que essa promessa nos ameaça. Apenas assentimos: "Sim, sim", estamos saindo, mas não assumimos nossa obrigação conosco - e esse é um grande problema.

De fato, ainda é muito mais complicado, porque os arranjos são de tipos diferentes:

• Como parte de suas responsabilidades imediatas , por exemplo, escreva comentários em código, conclua a liberação para o ambiente.
• Fora do trabalho principal , por exemplo, para monitorar a relevância das informações no wiki, leia um livro, vá para os cursos.
• Altere o comportamento , por exemplo, comece a trabalhar em uma determinada hora ou acompanhe o tempo gasto na tarefa.

Estes são acordos completamente diferentes, as pessoas os tratam de maneira diferente e você precisa trabalhar com eles de maneiras completamente diferentes.

Por via de regra, o escopo do trabalho principal vai além de questões que, em certo sentido, são mais importantes, ao que me parece, do que o atual nível de codificação do desenvolvedor, porque ele pode ser transformado através delas. Se uma pessoa sabe aprender, isso é completamente diferente do que se apenas aprendesse a codificar rapidamente e sem erros em 10 anos. Às vezes, concordar com um desenvolvedor para ler um livro pode ser muito mais difícil do que exigir que ele documente o código. Mas é ainda mais divertido quando se trata de mudar o comportamento.

Um exemplo clássico, quando não era importante ir para 10 ou 12, porque, se houver, você pode atrasá-lo e finalizá-lo, mas agora você precisa estar no local de trabalho o mais tardar às 11, porque processa e assim por diante. Se uma pessoa simplesmente concorda: "Sim, bem, chegarei às 11 amanhã" - isso não é uma mudança de comportamento, mas uma façanha. Se, para isso, for necessário, talvez, reconstruir a vida - ir dormir um pouco mais cedo ou não jogar Warcraft, significa que a própria pessoa deve mudar. Isso é difícil e, mais importante, incontrolável, como qualquer projeto.

Portanto, é muito importante entender de que tipo de acordo estamos falando. O grau de elaboração depende do tipo de acordo que estamos tentando concluir.

Interrupções

Não apenas os acordos quebram, eles quebram, em primeiro lugar, inesperadamente e em segundo lugar, na linha de chegada - porque é muito mais divertido. Embora isso seja inesperado, geralmente é em um ponto previsível. Eu sempre sei quando o acordo será quebrado.

Agora estamos trabalhando em equipes, a era dos solteiros e dos computadores de garagem já passou. Temos uma equipe, processos e todos os arranjos em uma cadeia. Se desmoronar, tudo desmoronará. Se uma pessoa simplesmente não leu o livro, então, em princípio, nada vai dar errado ou quebrar, mas em um ano sua equipe de repente não estará melhor do que agora. Para mim, esse arquivo é muito maior que duas horas de falha de todos os sistemas.

As interrupções também são diferentes.

O fracasso é meu tipo de fracasso favorito, mais honesto e inofensivo. Nós concordamos, a pessoa prometeu e não - isso acontece. Este é um colapso simples, porque tudo está claro com ele.

Existem opções mais desagradáveis, como execução formal.

A execução formal é quando, na sexta-feira à noite, o desenvolvedor (para uma amostra de cerveja em busca de inspiração) distribui 40 horas de tempo de trabalho pelas tarefas que realizou em uma semana. De fato, a pessoa que fez esse acordo com você não recebe nada no momento. Se o registro de tempo não for necessário para pressionar todos, mas para entender estatisticamente quanto tempo diferentes tipos de tarefas levam, qual é o erro médio etc., sua execução arruina toda a iniciativa. Não haverá estatísticas, porque os dados são retirados da cabeça. Como resultado, o acordo não foi cumprido, embora algo pareça ter sido feito e tudo esteja bem.

O problema é que nem sempre registramos o cumprimento formal como um acordo quebrado. Especialmente se você não estiver muito interessado. Por exemplo, eu sou um líder de equipe, o diretor me disse de cima: "Escreva um relógio, caso contrário eu punirei todos!" Eu vim para a equipe e transmiti que preciso gravar o relógio, caso contrário todos serão punidos. Como resultado, o relógio foi gravado de alguma forma, estou satisfeito - tenho algo para mostrar ao diretor. Eu próprio participo dessa sabotagem e, para mim, a execução formal é importante. Para o provedor de tarefas, não é aceitável.

A substituição é um pouco diferente da implementação formal do formulário, mas na verdade é a mesma tentativa de violar o contrato. Em vez da visibilidade da tarefa concluída, uma substituição é criada. Usando o exemplo do registro de horas, soa algo como isto: “Para registrar o tempo de cada tarefa, preciso de 5 minutos. No total, são duas horas por semana. Oh, bem, ele. Fiz uma tarefa que não pretendia em 4 horas. Mas fiz mais do que prometi, nem que não penhorasse o tempo.

Esta é uma tentativa de fornecer algo para você ficar para trás com o cheque, mas na verdade também é um colapso. O problema é que, como regra, temos várias outras coisas, o tempo não garantido não é a pior coisa. Nós nos desculpamos.

Repito: um acordo pendente é um trabalho negativo, um resultado negativo.

Como sobreviver em um mundo de arranjos não realizados?

Você pode simplesmente lembrar : “Você se lembra que registramos o relógio?”. Quando se trata de mudar o comportamento, um lembrete é um bom esboço. Os cartazes de enforcamento mais astutos que apóiam o modelo de comportamento: “Tempo prometido - salvou o castor!” De fato, simplesmente lembramos que houve um acordo, sem verificar seu status no momento.

Você pode ser um pouco mais persistente e perguntar como o contrato é implementado, se a pessoa já fez alguma coisa. Isso difere de um lembrete, pois força você a dar algum tipo de resposta articulada. Mas você coloca a pessoa antes da escolha: mentir ou não mentir. A resposta, a propósito, não é óbvia para todos. Em certo sentido, você está empurrando uma pessoa para o mal. Perguntar é um tipo de controle latente - parece ser solicitado, mas não verificado. O homem mentiu, mas deixamos isso em sua consciência.

Você pode verificar :

• por resultado;
• passo a passo;
• na dinâmica.

Verificação pelo resultado que já discutimos. A questão é o que fazer se o resultado for insatisfatório, mas retornaremos a isso mais tarde.

Por etapas e por dinâmica, é possível verificar o cumprimento de um contrato dentro e fora do trabalho. Por exemplo, convencemos uma pessoa a preencher uma base de conhecimento, esboçamos um plano com ela e seguimos esse plano - isso ainda se foi. Mas e a mudança de comportamento? Uma pessoa registra o tempo ou não registra; ou chega a tempo ou não. É ridículo rastrear essa transformação por etapas e dinâmicas - hoje está meia hora atrasado, amanhã 25 minutos, depois de amanhã 20.

O maior problema de validação é que isso nem sempre é possível. Dado que os acordos são feitos o tempo todo e com muitas pessoas, isso também exige muito trabalho .

Existe um modelo de gerenciamento no qual quase todo o tempo que um gerente gasta no controle de execução de tarefas, mas não funciona bem em TI. Sim, e este é o século passado. Espero que essa abordagem de gerenciamento um dia morra, como o último dinossauro.

Em vez de controlar, vamos entender melhor por que o colapso realmente ocorre - por que a pessoa que nos fez a promessa não a cumpriu.

Razões para a desagregação

Esta é provavelmente uma lista incompleta, mas aqui estão os exemplos mais impressionantes:

• Consentimento irracional. Uma pessoa concorda, porque é embaraçoso recusar: você é o líder ou apenas uma pessoa respeitada, ou deseja sinceramente ajudá-lo, gosta de você ou não gosta de recusar.
• Erro na avaliação. Uma pessoa pode pensar, concordar, mas cometer um erro na avaliação. Então ele virá e dirá: "Sim, prometi, mas o trabalho foi o dobro do que eu esperava".
• Mudança de prioridades: "Eu quase terminei, mas Vasya veio, ele tem um problema ainda mais importante, então me desculpe."
• Falta de recursos - apenas não há tempo suficiente.
• Circunstâncias imprevistas - o piano caiu de cima.
• Sabotagem

Muitas vezes, por trás de todas as desculpas, está o rei dos acordos frustrados - a sabotagem . Quando não queremos fazer e não queremos admitir que não queremos, obtemos sabotagem. Beber 40 horas por semana para tarefas que usam o método poke é sabotagem. Vir ao trabalho às 9 da manhã e tomar café é uma sabotagem. É baseado em uma relutância em fazer, que não foi explicitamente expressa.

De fato, existem causas mais sistêmicas do colapso . O que dissemos está na superfície e, se você se aprofundar, há apenas três razões:

1. Tipo de acordo não levado em consideração.
   
2. O tipo de acordo não é acordado.
   
3. Uma promessa sem compromisso.
   

Além disso, o primeiro e o segundo parágrafo podem estar presentes simultaneamente. Quando concluímos um acordo, não pensamos no que concordamos. Muitas vezes isso soa assim:

- Egeu, faça isso!
- OK, eu faço! - e fugiu.

Isso pode ser feito quando falamos sobre o trabalho no trabalho, por exemplo, sobre como escrever um módulo: "Execute rapidamente a tarefa 28". Mas isso não pode ser feito quando se trata de se preparar para uma reunião em um comício, por exemplo. De uma maneira boa, para preparar um discurso em uma reunião, você precisa se sentar, resolver o problema, explicar o quão importante é etc. Mas muitas vezes fazemos tudo no mesmo ritmo : "Faça isso" ou "Olha, não se atrase mais!" - e correu .

Acontece que concordamos, tendo um entendimento diferente sobre o tipo de acordo. Um exemplo clássico é a documentação de código. Nos últimos tempos, talvez tudo tenha mudado, mas quando me deparei com isso, meus colegas e eu discutíamos constantemente se o desenvolvedor deveria documentar o código ou não. Como líder, acho que deveria. O desenvolvedor acredita que o código funciona bem, dada a carga de trabalho e as constantes mudanças nas prioridades.

Um conflito de entendimento do tipo de arranjo nem sempre é revelado. Muitas vezes acreditamos que esse acordo não precisa ser esclarecido, reforçado, porque tudo já está claro: basta pegar e fazer. O subordinado acredita que dele querem do alto o que ele não quer fazer. E então a sabotagem começa .

A situação mais popular, como eu disse, é uma promessa sem obrigações. Um acordo que deu origem a uma promessa, mas não deu origem a uma obrigação, não será cumprido por um motivo ou outro: o piano cairá, a pessoa ficará distraída, algo mais acontecerá.

De fato, em condições de complexidade dos sistemas, a intensidade das mudanças: quando todos escrevemos às pressas, rapidamente os lançamos, refazemos, ou seja, em condições de entropia, sempre pode acontecer algo que impedirá o cumprimento do contrato. Obviamente, você pode controlar todas as etapas, aproveitar todos os casos de cada um de seus subordinados, tentar ajudá-lo a implementar o nosso acordo. Mas, então, não haverá tempo suficiente para mais do que puxar tudo sozinho.

A única chance de o acordo ser cumprido é que uma pessoa queira cumpri-lo.

Se eu desejar cumprir o contrato, lidarei com todos os problemas que surgem: com os pianos em queda, com o erro de avaliar, etc.

Isso é semelhante à ideologia do Scrum, assim como a complexidade da tarefa não é completamente conhecida. Fazemos algumas suposições com um erro na experiência anterior, avaliamos e depois fazemos tudo para fechar o sprint. Reconhecemos que sim, será difícil, que possamos cometer um erro em algum lugar da avaliação, que o sistema possa nos surpreender, mas faremos isso apenas para resolver o problema.

Com o arranjo, o mesmo deve acontecer com os sprints no Scrum. Uma pessoa que se comprometeu a fazer algo apenas precisa fazê-lo. Tudo é simples!

Resumindo, o que foi dito sobre os motivos do fracasso do acordo:

• Uma promessa não é uma garantia.
• Controle é difícil.
• O fracasso é revelado sobre o fato.

Está claro o que precisa ser feito: basta criar acordos duradouros que sejam fáceis de gerenciar e finalmente ir para as Bahamas.

Capitão Evidence

Em outras palavras:

• Como está - o sistema agora se parece com isso: arranjos bastante frágeis e difíceis de gerenciar.
• Ser - deve ser: acordos indestrutíveis, cuja gestão é transparente e não trabalhosa.

Para uma situação padrão de análise de GAP, "Ser" é o objetivo final pelo qual estamos nos esforçando, mas não o fato de que alcançaremos. Mas devemos nos esforçar.

Resta descobrir o que é um acordo forte e como gerenciá-lo.

Acordo forte

Forte acordo - são obrigações reais concluídas com uma pessoa vinculativa. Isso é muito importante. Falamos sobre obrigações, como sobre alguns pacotes que precisam ser transferidos e agora falaremos um pouco sobre a transportadora desse pacote.

Arranjos feitos com uma pessoa opcional levam a inconsistências. Se você imaginar o trabalho na forma de um fluxo de acordos que são distribuídos em diferentes direções por pacotes, quando tentar concluir um contrato com uma pessoa opcional, esteja preparado para o fato de que, com uma probabilidade de 50%, você perderá tempo. Portanto, a primeira coisa a começar é aumentar o preço de uma palavra.

Preço da palavra

Cada um de seus colegas deve entender, idealmente, que o cumprimento das obrigações é o trabalho principal. Essa é a essência do seu trabalho. Código escrito, liberação deflacionada são derivados de obrigações cumpridas. Portanto, tento conversar com as pessoas especificamente sobre obrigações e que o problema não é que o código não esteja escrito ou que não haja resultado. Isso é uma consequência e muita dor. Mas a essência do problema é que, tendo assumido a obrigação, não encontramos uma maneira de cumpri-la.

Se você nunca falou sobre isso com as pessoas, então isso não é tão óbvio. Eu suspeito que, para falar sobre isso, talvez você precise primeiro percorrer a escada desde o início do relatório “resultado - trabalho - ação - acordo” e vice-versa. , , — , , , .

, , . - . , , 10 3. , — .

, .

, — . — , .

, , .

, — : « , ».

— , . , — . , .

— . , .

, , , .

, - — .

« » . , — . , , . , . , - . , , , , :

1. , .
   
2. , .
   

, , . — — , . - . , , , . , . .

, , «» :

• .
• .
• .

— , , , , , .

, . , .

, .

. , , : , , . , , , , . , — , - , . — .

, . — , «» . , — . - , . :

— , !
— .

-: «, , . 10:55. , ».

, , 5 — , , . , : , .

— — , .

?

, : ? 4 , , - :

1. ?
   
2. ?
   
3. , ?
   
4. , ?
   

. , . , .

: «, - , , , !» , , , .

, . . - , , , , .

« » . — . , , — .

« » , - , . , , — . , . , , .

, :

• .
• .
• , , — , .
• « » . , .

, Excel, : , , , . , .

?

, , , . , …

? ? — : — , — , — .

, «» , , . «» — - . « » , « ?» « ?»

…

Mas a escolha de ir para o TeamLead Conf ou não, na minha opinião, é óbvia. Além disso, o programa está quase pronto. Mas você pode escolher Moscou em fevereiro ou Peter em setembro e se inscrever no boletim para não perder novos vídeos e artigos, a abertura do Call for Papers e as principais datas.