Onde conseguimos a garrafa?

Técnica de gerenciamento de garrafas ou Flowcon, incluindo tarefas. Fluxo, projeto, desenvolvimento, funções de rotina, regulares, etc.

Muitas pessoas, tendo aprendido sobre a metodologia e as soluções baseadas nela, fazem perguntas - o que, como, qual é a essência, com base em quais “práticas mundiais” são feitas, quais métricas são usadas, a quem se adequa e de onde veio. Respondi a cada um individualmente, mas decidi - tudo, pare, cansado de escrever a mesma coisa centenas de vezes. Sou programador ou quem? A reutilização pode ser não apenas para código, mas também para informações. Escreverei uma vez, tentarei responder a todas as perguntas do artigo e aconteça o que acontecer.

O melhor de tudo, parece-me, apresentar na forma de uma história, porque o nascimento de uma garrafa está intimamente ligado à minha carreira, por assim dizer. Eu farei isso. Perseguido.

PMBOK

A primeira técnica de gerenciamento de projetos e tarefas que eu conhecia se chamava PMBOK. Foi o ano distante de 2006.

Naqueles dias, o PMBOK era quase um monopólio no gerenciamento de projetos. Nos currículos e vagas, só foi ouvido o PMBOK. Não havia metodologias flexíveis no ar naquela época, embora elas já existissem em algum lugar.

O PMBOK era então um método de gerenciamento de projeto puramente em cascata, ou seja, assumiu uma estrutura rígida de etapas e tarefas, prazos e dependências do início ao fim. Consequentemente, ela se fragmentou rápida e lindamente em fragmentos nos projetos de implementação da 1C da época, devido à constante violação da famosa (então) regra do triângulo Orçamento - Tempo - Conteúdo.

Naqueles dias, nem clientes nem implementadores eram capazes de fazer especificações técnicas sensatas, escrever requisitos funcionais, simular o trabalho da empresa. Sim, e configurações, como SCP, constantemente lançavam surpresas - elas se desenvolveram. Como resultado, a lista compilada de obras tornou-se irrelevante em algum lugar um dia após o início do projeto.

Mas os cérebros dos programadores são curiosos e criaram uma certa combinação de PMBOK e o então Agile desconhecido. Nós chamamos isso de Borda Amarela. E eu também fui forçado a me tornar seu apologista.

Borda amarela

O Edge amarelo foi baseado nos estágios criados pelo PMBOK, substituindo apenas radicalmente o objetivo de cada um deles. Qual é o objetivo do PMBOK? Complete todas as tarefas do estágio.

O Yellow Edge surgiu com outro objetivo: assinar o ato . Por exemplo, existe um estágio - "Implementação da contabilidade do armazém". Na fase de criação e redação do TK, alguns trabalhos aparecem nele, como "Relatório de materiais", "Treinamento do usuário", "Definindo direitos de acesso" etc. - dependendo da profundidade do estudo na fase do exame expresso.

Esta lista de trabalhos serviu como um kit inicial para começar com algo. Um programador chega ao chefe do armazém, ou lojistas ou contadores de materiais começam a conversar com eles, e acontece ... Bem, acontece que os cadernos terminam com força terrível.

A princípio, o cérebro estragado pelo PMBOK disse: não! É impossível Só é necessário fazer o que está escrito no TK! E os gerentes de projeto entraram em longas negociações negativas com o cliente. Alguém conseguiu convencer o cliente por trabalho adicional, tarefa técnica adicional e assim por diante. A maioria não. O cliente disse: caramba, pessoal, eu não sei o que é TK e que melhorias em seu programa precisam ser feitas para que tudo funcione para mim, mas se não funcionar, não assinarei o ato .

A realidade, em geral, venceu, e o projeto vivia em duas dimensões - plano e fato. Parece que o plano pode ser descartado, mas existe um problema - um orçamento foi elaborado de acordo com ele, protegido pelo gerente de projetos por parte do cliente e você não pode tocá-lo. Mas o fato permaneceu - é necessário fazer um mínimo do máximo do que o cliente deseja assinar o ato, caso contrário não haverá pagamento ou, consequentemente, salário.

Então, na minha cabeça, havia um modelo de Edge, embora amarelo. A garrafa começou a se formar e continha duas práticas de gerenciamento de tarefas. Parece que eles se contradizem, mas se davam bem na vida.

CORE PM

Então, para o monte vou mencionar. Vendo problemas com o gerenciamento de projetos entre mim e meus colegas, comecei a escolher a teoria fora do PMBOK e encontrei um livro na loja com o título direto "Gerenciamento de projetos", de autoria dos quatro Tates. Eles nomearam seu método CORE PM.

A essência é praticamente a mesma do PMBOK. A invariância do plano é chamada de principal. Procedimento diretamente separado, grande, complexo e burocrático foi inventado, como fazer alterações no plano.

Naquela época, já tendo reconhecido a borda amarela, não pude acrescentar nada deste livro à minha garrafa. E isso é muito bom, porque percebi novamente que não existem tios inteligentes no mundo.

Tios inteligentes

Sobre o fato de não haver tios inteligentes no mundo, entendi há muito tempo, de volta ao instituto, quando pratiquei. Então eu gostava de métodos estatísticos de gerenciamento da qualidade do produto e fui para a fábrica, onde passei um mês coletando dados para o diploma.

No início, o objetivo era precisamente a coleta de dados que eu e o professor queríamos distorcer em software especializado (Statistica?). Parece que a idéia era construir um modelo matemático de produção de transportadores para entender a influência de diferentes estágios na qualidade do produto final.

O professor, antes da viagem, me entregou alguns livros sobre mapas de Shekhart, controle estatístico do processo (CEP), gerenciamento geral da qualidade (TQM). Aparentemente, ele próprio não os leu - caso contrário, não se ofereceria para construir um tapete. modelo de produção. Eles eram adequados, por exemplo, para sensores de pressão, onde a construção do modelo e a análise de regressão de Draper eram a base da calibração, mas não para a indústria automotiva.

E eu li livros. Tudo era tão simples lá que era de tirar o fôlego. E a fábrica também tinha tios inteligentes no serviço de gerenciamento de qualidade. Eles conheciam os conceitos básicos desses livros, mas, para minha grande surpresa, eles nunca usaram não apenas métodos para melhorar a qualidade, mas também as fórmulas mais simples para avaliar o estado atual do processo técnico.

E as fórmulas eram mega-simples. Você pega cem detalhes, mede, insere os números no Excel, calcula a média, o desvio padrão (o mesmo sigma) e exibe um indicador simples e compreensível - o índice de adequação ou o índice de reprodutibilidade (se o processo for estável). Na verdade, esse indicador dizia claramente se tudo está normal com o processo ou não.

Quando calculei esse número, eles estavam em choque. E pelo fato de que finalmente viram essa figura e de quão terrível ela se revelou. Eles pediram para contar mais algumas peças e máquinas - mas e eu?

Havia muitas coisas interessantes, incluindo um simples esforço, durante minha presença, para melhorar radicalmente a qualidade da produção. Mas esse não é o ponto.

Um pensamento-chave veio a mim então: tios inteligentes sabem muito, mas não fazem nada .

Os métodos estão completos - tanto no gerenciamento da qualidade quanto no gerenciamento de tarefas / projetos e no gerenciamento geral. Pergunte a qualquer gerente eficaz - darei uma palestra sobre como e o que fazer de acordo com tal e qual técnica. E pergunte brevemente - ele faz o que está escrito na metodologia? Figos lá.

A garrafa foi enriquecida com um conhecimento muito útil. Tudo deve ser feito e verificado por si mesmo, ninguém pode ser confiável, especialmente aqueles que não conseguem mostrar seus resultados na prática.

Modelo de gestão russo

Percebendo que tinha que compreender tudo sozinho, decidi ler outra coisa. Eu queria não aprender uma nova técnica pronta, mas entender algo mais fundamental. O livro "Russian Management Model", de Alexander Prokhorov, chamou minha atenção.

Dizer que o livro é brilhante é não dizer nada. Você deve lê-lo se você trabalha na Rússia. Felizmente, não existem receitas prontas lá, mas todas as razões pelas quais temos tudo como estão são elegantemente pintadas.

Não vou pintar por muito tempo, vou mencionar apenas alguns pensamentos importantes que são importantes no contexto deste material.

A primeira é que o trabalho do povo russo deve ser medido para que ele não se torça. Porque estamos tão acostumados a enganar qualquer sistema que o fazemos inconscientemente. Não aceitamos regras, restrições e leis. Mais precisamente, acenamos com a cabeça, concordamos, e nós mesmos já pensamos em como enganar.

O segundo - o povo russo trabalha melhor no chamado células de cluster, isto é, equipes pequenas não controladas com muita força. O espaço aberto não é para nós. Como você entende, o mesmo princípio é estabelecido em um scrum.

Terceiro, o povo russo não faz nada como lhes é dito. Essa é uma ideia chave ao implementar qualquer metodologia. Você dá instruções sobre como agir, libera pessoas e espera pelo resultado, mas não é. Porque as pessoas jogam fora suas instruções e fazem como costumavam fazer.

A garrafa após este livro é incrivelmente enriquecida. É verdade que os métodos para resolver esses problemas "russos" precisavam ser buscados por conta própria. Eu achei o controle.

Controlando

Controlar é um controle baseado em número. Uma das minhas técnicas favoritas. Enfatizo o principal: controlar não é controlar. Isso é gerenciamento.

Se não houver números, o controle é realizado às cegas, com base em informações indiretas. Quando você trabalha com tarefas, isso é especialmente verdade, porque um sistema para medir tarefas geralmente não vale nada. Geralmente, esses são os custos de mão-de-obra em horas, o prazo (e o cumprimento) e, de fato, partes das tarefas resolvidas. É impossível gerenciar efetivamente com base nesses dados.

A parte do controle que formula requisitos de informação, ou seja, números, métodos para obtê-los, reprodutibilidade, qualidade, profundidade do estudo, etc.

O número deve ser de alta qualidade, mas você raramente os vê. Já escrevi vários artigos sobre isso, não vou me repetir. Apenas aceite minha palavra: você não encontrará números de alta qualidade controlando critérios com muita frequência. Provavelmente porque ninguém leu o artigo Controlando na Wikipedia.

Então, o controle apareceu na garrafa. É universal e, a partir de então, controlava a formação de quaisquer números exigidos por qualquer técnica.

Gerenciamento de limites

O gerenciamento de limites, ou gerenciamento de fronteiras, é uma ciência pouco conhecida sobre a transformação de sistemas de negócios. Embora, talvez, algo já tenha mudado agora - eu o estudei há vários anos, de acordo com os artigos sobre os trabalhos de Eric Trist e outra pessoa, não me lembro do sobrenome. Agora, a Internet diz que há algum tipo de livro em inglês sobre esse tópico - não posso dizer nada, não li.

A linha inferior é incrivelmente simples: limites . Sistemas de negócios internos, processos, mesmo em uma pessoa - muitos limites. Físico, emocional, energia, etc.

As fronteiras são ruins e boas, úteis e prejudiciais. Alguns interferem no curso normal do processo, outros dividem o fluxo misto em duas partes, ajudando a processá-lo mais rapidamente. Alguns isolam uma pessoa das informações necessárias, dificultando a reação a tempo, enquanto outros a protegem de informações desnecessárias, permitindo que você não se distraia.

Em suma, as fronteiras e sua gestão são mega legais. Para entender isso, você precisa tentar. Para pessoas inteligentes como você, basta entender o princípio chave para começar a aplicá-lo. O restante precisa de estudos de caso e práticas específicas, e na verdade existem muitos deles. Só que eles não estão na Internet, mas precisamos inventá-lo.

Eu vim com alguns, publicados - Iceberg e o método de raias de natação .

O gerenciamento de limites teve uma influência muito forte sobre a garrafa e quase todas as suas partes - no gerenciamento do ciclo de vida das tarefas, na organização de prioridades e no gerenciamento regular.

Faça você mesmo o inferno

Ele chamou essa seção da mesma forma que a publicação com o mesmo nome. Esta foi a primeira experiência na construção de um sistema para gerenciar pedidos, memorandos, planos e projetos com base no conhecimento acumulado.

A experiência é bastante bem-sucedida, embora o artigo pareça mais negativo. Na construção do sistema, os princípios de controle, gerenciamento de limites e Iceberg (da programação de negócios) foram usados ​​principalmente. Obviamente, acabou sendo tecnocrático demais, mas a experiência, em sua utilidade, foi enorme.

Primeiro, era um sistema para toda a empresa, e não para uma pequena equipe de programadores. Em segundo lugar, o sistema alcançou seu objetivo - aumentou a disciplina executiva para níveis nunca antes vistos.

Mas o principal para mim é o uso prático de partes da garrafa em larga escala, e não em programadores, mas em pessoas comuns. Algo, de acordo com os resultados, teve que ser descartado da metodologia, mas alguns métodos provaram ser eficazes. Para a maior parte, é claro, controlando.

Pensamento sistêmico

Isso não é para mim, mas sobre um campo de conhecimento chamado pensamento sistêmico. Está cheio de livros e malas, então não vou recontar. Observo apenas um princípio muito importante, que influenciou bastante as propriedades emergentes ou emergentes da garrafa. Essas são quaisquer propriedades do sistema que podem ser vistas apenas no estado ligado.

Enquanto você está sentado longe do sistema e fantasiando sobre como ele funciona, você não vê as propriedades emergentes. Você pode projetar, desenhar, programar, testar, mesmo em público, mas quando você inicia o sistema com trabalho real, as propriedades emergentes começam a funcionar.

Você, por exemplo, presumiu que uma pessoa apresenta uma tarefa e a outra se compromete a realizá-la. Bem, bem. A segunda pessoa pode simplesmente não ver a tarefa. E se ele vir, ele não lerá. E se ele ler, ele dirá que não leu. Ou não entendo. Ou não é o trabalho dele. Etc.

Ou você pensou que na equipe o coordenador é o chefe. Eles forneceram para ele um AWP, com uma lista de tarefas que ele distribuiria aos artistas. Inicie o sistema e você descobrirá que ele não distribui nada, mas apenas percorre reuniões e festas corporativas. E as tarefas são distribuídas por um cara quieto e indescritível sentado no canto - um líder oculto. E ele, ofendendo-se com o fato de não ter sido notado, também começará a sabotar a implementação do seu sistema.

Essas são propriedades emergentes. Eles não são visíveis durante o design especulativo; eles aparecem quando o sistema começa a funcionar.

Está claro que “propriedades emergentes” é uma abstração tão grande que alguém inventou para nomear um fenômeno compreensível para todos - você precisa iniciar o sistema e algo mais surgirá, desde erros de design de arquitetura a erros triviais.

Mas, no caso do gerenciamento de tarefas, sempre lidamos com um sistema complexo que consiste em automação, gerenciamento, pessoas com seus relacionamentos e objetivos da equipe, clientes, gerentes, etc. O sucesso do gerenciamento de tarefas depende de todos os componentes, embora em graus variados, e nenhum deles pode ser ignorado.

E se, por exemplo, você é um programador que automatiza o gerenciamento de tarefas, não apenas pode, mas também ignorará muito. É mais fácil Portanto, o sistema pode e não funcionará. Não haverá bugs, mas também não fará sentido.

E eu queria que funcionasse. Portanto, acrescentei o pensamento sistêmico à garrafa - tanto como um dos princípios fundamentais quanto como sotaques e práticas específicas.

Codex Samurai e Livro dos Cinco Anéis

Parece estranho, mas foram esses livros que fizeram da garrafa uma garrafa. Vou explicar brevemente agora.

Um samurai decente na vida fez isso. No começo, fui estudar artes marciais com algum mestre. Ele estudou até que o superou. E aqui temos um samurai decente, dono da técnica de uma determinada escola (por analogia - PMBOK).

Ele deixou a escola e foi embora no Japão antigo, em busca de um novo desafio. Fui a escolas diferentes, chamei o mestre local para um duelo e tomei decisões com base nos resultados. Se o mestre era mais fraco que o samurai - bem, não o destino. Se o samurai perdeu, ele caiu de joelhos e pediu para levá-lo como estudante. E ele estudou até que novamente superou o mestre.

Isso aconteceu várias vezes. E em algum momento, o samurai tinha seu próprio estilo.

Em geral, ele não nasceu para todos, isso é normal. Alguns permaneceram "sem rosto", sendo apenas mestres de várias escolas conhecidas (este tipo de MBA).

E alguns criaram seu próprio estilo antes mesmo de entrar na primeira escola. Por exemplo, um dos heróis nacionais do Japão Miyamoto Musashi, o inventor do estilo de duas espadas e o autor do Livro dos Cinco Anéis. Ou Masutatsu Oyama, cidadão coreano, criador da escola de karatê Kyokushinkai. Tanto um como o outro inventaram seu método em algum lugar no início de uma carreira e depois o aperfeiçoaram. Tanto isso como outro a caminho encontraram mestres mais poderosos e continuaram a aprender com eles.

Mas nem um nem o outro deixaram o equipamento para substituí-lo por um estranho que parecia mais forte em um determinado momento. Eles simplesmente enriqueceram sua técnica.

E, bem, no final, um samurai decente, que derrotou todos no mundo, abriu sua própria escola. E outros samurais vieram até ele, alguém ganhou e saiu, alguém perdeu e ficou. E assim por diante ad infinitum. Então, Masutatsu Oyama, não encontrando oponentes entre as pessoas, começou, por algum motivo, a matar os touros.

Então, depois de ler este livro, entendi o que estava fazendo. Eu, como um samurai decente, comecei com a escola a uma curta distância - com o PMBOK. Então ele começou a adicionar outras escolas. É verdade que muitas vezes cometi um erro indecente por um samurai decente - não combinei a prática, mas substituí um pelo outro, em busca de uma bala de prata. O PMBOK não se encaixa - jogamos fora, pegamos CORE PM, não dá certo - jogamos novamente, jogamos no scrum e assim por diante. Portanto, mudei minhas táticas - comecei a aplicar novas práticas como um experimento, ver o que acontece e deixar as soluções mais bem-sucedidas na garrafa.

Programação de negócios

A programação de negócios é um conjunto de métodos e práticas simples para melhorar os negócios. Pelo menos o todo, pelo menos uma certa parte.

Aconteceu que a programação de negócios se desenvolveu paralelamente à garrafa, e o objetivo da melhoria era tudo, exceto o departamento de TI nativo.

Mas, em algum momento, a compreensão veio de repente. Bem, eu não estou certo. Sei como melhorar qualquer processo e atormento meu processo nativo com alguns métodos estrangeiros.

Em geral, apliquei programação de negócios e, pela primeira vez na minha vida, recebi um aumento mensurável na eficiência dos programadores e imediatamente - duas vezes. As mudanças diziam respeito ao processo, motivação, objetivo, sistema de gerenciamento e automação. Em geral, todos os cinco componentes com os quais a programação comercial trabalha. Nós mesmos construímos nosso trabalho.

O resultado me impressionou, programadores, gerência e especialistas em sistemas de motivação. Mas eu, não sendo um samurai decente, joguei todos os resultados no lixo, porque na venda comprei um livro sobre scrum.

Scrum

Existem dois scramas neste mundo - certo e errado. O correto está descrito em um livro de Jeff Sutherland. Errado - no chamado guia de scrum, e os autores ainda listam o mesmo Jeff Sutherland.

O scrum correto diz: é possível e necessário acelerar o trabalho em 4 vezes. O errado não diz nada, apenas fornece algumas regras.

Um scrum correto fornece honestamente referências aos métodos japoneses de gerenciamento de qualidade, chamando-os de um dos fundamentos da filosofia scrum. Em particular, ele recomenda usar as regras de um samurai decente - tome o scrum como base e crie sua própria técnica. Scram errado diz - faça como escrevemos aqui. E se você fizer isso de maneira diferente, isso não é um esforço.

Em geral, peguei o livro e fiz tudo como está escrito. Quadro, adesivos, comícios, retrospectivas, etc. O resultado atendeu a todas as expectativas - dobramos de velocidade, ou seja, começamos a produzir o dobro do resultado por unidade de tempo.

No entanto, o scrum em sua forma pura teve que ser jogado fora por uma simples razão - a equipe de programadores se dispersou em diferentes escritórios, e a oportunidade de usar uma placa foi perdida. Sofreram por algum tempo usando dois conselhos, mas também há comícios, retrospectivas que exigem participação pessoal. Portanto, o scrum foi abandonado.

Mas o melhor foi deixado na garrafa. Qual é o melhor do scrum? É isso mesmo, o sistema de medição de tarefas é o planejamento de pôquer. Não há nada mais decente para avaliar as tarefas dos programadores em nosso mundo.

O sistema de relógio usado anteriormente é muito pior, porque a inflação ou a deflação das estimativas surgem constantemente. Os pontos são muito mais estáveis.

Dos elementos scrum restantes na garrafa, talvez, apenas um sprint permanecesse, como uma das opções de planejamento. Quem trabalhou com 1C sabe que o sprint é o planejamento de calendário espacial mais comum, ou seja, uma certa quantidade de produtos que precisam ser vendidos / comprados / produzidos por um determinado período.

Então, obrigado, scrum, por tudo o que você nos ensinou, mas você mesmo cavou sua própria cova, com seu guia do scrum. Pegamos apenas o melhor.

Scrum de fluxo

Então tive a experiência de implementar a estratégia de uma empresa. A experiência é única para um programador - podemos dizer que tive muita sorte. Era necessário alterar o trabalho da maioria dos departamentos da empresa e, como você sabe, uma variedade de métodos.

Uma das unidades problemáticas era o suprimento. Ainda não entendo por que é tão difícil - a função é simples. Então eu ainda estava interessado em scrum e decidi usá-lo para compras.

Mas ele imediatamente encontrou contradições metodológicas. Programadores são uma coisa - cada tarefa é única lá e vale a pena ser escrita em um adesivo e suspensa em um quadro negro. E quais são as tarefas dos fornecedores? Compre cem buchas? E amanhã - novamente para comprar cem buchas? E depois de amanhã?

Em suma, adesivos não são isso. E o diagrama de combustão não é isso. O Scrum foi projetado para a implementação do projeto, e o que é um projeto? Este é algum tipo de atividade que um dia terminará. Deve terminar, nesse sentido, esse é o objetivo.

E aqui - as compras. As compras podem terminar? Bem, apenas com a empresa. Então, quais são as compras? Não é um projeto, mas um processo. Mas o processo é uma palavra mais ou menos, porque também dá uma certa completude, e há um começo e um fim para ela. E entre eles - um intervalo para fumar, a Internet e a comunicação na cozinha.

O Sr. Presidente deu uma resposta quando falou sobre seu trabalho como primeiro-ministro em 2008-2012. Ele disse: ser o primeiro-ministro - como permanecer sob uma cachoeira de infinitas tarefas, problemas e objetivos. O trabalho nunca acaba. Quantos não tentam, sempre haverá algo a fazer.

O que é uma cachoeira? Este é um fluxo. Então a idéia de fluxos apareceu. Obrigado, Vladimir Vladimirovich.

Como eu gostava de scrum na época, não queria deixar esse nome e chamei a metodologia da cadeia de suprimentos de "scrum alemão" primeiro (porque estava fortemente envolvida no controle, o que os alemães amam mais do que qualquer outra coisa), então - "Kazakh Scrum" (então, para rir) e, finalmente, "streaming Scrum".

O ponto é simples.As tarefas para o fornecedor sempre vêm de fora - das necessidades de vendas e produção. O sistema prioritário para essas tarefas é muito simples. E a essência do trabalho é ainda mais simples - da cerca ao almoço.

Há necessidade de buchas - encomende buchas. Precisamos de parafusos - bem, você sabe o que fazer. E assim por diante, até o infinito. Porque o fluxo.

E o controle, que ficou longo e firmemente preso na garrafa, forneceu as métricas corretas e os indicadores individuais. Logo ficou claro que os antigos fornecedores experientes trabalham muito pior do que as "garotas" que simplesmente aceitam e fazem, e não falam sobre "como costumava ser".

O resultado foi impressionante em qualidade e velocidade de conquista - em um mês, eles encheram o armazém de remessas para um nível que antes era inatingível durante os anos de gerenciamento "comum".

Bem, aqui, em algum momento, ocorreu-me que não há projetos de automação interna, mas há um fluxo. A divisão da automação interna em projetos é uma convenção que foi herdada do grande amor de 1Snikov pelo PMBOK. São necessários projetos onde haja dinheiro, prazos, orçamentos, formalidades e burocracia. Se tudo isso está na automação interna, é óbvio que algo precisa ser feito.

Em geral, os córregos e seu gerenciamento entraram firmemente na garrafa. Olhando para o futuro, direi que o nome Flowcon é derivado da frase controle de fluxos.

Teoria das restrições do sistema (CBT)

A teoria das restrições do sistema de Goldratt é um princípio que diz que em qualquer sistema existe uma restrição, o link mais lento cuja velocidade determina a velocidade geral do sistema. Bem, vários métodos baseados nesse princípio foram desenvolvidos pelo próprio Goldratt e seus seguidores. Por exemplo, a técnica Velocity descrita no livro "The New Goal" envolve TOC e Lean.

Obviamente, o princípio principal passou da CBT para a garrafa - entender a existência de restrições e os meios de trabalhar com ela. Não estou escrevendo conscientemente "removendo restrições", porque A TCC envolve não apenas a eliminação, mas também a proteção de restrições e, às vezes, sua criação artificial.

Foi o sumário que me fez olhar não apenas para a fase da tarefa, mas também para o “kit” - o que acontece antes e depois do trabalho do executor direto. Não é nenhum segredo que geralmente leva 15 minutos para concluir uma tarefa e leva alguns dias para aceitar, coordenar, aceitar o resultado. E todos esses poucos dias, o cliente, ou o iniciador da tarefa, está esperando.

Esses estágios burocráticos, dentro do ciclo de vida da tarefa, podem ser analisados ​​sob diferentes ângulos. O TOC dirá que essas são limitações porque elas tiram o máximo proveito da velocidade de geração das unidades do alvo. O mesmo gerenciamento de limites dirá que o problema é a presença de limites extras, neste caso, entre as pessoas envolvidas na coordenação. Muito tempo é gasto para superar esses limites.

Os pontos de vista são diferentes, mas o resultado é um - a tarefa é resolvida proibitivamente por muito tempo. E o alinhamento é apenas um exemplo. E a escolha da tarefa de um programador quando a "newsletter" é proibitivamente longa? Isso não é uma limitação? E a escolha errada de um executor, quando tarefas do mesmo tipo sempre chegam ao mesmo executor e uma linha super longa é construída à sua frente?

Métodos específicos do sumário também entraram no frasco, por exemplo, usando um buffer para determinar quando uma tarefa deve começar a funcionar se tiver um prazo. Mas o principal na TCC, é claro, é o princípio, não os métodos. O próprio Goldratt escreveu sobre isso no artigo "De pé sobre os ombros dos gigantes".

De pé sobre os ombros dos gigantes

Este é um artigo tão famoso de Goldratt, no qual ele coloca tudo em seu lugar, inclusive - com suas palavras de Goldratt, ele conta quem são esses samurais decentes. Não vou recontar o artigo, ele está disponível publicamente na Internet.

Darei apenas uma citação-chave.

“Há uma diferença entre as soluções aplicadas (aplicativos) e os conceitos fundamentais nos quais essas soluções são baseadas. Os conceitos são gerais, as soluções aplicadas são a adaptação de conceitos a um ambiente específico. Como já vimos, essa adaptação não é simples e torna necessário o desenvolvimento de certos elementos da solução. Devemos lembrar - a solução aplicada é baseada nas premissas iniciais (às vezes ocultas) sobre um ambiente específico. Você não deve esperar que esta solução de aplicativo funcione em um ambiente para o qual as premissas originais não sejam verdadeiras. "Podemos economizar muito esforço e evitar decepções se formularmos cuidadosamente essas premissas iniciais".

Se, com suas próprias palavras, Goldratt diz o mesmo que samurai e pensamento sistêmico: não há necessidade de fantasiar, não há necessidade de gritar “scrum para sempre” ou “TOS - besteira”, porque você sempre estará errado. Pegue e tente, e não esqueça que nenhum método puro lhe convém. Mesmo assim, você deve observar, pensar e se ajustar.

Observações

Apresentando a garrafa em diferentes equipes, eu assisti bastante. Descobriu-se que isso não é apenas simples e interessante, mas também útil. Então a garrafa foi enriquecida com vários métodos, práticas e hacks da minha própria invenção. Sinceramente, entendo que não inventei nada de novo e, com certeza, alguns métodos descrevem esses métodos, mas não há vida suficiente para ler todos os livros.

Por exemplo, muito foi escrito sobre a destrutividade de escolher uma tarefa. E se a tarefa for selecionada, mas for necessário decidir como implementá-la, o programador, por exemplo, poderá passar muito tempo até a hora certa, e ele não fará a primeira opção disponível.

Como escreveu Maxim Dorofeev, autor das técnicas Jedi, em uma imagem engraçada, qual é o sentido de esperar que o prazo seja cumprido através de * opu, se você puder fazê-lo imediatamente *, mas haverá tempo para consertar tudo?

Tenho visto repetidamente, tanto em mim quanto nos outros, que a escolha de uma solução para um problema pode levar dias. Além disso, as opções podem ser completamente idênticas em desempenho, otimização e conveniência do usuário. Mas algo não toma nenhuma decisão, e é isso. Trabalhe - por 15 minutos e reflexão - como se estivesse construindo um foguete.

Existem muitos exemplos e todos influenciaram a garrafa. E eles continuam a influenciar, porque depois de entender que minhas próprias observações não são piores que os livros, não posso mais parar - não há limite para a perfeição.

Automação impiedosa

Depois de reunir todo o meu conhecimento em uma pilha, criei uma nova versão do sistema de gerenciamento de tarefas, comecei a aplicar todo o conhecimento da garrafa e obtive um resultado inesperado - a produtividade da equipe de programadores aumentou 4 vezes. Provavelmente, apenas os preguiçosos ainda não assistiram ao vídeo dos meus relatórios sobre este tópico - uma e duas vezes .

Na verdade, essa experiência me levou a distribuir a garrafa como uma técnica. Comecei a sistematizar informações e métodos, escrever artigos sobre a garrafa e seus métodos e falar sobre minha prática.

Arranjo para um novo sistema

Após essa experiência, mudei para uma empresa puramente de software e, é claro, continuei a prática de usar a garrafa. Mas enfrentei um desafio interessante - eu não tinha um sistema de gerenciamento de tarefas comigo, no qual obtive uma aceleração de 4 vezes.

Primeiro, sentei-me e fiz um analógico simplificado, em 1-2 dias. Quando você conhece a técnica, isso não é um problema, especialmente se você não precisa escolher sua conveniência, interface etc.

Mas não precisei trabalhar com esse sistema por muito tempo, porque nossa empresa se comunicava com os clientes por meio do GitHub. Se você souber, também existe algum tipo de gerenciamento de tarefas chamado Problemas.

O desafio se tornou ainda mais interessante. Uma coisa é criar o sistema você mesmo, do zero, e outra é adaptar o existente para que ele atenda aos requisitos da metodologia. Apesar de você não poder alterar nada, apenas uma interface e API padrão estão disponíveis.

Então eu comecei com a API. Não quer dizer que seja chique, mas fornece dados suficientes. O primeiro problema acabou sendo a impossibilidade de indicar a avaliação do problema na forma de um número. Eu tive que passar pelos rótulos (rótulos) - eles são do tipo string, mas podem ser transformados em números por um script externo. Escrevi esse roteiro e o usei por vários meses - ele desenhou um gráfico de eficácia.

Mas existem problemas que não consegui resolver no GitHub. Por exemplo, priorização. Existem tags, marcos, projetos. Teoricamente, com a ajuda deles, é possível identificar qual tarefa é mais importante, mas o uso dessas informações é extremamente inconveniente - você não pode classificar por rótulos. Eu precisaria criar outro script que retire tarefas por meio da API, classifique e exiba a lista correta.

Em geral, o ramo acabou sendo um beco sem saída. Vasculhei outros sistemas de gerenciamento de tarefas on-line - os problemas são semelhantes. Em todos os lugares há a capacidade de inserir e armazenar dados, mas poucas ferramentas de configuração - ou seja, a configuração transforma os dados em um sistema de controle. Em todos os lugares há uma API e, através dela, você pode criar seu sistema, mas a questão é: por que o sistema deles? Apenas como uma fonte de dados?

Esse dilema ficou na minha cabeça por vários meses. Fazer ou não? Adapte a técnica ao GitHub criando sua própria mancha? Ou para outro sistema? Na sua forma pura, ninguém é adequado, mas não pode ser adaptado, em um tempo razoável. Sim, e use scripts externos já esgotados.

Mas, apesar do dilema, a experiência foi bem-sucedida. A garrafa funcionou muito bem por si mesma, embora em um sistema bastante curto, e acelerou o trabalho - nas primeiras 4 vezes, depois nas 6, chegou a 10. É claro que o coeficiente depende do ponto de referência, mas parei de me preocupar com isso por um longo tempo - I a garrafa já provou tudo.

Transferindo para outro novo sistema

Lembrei-me então de que existe 1C no mundo e um produto maravilhoso como 1C: Workflow. Se alguém não souber, este é um programa no qual você pode configurar qualquer processo. Consequentemente, ele não contém nenhuma metodologia em si, apenas uma técnica, e alguém deve contar uma técnica.

Aqui, apenas, as pessoas estavam indo para a próxima conferência 1Snu, e eu decidi participar lá. Peguei um fluxo 1C: Document vazio e padrão e comecei a montar minha própria metodologia - uma garrafa. Honra e elogios 1C: Gerenciamento de documentos - demorou várias horas para configurar, e temos um sistema de gerenciamento de tarefas bastante decente que corresponde muito à garrafa.

Na conferência que ele falou, as pessoas gostaram, muitos se interessaram pela técnica. É verdade que poucas pessoas usam o 1C: gerenciamento de documentos para gerenciamento de tarefas - isso foi uma surpresa para mim. Eles usam alguns sistemas on-line nos quais nada pode ser configurado corretamente, e não existe uma metodologia inteligível, além do conceito de eficiência. Oh bem.

O resultado ainda é positivo. Ele, juntamente com o uso de tarefas no GitHub, mostrou que a garrafa pode ser completamente integrada a outros sistemas. Por isso, temos consultoria e vários projetos para acelerar as equipes em seus próprios sistemas.

Sistema próprio

A consultoria é, obviamente, divertida, mas longa e cara. A maioria das pessoas não sente muito por jogar fora seu antigo sistema de gerenciamento de tarefas, que é de pouca utilidade. Bem, as pessoas querem dois em um - e a metodologia e o programa, nos quais "tudo está de acordo com a metodologia".

Portanto, nos sentamos para escrever nosso programa de gerenciamento de tarefas, claramente afiado embaixo da garrafa. Existem poucas configurações, porque elas podem expulsar a garrafa do programa, e este será o próximo sistema de gerenciamento de tarefas, mais como um notebook.

Curiosamente, o desenvolvimento do programa começou imediatamente a dar feedback à metodologia. Algumas coisas tiveram que ser jogadas fora da garrafa, outras - adicionadas, alguma coisa - mudadas. Obviamente, nós mesmos mudamos rapidamente do GitHub para o Flowcon.

E flui novamente

Eu nunca dirigi uma empresa antes. Na verdade, ainda não posso dizer que estou no comando - há dois de nós aqui, e os direitos e responsabilidades estão divididos aproximadamente pela metade. Mas temos que lidar com todos os problemas da vida da empresa, e não apenas com o desenvolvimento ou implementação.

Temos o desenvolvimento de software e serviços, finalizando produtos antigos, apresentando novos clientes, vendas líquidas sem serviços, dando suporte a clientes antigos, marketing, negociações, exposições com seminários, questões domésticas, como dinheiro, etc. Em suma, somos uma empresa em miniatura.

Esse estado de coisas nos fez reconsiderar a garrafa e introduzir duas novas entidades - fluxos e equilíbrio.

Todo tipo de atividade que eu tenho que fazer é um fluxo. Por exemplo, preciso programar novos produtos, resolver problemas de clientes em implementações e escrever artigos. Sou uma pessoa apaixonada, como qualquer programador, por isso não é tão difícil, mas estou muito relutante em alternar entre esses tópicos.

Eu gostaria de me sentar, por exemplo, para desenvolver um novo produto, e não sair por uma semana. O que vai acontecer? Não haverá dinheiro, porque o diabo conhece o novo produto quando começa a vender. Devemos mudar para trabalhar com clientes.

Se você se empolgar em trabalhar com clientes, também ocorrerá um colapso, porque construir um negócio com os mesmos serviços é bastante arriscado.

Bem, envolva-se em escrever artigos - geralmente cuspa. Mas então não haverá produtos, nem dinheiro. Portanto, você precisa se conter. No começo, ele fez isso com um palpite, muitas vezes estava enganado, empolgado e recebeu falhas. E então eu percebi que estes são fluxos, e tudo se encaixou.

Existem fluxos que podem ser medidos e planejados. Por exemplo, 100 horas por mês - para serviços, 300 pontos - para o desenvolvimento de novos produtos e entre - 4 artigos. Cada fluxo tem sua própria unidade e método de medição e seu próprio objetivo. E a garrafa deve equilibrar esses fluxos, garantindo o desenvolvimento uniforme da empresa.

Obviamente, não existem três fluxos, mas mais - tanto conosco como com você. E é necessário equilibrar tudo para quem deseja desenvolvimento sustentável, construído sobre uma estratégia, e não no contexto atual e na extinção de incêndios.

Portanto, a garrafa evoluiu de uma técnica de gerenciamento de tarefas para uma técnica de gerenciamento da empresa. Bem, ainda não está virado direto - esse processo ainda está em andamento, mas os resultados são impressionantes.

Gerenciamento de desenvolvimento

Anteriormente, eu não tinha que lidar com o desenvolvimento de produtos de software de uso em massa, in a box ou serviços. Portanto, a garrafa não continha métodos específicos para esses tipos de atividades.

Apareceram lacunas quando tivemos um problema - trabalhamos muito e rapidamente, e os produtos não entram no mercado. Como dizem em piadas sobre scrum, resta entender que tipo de porcaria estamos fazendo com tanta velocidade.

Eu tive que ajustar a garrafa - para introduzir o conceito de lançamentos e reconstruir o sistema de priorização baseado neles. Afinal, um release não é um projeto e nem uma tarefa, mas um tipo de contêiner de outras tarefas que precisam ser realizadas para que o release ocorra. E o lançamento, principalmente o primeiro, é o acesso ao mercado. Até que isso aconteça, ninguém verá o produto e, consequentemente, não haverá feedback nem dinheiro.

Quem mais esqueceu?

Eu sinto que é hora de terminar. Se você ler neste lugar, terá muito respeito. Ainda não escrevi sobre muito, mas a principal coisa, como, se refletiu neste material.

Ainda existem várias técnicas e práticas que afetaram a garrafa, mas não as listarei. Talvez um dia eu faça algo como um glossário ou uma lista de referências - para aqueles que respeitam fortemente todos os tipos de abordagens científicas, índices de citação e "confiar em métodos mundialmente famosos".

Sim, queridos autores dos métodos dos quais tirei algo útil para a garrafa, mas não mencionei neste artigo, peço desculpas por isso.

Qual é o resultado?

Como resultado, temos uma garrafa - uma mistura explosiva das melhores práticas de gerenciamento que melhora a eficiência. E existe exatamente para aumentar a eficiência.

O que é importante para mim pessoalmente é uma mistura, um conjunto, não uma sequência. Você pode aplicar todos os métodos, você pode - apenas um, ou meio, de sua escolha. Qualquer método, por si só, aumenta a eficiência. Um mais, outro menos.

Como já mencionado no artigo, ao longo dos anos de prática, tentei partes da garrafa em diferentes empresas e, mais importante, em tipos completamente diferentes de atividade humana. Havia programadores, engenheiros de projeto, serviços de qualidade, suprimentos, vendas e produção, contadores, economistas e gerentes, e quem diabos sabe quem mais.

É claro que cada profissão precisa de seu próprio conjunto de métodos para a garrafa e de sua própria automação. Mas você pode escolher o kit certo para todos. Mas o mais importante - a garrafa está se desenvolvendo e em um ritmo acelerado. Porque ele foi além dos limites da minha prática e começou a enriquecer rapidamente com o feedback de outras pessoas, empresas e profissões.

Existem até pessoas que pegaram uma ou duas idéias de materiais publicados e as colocaram em prática. O que é especialmente interessante é que eles não me escrevem sobre isso, mas se cruzam acidentalmente em algum lugar de um fórum ou conferência, falam honestamente sobre suas experiências e não têm vergonha de dizer que tiraram idéias da garrafa.

Então, tudo ficará bem.