Perseguindo o melhor

Não conheço você, mas gosto de experimentar pessoas. Normalmente, não peço opiniões às pessoas, mas desta vez o experimento foi realizado a pedido deles. As pessoas queriam que eu lhes desse um novo sistema de motivação. Bem, eu fiz.

O artigo é um pouco longo, porque Tentei explicar não apenas as entradas e saídas, mas também o processo de desenvolvimento do sistema, as questões que surgiram ao longo do caminho e como as solucionamos. Talvez nossa experiência seja útil para você - se não inteiramente, algumas partes dela.

Então, na entrada - uma pequena equipe de programadores 1C de três pessoas trabalhando em uma correção. Além disso, eu, seu líder, por competência central, também sou programador da 1C.

O processo de negócios é o mais comum:

1. Os programadores recebem tarefas de qualquer departamento;
2. As tarefas estão sujeitas a aprovação, se necessário. A lista de coordenadores é diferente para diferentes tarefas;
3. As tarefas têm prazo, existe a possibilidade de sua transferência (não mais que duas vezes). Antes do início, o prazo é acordado por ambas as partes;
4. Existem projetos de automação realizados em cascata. As tarefas do projeto têm a mesma vida que as demais - há prazos, aprovações, etc;
5. Existe suporte técnico sob a forma de serviço - os programadores se revezam sentados nele por 1 semana.

Sistema de Motivação :
1. Os programadores têm um salário, dependendo das qualificações;
2. Há uma desmotivação para tarefas não concluídas no prazo;
3. Existem bônus para a implementação de projetos.

A automação de todas essas coisas é a mais comum. Para definir metas, um sistema corporativo comum é usado, como 1C: Gerenciamento de Documentos. Possui instruções e memorandos nas quais as tarefas residem. Há uma pequena automação do gerenciamento de projetos em cascata. Existe um cálculo automático de desmotivação em caso de violação dos prazos.

Parece ser - viver e se alegrar, trabalhar - não bate no reclinado. Não é difícil cumprir os prazos se você participar da produção deles. Trabalho - sem muita dificuldade, nada sobrenatural. Eu, como líder, não me destaco entre outros - em outros serviços, tarefas, cronogramas e projetos são gerenciados de acordo com os mesmos princípios.

Mas uma pergunta nos assombrava - como ganhar mais dinheiro?

No sistema atual, havia duas alavancas - para obter um aumento nos salários ou prêmios do projeto . As empresas geralmente não gostam de aumentar o salário de um programador 1C, porque eles mal entendem por que esse cara precisa pagar mais dinheiro .

Para treinamento avançado ou algum tipo de categorização, como notas? Não está muito claro por que você deve pagar mais por isso, se as qualificações não afetarem os resultados. E se os resultados são diferentes para os programadores, isso está relacionado às qualificações formais? Quanto aumentar o salário, se você continuar por esse caminho? Os salários atuais eram aproximadamente iguais à média do mercado.

Algumas vezes, para aumentar o salário dos programadores, ainda conseguiu. Por exemplo, um foi expulso pela certificação pelas forças dos franqueados envolvidos. Eles aumentaram o outro, porque ele estava bem no mercado, valeu mais (avaliação subjetiva). Mas esse caminho não pode ser repetido com frequência, para não ouvir: "Você está fodido lá no final, ou o quê?"

Também é impossível trabalhar duro para aumentar os prêmios do projeto, porque o tópico é bastante escorregadio. Goste ou não, um prêmio do projeto é um pagamento adicional pelo trabalho pelo qual já foi pago . Obviamente, você pode reformular de alguma forma, por exemplo, um custo extra por executar antecipadamente, participar ativamente da implementação ou por trazer rapidamente a automação aos requisitos do cliente.

Mas, mais cedo ou mais tarde, o líder começa a fazer a pergunta - se uma pessoa está sempre fazendo projetos antes do previsto, por que devo pagar mais por isso? Talvez o prazo seja calculado incorretamente?

Depois de pensar, nós e os programadores decidimos por nós mesmos criar um sistema de motivação e mudar nosso trabalho para obviamente trazer mais benefícios à empresa. Supondo que, para maior benefício, receberemos mais dinheiro.

É certo conversar com a empresa sobre os benefícios para a empresa, o que eu fiz. Conversei com os líderes, diretor, proprietário. As opiniões eram diferentes, mas se você as agrupar e classificar, a idéia central era a seguinte: queremos o que você já está fazendo, apenas mais rápido . Ou de outra maneira: queremos obter mais ao mesmo tempo.

Obviamente, estamos falando sobre a velocidade da programação e implementação . Note-se que naquela época não sabíamos nada sobre scrum, como um método que acelera o trabalho dos programadores.

Para mim, como líder, esse momento foi muito importante: queria que os programadores cuidassem de seus resultados . Eu não queria chutá-los, ficar de pé sobre minha alma, controlar o processo e o tempo. Eu precisava de um sistema autônomo que pudesse ficar sem mim e sem um líder.

O sistema de pagamento mais próximo e adequado para nossos propósitos parecia ser o pagamento por peça pelo trabalho realizado . Parecia promissor e facilmente comprovável: aqui está o homem, aqui está o trabalho realizado, aqui está a renda. Não há necessidade de motivar - se uma pessoa não quiser trabalhar, ela não ganhará dinheiro, e isso se tornará óbvio. Com essa pessoa, será possível sair sem remorso.

Uma questão chave surgiu - como avaliar o trabalho e quanto pagar por eles ? Em francos, esse problema é resolvido de maneira mais simples - há uma estimativa da complexidade em horas pelas quais o cliente paga. O programador, de fato, recebe uma porcentagem da taxa horária. Não tínhamos clientes nem relações com dinheiro, mas precisamos avaliar de alguma forma o trabalho.

A ideia surgiu rapidamente, assim como sua implementação e a base de evidências. Decidi avaliar as tarefas nas horas do melhor programador .

Se o melhor programador resolver o problema em 1 hora, custa 1 hora. Outro programador que resolver esse problema em 4 horas receberá 1 hora paga por ele.

Para avaliar as tarefas "pelo melhor programador", você precisa entender quem é. Decidimos assim: o melhor programador tem todo o conhecimento necessário sobre como resolver o problema . Ele conhece o campo metodológico, conhece os mecanismos necessários da plataforma, conhece os metadados e “onde está”. Em geral, senta e senta, sem perder tempo em vão.

O objetivo principal de uma avaliação é minimizar a perda de tempo, tornando-as não rentáveis. As perdas no trabalho de um programador são enormes e, em termos de perdas de volume, geralmente excedem a metade do tempo de trabalho.

Fiz a melhor avaliação pessoalmente, e talvez esse seja o gargalo de todo o sistema. Ficou imediatamente claro que era necessário tornar o sistema de avaliação, se não transparente, e depois verificado retrospectivamente. Portanto, decidi fazer um classificador de avaliação de trabalho - um livro de referência simples contendo componentes padrão para resolver o problema e sua avaliação. Foi gradualmente preenchido, chamamos a avaliação do trabalho de “jurisprudência” - os itens testados na prática, com o prazo medido, caíram no classificador.

O classificador continha, por exemplo, os seguintes itens:

• Desenvolvimento de um relatório simples, como "Vendas", um registro, no ACS no modo de usuário. Pontuação - 15 minutos;
• Criação de um registro de acumulação, com um simples registro de movimentos completamente determinado pelo contexto do documento. Pontuação - 15 minutos;
• Desenvolvimento de função, sem RLS, com uma pequena lista (até 10) de objetos permitidos. Classificação - 10 minutos.

O lead time incluiu desenvolvimento e teste pelo desenvolvedor. Se ocorreu um erro no banco de dados ativo nas alterações criadas nesta tarefa, os erros foram corrigidos pelo executor às suas próprias custas.

Cada tarefa executada pelos programadores recebeu essa avaliação antes da execução. É claro que algumas tarefas continham vários pontos do classificador - por exemplo, um registro, mais vários detalhes, mais um relatório e mais uma tarefa automática. O tempo neste caso foi resumido.

Agora era necessário determinar quanto pagar por uma hora de trabalho do melhor programador . Decidimos essa pergunta na testa. Um bom programador médio recebeu 60 mil rublos no mercado. Decidimos que o melhor programador deveria receber 100 tr. É claro que posteriormente esse valor pode ser alterado em qualquer direção.

Cálculos simples e arredondamentos nos deram a taxa horária do melhor programador: 600 rublos por hora .

O número ficará bom, porque é metade da taxa horária das franquias locais e menor do que o custo dos freelancers, que pediram entre 700-900 rublos por hora.

Mas o principal - apenas o trabalho direto fazia parte da nossa taxa horária. Não houve reflexão, modelagem, análise de decisão, etc.

No entanto, percebendo que ainda haveria uma conversa sobre essa aposta com a liderança, decidimos garantir que estávamos certos. Para isso, conversamos com franquias e freelancers de amigos e desconhecidos. Demos a esses caras algumas tarefas para avaliar e fizemos uma pergunta simples - quanto você receberá dinheiro por esse trabalho? O resultado foi previsível - os caras pediram trabalho 2-3 vezes mais do que nós (considerando os impostos sobre o salário). Isso se acalmou - a bunda está coberta.

Agora era necessário equilibrar o sistema pela quantidade de acumulação mensal, a fim de evitar erros nas duas direções. O primeiro lado são programadores. Você nunca sabe, de repente acontece que o programador ganhou 10 tr - ele não terá nada para alimentar sua família. A solução é simples, vi quando trabalhei na franquia - para definir o pagamento mensal mínimo , menor do que o programador não receberá. Sem pensar duas vezes, eles decidiram que esse seria o salário atual.

O segundo lado é a empresa. Apenas um pagamento mínimo não é lucrativo, porque pode ser usado para enganar o sistema. Por exemplo, para realizar 20 tarefas por mês antes que o estado esteja “quase pronto”, obtenha um salário e, no próximo mês, faça uma descoberta, feche 20 tarefas inacabadas e mais 30 novas e faça um acordo. A propósito, no franco era exatamente isso, e todo mundo usava.

A saída da situação também é simples - "lembre-se de menos" . Ele trabalhou em 40 tr, recebeu um salário de 60 tr - ok, lembre-se dos menos 20 tr No próximo mês você terá que. Trabalhe no próximo mês com 80 tr - você recebe 60 tr, e não deveria.

Ao mesmo tempo, por precaução, estabelecemos o limite de pagamento - 100 tr. Concordamos que o trabalho realizado além desse valor será considerado um plus no próximo mês.

Agora eu tinha que descobrir o que fazer com os projetos. Um projeto, se simplificado, é um conjunto de tarefas relacionadas entre si por algum significado ou objetivo. Mas a empresa está interessada não apenas na implementação acelerada de cada uma dessas tarefas, mas também na implementação mais rápida possível de toda a lista de tarefas do projeto e na obtenção do resultado.

A solução também é simples, e novamente espiada por outras pessoas - para acumular e dar parte do salário por peça no final do projeto . Decidimos que conosco serão 20%. Enquanto o projeto está em andamento, o programador recebe 480 rublos por hora e os restantes 120 rublos a cada hora no final do projeto.

Bem, tudo parecia estar calculado e pensado, é necessário iniciar a operação de teste.

O primeiro passo foi mudar o processo de negócios dos programadores:
1. As tarefas agora devem ser definidas não pessoalmente para o artista, mas para mim, o líder;
2. Agora tenho que avaliar cada tarefa em horas;
3. Após a aceitação e avaliação, a tarefa fica disponível para implementação.

Ok, o processo de negócios foi alterado, é necessário automatizar . Para ter mais liberdade de criatividade, paramos de usar tarefas e memorandos (todos os usavam) e criamos e criamos dois novos objetos para nós mesmos em um ou dois dias:
1. Uma aplicação ao departamento de TI, com todos os campos necessários para a nossa avaliação;

2. Um sistema simplificado de contabilidade para projetos e tarefas neles, com o mesmo sistema de avaliação.

E imediatamente eles fizeram um relatório que mostrava o resultado em horas e o dinheiro ganho para que os programadores pudessem ver seus resultados todos os dias.

Começou a trabalhar e imediatamente se deparou com dificuldades - os programadores começaram a reclamar que as classificações de tarefas são muito baixas . "Eu preciso pensar sobre isso", "mas nunca me deparei com o processamento, preciso resolver o problema", "fiz uma tarefa automática uma vez, há alguma instrução para ler?" etc.

Eu os ouvi e comecei a refletir sobre a profundidade filosófica da questão: a empresa deveria pagar pela aquisição de conhecimento por seus funcionários?

Parece que a resposta é óbvia - deveria. Mas é tudo tão óbvio? O que acontece.

Aqui está uma tarefa para um programador - preencher a subconta Warehouse no lançamento na conta 003 (por algum motivo, em um soft starter típico, ele não é preenchido). Mas ele não sabe como processá-lo, nem do lado do contratado, nem do lado do processador.

Parece - sente-se e descubra o que tal e qual sempre fez. No sistema salarial tradicional, o empregador pagará o seu tempo enquanto você trabalha por lá.

Mas não é tão simples. Das quatro pessoas (três programadores + eu, o chefe), dois são bem versados ​​no processamento, e a tarefa foi para alguém que não entende. Quando entendemos a reciclagem? O programador está no último emprego, eu estou no local atual, porque anteriormente não havia prática de cobrança de pedágio / reciclagem. Acontece que a empresa atual já pagou por essa competência . E parece que pagar uma segunda vez, pelo menos na mesma quantia, está errado. O que agora precisa ser feito? É isso mesmo, transfira competência para quem recebeu a tarefa.

Outra questão surgiu - e para que o portador de competência precisa disso? Ele também tem um salário por peça e, em vez de transferir conhecimento, fará mais trabalho melhor.

Comecei a refletir sobre uma questão ainda mais filosófica: uma empresa deveria pagar pela transferência de competência entre funcionários? Tradicionalmente, a transferência de conhecimento é um dado adquirido. Mas todos sabemos que a qualidade dessa transferência deixa muito a desejar. A exceção são os programas de adaptação e orientação, mas eles não são muito comuns.

Então, a solução se tornou óbvia para nós:
1. Pela transferência de conhecimento e ajuda mútua, devem ser pagos;
2. Para a aquisição de novas competências deve ser pago.

O segundo ponto é sobre o conhecimento que nenhuma equipe possui. Por exemplo, tivemos a tarefa de extrair dados constantemente de um sistema externo para o 1C usando consultas diretas ao MS SQL. A tarefa não é difícil, mas ninguém fez isso antes. Fiz isso - criei um aplicativo em meu nome, cuja essência é fumar o trabalho com fontes de dados externas em um nível suficiente para resolver um problema específico. Avaliação da tarefa - 1 hora (e você pode sentar pelo menos o dia inteiro).

Como resultado da solução do problema, contamos com um especialista que pode resolver problemas com fontes de dados externas e não pagaremos mais por essa competência . Somente para sua transferência para outros programadores.

Decidimos pagar pela transferência de competências e assistência mútua e, por isso, criamos o prazo apropriado - os custos de análise e design. Para não perder tempo com grande burocracia, desenhamos uma tabela no Word contendo os dados:
1. A questão que foi discutida / projetada / referida;
2. O horário de início e término da discussão, com precisão de minutos;
3. Os participantes.

Um documento separado foi adicionado ao sistema contábil, no qual os resultados de tais discussões foram conduzidos uma vez por semana. Normalmente, as discussões cabem em 5 minutos , chegando ocasionalmente a 15 minutos. Durante uma semana, resultou em todas as 3-5 horas .

O que é importante: o tempo de discussão foi pago a todos os seus participantes , ou seja, era benéfico adquirir e transmitir conhecimento. Foi benéfico ajudar os colegas, pois as leis humanas não desapareceram - se você ajudar, elas o ajudarão e, se você mantiver o conhecimento para si mesmo, esteja preparado para enfrentar uma tarefa desconhecida com uma estimativa de 1 hora e sente-se por 2 dias. É claro que houve exceções quando eu mesmo excluí da lista de participantes quem estava sentado e contando o corvo.

Sim, todas essas reuniões deveriam ter sido realizadas em minha presença, como Antes do mundo exterior, eu era responsável pela qualidade do sistema. Todas as questões discutidas foram refletidas no sistema e, se necessário, foi possível retornar e verificar se o dinheiro foi gasto legalmente.

Havia mais uma pergunta "podre" - suporte técnico . Falta - porque eu não gosto da disponibilidade de suporte técnico, entorpece a mente dos usuários, tira um tempo valioso de especialistas, sem trazer muitos benefícios para a empresa.

Formalmente, o suporte técnico da época é um oficial de serviço dedicado que deve ajudar as pessoas dentro de uma semana. Quanto paga um programador que assiste ao suporte técnico?

A princípio, a ideia não era pagar, mas reduzir a base para o cálculo do salário no cálculo do pagamento. Por exemplo, se um programador tem um salário de 60 tr, gasta 2 semanas em um mês em suporte técnico, ao calcular, considere metade do salário - 30 tr e, durante o resto do tempo, considere um acordo.

Mas fica imediatamente claro que algum tipo de absurdo está sendo obtido - a empresa não é muito grande e o suporte técnico objetivo não leva um dia inteiro. Consequentemente, o programador consegue resolver os problemas e pode usar o esquema com um "empurrão".

Existe uma saída muito mais fácil: calcular quanto tempo por dia é gasto com o suporte técnico do melhor funcionário e pagar ao programador a mesma quantia atualmente. Porque Eu era considerado o melhor nessa gangue, depois medi em mim mesmo. Fiquei sentado por alguns dias apoiando-o com um cronômetro e o objetivo não era manchar o ranho, mas ajudar rapidamente as pessoas. Redirecione corretamente suas perguntas para tarefas. Forneça links para instruções se uma pessoa não as leu e requer treinamento on-line sobre o que todos conhecem. Bem, etc.

De acordo com os resultados das medições, o suporte técnico leva em média 2 horas por dia . Bem, essa é a figura. Concordamos que, nesse valor, ela seria paga ao oficial de serviço - 2 horas por dia ou 10 horas por semana.

É claro que não é rentável se engajar apenas no suporte técnico - isso é cerca de 25 mil rublos por mês.

Para que o oficial de serviço não ficasse entediado, demos a ele um pedaço de papel e o fizemos escrever todos os que se dirigiam a ele - apenas seu sobrenome. No sistema contábil, foi criado um documento em que o atendente no dia trouxe todos os “convertidos”. Por que - veja o final do artigo, sob o título "Um bom bônus".

Na verdade, a imagem foi formada sobre isso e continuamos a operação de teste do sistema .

Entre os programadores, houve um entusiasmo sem precedentes . Agarrada à tarefa, a fumaça permaneceu como um pilar na execução.

Silenciosamente, um programador começou a trabalhar, que adorava discutir "que tarefa difícil, existem tantas armadilhas"; ele podia passar horas sugando essas armadilhas, preenchendo seu próprio preço (não está claro, no entanto, por que - o salário).

O programador imediatamente começou a tomar decisões ótimas, que adoravam sentar-se por horas e "pensar na solução ideal", porque agora a solução ideal foi emitida por uma equipe que fazia o brainstorming em 5 minutos.

Um programador introvertido começou a se comunicar com mais frequência com os clientes, que puderam permanecer em uma tarefa já resolvida por dois dias porque ficou com vergonha de conversar com o cliente.

Tarefas muito mais sensatas e de alta qualidade dos usuários começaram a aparecer, porque os programadores começaram a ajudar em seu design.

O programador iniciante, que teve vergonha de fazer uma pergunta a seus colegas por causa de "é inconveniente distrair, ficará aborrecido" (devo dizer, eles já estavam realmente aborrecidos antes) por horas sentadas e em silêncio.

Programadores tornaram-se apaixonados e gananciosos, no bom sentido da palavra. Eu, como líder, alcancei meu objetivo - o sistema começou a funcionar, embora não completamente sem mim, depois com minha participação mínima.

Minha participação tornou-se transparente e compreensível, são apenas pontos no processo de negócios:
1. Aceitação e avaliação de tarefas, eu fazia isso uma vez por dia, por cerca de 15 minutos;
2. Participação em reuniões sobre análise e design (isto é ~ 3 vezes ao dia por 5 minutos).

Total, para gerenciar três programadores - 30 a 60 minutos por dia . Ninguém precisa chutar, seguir a execução e o tempo, motivar, verificar a qualidade - tudo foi feito por si só . Eu pude assistir os resultados a qualquer momento através do sistema. Isso não quer dizer que acabou sendo um autogoverno completo, mas estávamos o mais próximo possível disso.

Realizamos a operação de teste por 3 meses. Durante esse período, a produção de relógios dobrou e o salário calculado para a nova motivação cresceu 30%. A diferença é clara - agora o salário tinha que ser calculado . Segundo os próprios programadores, eles nunca tiveram que trabalhar tão intensamente em qualquer lugar antes. Foi intenso, não muito, nem muito - eu sempre fui contra mais de um dia de trabalho de 8 horas.

Mas o que importa aqui não é o que eles disseram sobre a intensidade do trabalho, mas como o disseram. Eles falaram orgulhosamente por si mesmos.. Não apenas porque o novo sistema tornou seu trabalho mais eficiente, mas também porque eles próprios foram os autores desse sistema. Eles mesmos se tornaram mais eficazes, tornaram seu trabalho transparente e mensurável, começaram a olhar de maneira diferente para a empresa, seus gerentes e funcionários.

Explico o sucesso da seguinte forma:
1. Se você examinar o prisma de teses sobre o desenvolvimento de sistemas de motivação, fica claro que definimos bem o produto. Um produto é uma tarefa resolvida. Dinheiro limpo é pago por este produto. Tudo o resto - às suas próprias custas (reflexão, Internet, comunicação em mensagens instantâneas, fumaça, irritação, depressão, etc.).
2. Se você observar o processo de desenvolvimento por meio do autogerenciamento, poderá ver que o sistema foi criado com a participação direta das pessoas que trabalham nele.
3. Tornamos o sistema o mais mensurável possível - de acordo com os requisitos de controle. A mera medição do trabalho realizado fez as pessoas se moverem mais rápido e não se envolverem em bobagens.

Após a operação de teste, passei por várias iterações para proteger o novo sistema: diretor de pessoal, diretor financeiro, diretor, proprietário, consultor externo de RH (Moscou, parece muito famoso). Todo mundo gostou do sistema.

Como chefe de seu desenvolvimento, eu estava particularmente interessado na opinião do consultor de RH, como Ele conhece bem a prática mundial e concluiu centenas de projetos para desenvolver sistemas de motivação. Sua avaliação do meu sistema acabou sendo muito alta, ele gostou especialmente dos contornos da defesa ("lembre-se de menos" e limite o pagamento máximo).

Posteriormente, os princípios desse sistema tornaram-se básicos para outros sistemas de motivação empresarial.

Um bom bônus
Portanto, tínhamos em mãos uma estimativa em rublos para todos os trabalhos, incluindo análise, design e suporte técnico. Era um pecado não aproveitar esta oportunidade e não fazer o cálculo do custo da automação no contexto de clientes e projetos . Afinal, agora sabíamos com certeza quanto dinheiro a empresa gasta com a automação e, se você observar esses dados em termos de utilidade , obteremos apenas uma imagem deslumbrante.

Por exemplo, aprendemos que o suporte técnico para o vice-contador, que, de acordo com a descrição do cargo, deve conhecer melhor a AMR em contabilidade, deixa mais dinheiro do que essa pessoa recebe na forma de salário.

Também aprendemos que as pessoas que sempre reclamam "não estão envolvidas conosco" consomem 40% de todo o dinheiro em automação.

Foi interessante observar o orçamento crescente de mês para mês para projetos que não tinham um host (é quando o diretor, por exemplo, diz - automatize esse serviço e a automação não foi executada em nenhum lugar, mas eles precisam escrever tarefas por conta própria, para que andem em círculos) .

A apoteose foi o relatório da sessão estratégica com um resultado decepcionante - mais da metade do dinheiro que a empresa gasta em automação sem sentido. A falta de sentido é uma característica completamente significativa. Por exemplo, a funcionalidade é desenvolvida, não há comentários, mas não é usada ("sim, de alguma forma, todas as mãos não alcançam"). Ou a funcionalidade projetada para ajudar a melhorar o processo de gerenciamento alterando o valor do indicador - e o valor do indicador permanece parado ou piora (e no início do projeto, foi dito que isso não ajudaria vocês, vocês têm um problema diferente).

Qual é o resultado? Eles começaram a nos ouvir com mais frequência e cuidado, principalmente antes do início do trabalho. Porque agora fomos capazes de prever os resultados dos projetos, contando não apenas com o pensamento sistêmico, mas também com as estatísticas em números. O volume de trabalho sem sentido nos primeiros meses diminuiu para 30% - apesar do fato de a estrutura da “falta de sentido” ter melhorado. Mas isso é outra história.

PS

Há pessoas que repetiram minha experiência - ou seja, elas também criaram um sistema de gerenciamento e motivação baseado em certas horas padrão. Eles dizem que estão indo bem. Embora, quem admite ...

eu não conheço você, mas sou burro. A experiência descrita no artigo aconteceu há cerca de 4 anos, se bem me lembro. Então descobri o scrum - mais precisamente, comprei um livro em uma venda - e me empolguei, mas abandonei tudo o que era antigo. Porque é burro.

Você sempre quer não pensar, mas levar o que está acabado. Scrum, PMBOOK, CORE PM, Kanban, CBT ou algo mais, “implementa” ou, mais elegante, “implementa”. E alguns idiotas, como desenvolvedores de guias de scrum, também estão alimentando a situação dizendo algo como "se você estiver fazendo o caminho errado, não precisará se assustar". Embora no livro eles mesmos tenham escrito que você precisa pensar com sua própria cabeça.

A experiência descrita no artigo é inestimável. Para mim, é claro. Só porque ele mostrou a importância de avaliar tarefas em algumas unidades mais ou menos estáveis. Então, já no scrum, ele se transformou em pontos. Mais experiência mostrou o que o sistema de motivação certo faz com as pessoas. Ele também mostrou que, com o sistema certo de gerenciamento e motivação, as pessoas não precisam de um líder. E muito mais tem mostrado.

Como você gosta? Isso é útil? Ou seja, não trabalho, trata-se de 1Snikov.