Gestores de locais de trabalho como Asana e Trello prometem utopias organizacionais. Mas revelam limitações que remontam ao chão de fábrica do século XX.
Salve esta história
Salve esta história
Quando trabalhei como redator para uma empresa de tecnologia canina, usamos Airtable e Basecamp para organizar nossos fluxos de trabalho. Em nosso próximo trabalho, a equipe de marketing nos forçou a aprender Asana (“igual ao Airtable, mas muito melhor”), mas a equipe de produto executou seu trabalho e sprints por meio do Jira. Fui demitido antes de aprender Jira, e no meu próximo emprego eles apostaram na Airtable, que felizmente eu já conhecia. Mas a eficiência ainda foi perdida e a Airtable aparentemente assumiu a culpa. Ao sair do emprego, ouvi alguém mencionar que um novo programa, o Trello, substituiria o Airtable e “mudaria tudo” para nós. Alguns anos depois voltei como empreiteiro e as coisas continuaram iguais. A empresa havia se afastado do Trello e agora era dominada por algo chamado Monday. com. Também prometeu grandes mudanças.
Se você trabalha como “faça você mesmo” – engenheiro, redator, designer, analista de dados, profissional de marketing – na força de trabalho de colarinho branco de hoje, provavelmente já se deparou com um desses produtos de software de gerenciamento de projetos (software PM). Ao fazer login, você receberá convites para colaborar com empresas como Smartsheet, Notion, Udemy, ClickUp, Projectworks, Wrike e Height. Esta lista parece interminável, mas continua a crescer. Atualmente, existem mais de uma centena de aplicativos e agendadores proprietários competindo pelos negócios das empresas, prometendo aumento de produtividade, fluxo de trabalho tranquilo e flexibilidade incomparável. E se você, como eu, passou vários anos mudando de um emprego para outro e trabalhando em equipes de projeto, teve que aceitar o fato de que a falta de comunicação e a confusão são naturais em qualquer equipe grande. Mas em uma era de trabalho cada vez mais digital e remoto, você ainda pode imaginar o “aplicativo matador” realmente vencendo. No entanto, nenhum destes serviços de software PM faz o trabalho de forma eficiente. A chave para estas deficiências reside na própria história da eficácia no local de trabalho – começando com os primeiros consultores empresariais.
Resolvendo o problema de eficiência
Antes da segunda revolução industrial, praticamente não existia produtividade.(À medida que as fábricas se tornaram mais complexas e o número de funcionários aumentou, o objetivo do capital passou a ser garantir a eficiência do trabalho. Se você associar o aborrecimento de muitas notificações do Trello à situação difícil de um maquinista montando tornos nos anos 1900 e começar a fique tonto, você não está sozinho Mas a ideia de garantir um trabalho eficaz é tão antiga quanto a própria ideia de emprego.
Foi assim que surgiu o que conhecemos como gerenciamento de projetos no século XX. De acordo com o livro de Frederick Taylor, The Principles of Scientific Management, o objectivo da gestão do trabalho “deveria ser assegurar a máxima prosperidade para o empregador, combinada com a máxima prosperidade para cada trabalhador”. Ao mesmo tempo em que Taylor, um engenheiro mecânico, saiu do chão de fábrica para se tornar um dos primeiros narcotraficantes (ou consultores) da América, outro engenheiro, Henry Gantt, popularizou e codificou os fundamentos do gráfico de Gantt – um gráfico de barras simples que transforma o cronograma de um projeto em um conjunto de linhas ao longo dos eixos x e y, com o tempo se movendo da esquerda para a direita. Também chamados de método em cascata, os gráficos de Gantt criam uma metáfora visual para tarefas, suas dependências e contingências para que você possa ver cada tarefa individual em termos de quando ela deve começar e quando deve ser concluída, em relação ao projeto geral e às tarefas futuras. ele.
Você é um designer gráfico que espera a chegada de fotos e texto antes de começar a criar um banner? Em muitos aplicativos modernos de software de gerenciamento de projetos, você pode ver essas suposições, como nos gráficos de Gantt modernos oferecidos por Monday. com, Wrike, Microsoft Project e Click Up. Asana também possui modelos de Gantt.
Bem-vindo ao WIRED Software Review, onde publicamos críticas ao artefato cultural definidor de nosso tempo.
Taylor e Gantt descobriram como gerenciar o trabalho de um motorista de fábrica, cujo trabalho, como o trabalho de Lucy em uma fábrica de chocolate, geralmente incluía uma tarefa de repetição. Mas o aumento do número de trabalhadores da informação significa um aumento no número de vagões, consultores, analistas e gerentes de estação, além de fortalecer a hierarquia. No projeto de construção, por exemplo, enquanto o reforço é instalado, uma equipe de trabalhadores de concreto pode preencher a fundação. Da mesma forma, o funcionário da fábrica não precisa ver o diagrama de Gant para fazer sua parte do widget, é suficiente para ele saber o que fazer. Eles não precisam participar da criação do cronograma. Eles não precisam interagir com o diagrama. No projeto formidável da carne Hoover (sua construção foi organizada usando o diagrama de ganta), trabalhadores que inundaram concreto, não era necessário gerenciar independentemente essa tarefa, enquanto verificava seus diagramas de gant. Nos dias anteriores ao trabalho de informações, os funcionários que executavam tarefas (participantes individuais) não precisavam governar; Eles se controlavam.
O trabalho de informação, por outro lado, é mais fácil de controlar usando os métodos desenvolvidos pela Gantt. No trabalho da informação, há um número infinito de vetores de feedback, debates, aprovação de partes interessadas e revisão, sem mencionar um número infinito de pontos de contato.(Se você acha que seu local de trabalho está cheio de gerentes, você não está sozinho). O software que imita a maneira anterior de estabelecer o design Dominos é a fonte de nossa decepção no local de trabalho e no início das soluções universais, que acabam simplesmente fazendo mais trabalho.
Maneiras críticas de mapas de estrada para opções infinitas
Você sabia que o projeto de Manhattan também faz parte da gloriosa história do gerenciamento de projetos? Problemas mais complexos requerem cada vez mais soluções elegantes, e é impossível passar de uma idéia para uma bomba atômica em vários anos sem rotas de trabalho paralelas efetivamente organizadas. Observações feitas por alguns engenheiros dentro da estrutura do projeto de Manhattan levaram à criação de um método de caminho crítico no final da década de 1950-um modelo algorítmico que cria um mini-card (um pouco semelhante a uma árvore de soluções) de todas as partes do processo de desenvolvimento ou projeto. Cada nó e caminhos recebem valores temporários e o computador decide como chegar ao final o mais rápido possível (ou mais barato), tendo concluído todas as tarefas necessárias. Combine o caminho crítico com o método PERT, desenvolvido simultaneamente com um sistema marinho dos EUA semelhante, e o gerenciamento de projetos passou para a era do computador. Na mesma época, o sistema Kanban foi desenvolvido no Toyota (traduzido de japonês – “Ads Board”), projetado para aumentar a eficiência da produção enxuta. Como sistema manual de cartões e sinais, Kanban também ganhou popularidade.
No momento em que o desenvolvimento do software era uma área mais legítima que pode ser controlada (na década de 1980), também recebemos a “Lei de Fred Brooks”, que afirma que a adição de trabalho aos projetos de programação atrasada apenas descreve lentamente eles . A verdade subjacente a essa idéia – que a “inclusão” de tarefas complexas leva mais tempo do que a salva – é um dos vários fatores que levaram os desenvolvedores de software a criar scrames, uma maneira mais flexível de comunicação durante projetos de trabalho aberto, como programação. Os scrums são possivelmente mais revolucionários do que o caminho crítico, Kanban ou qualquer um de seus antecessores, porque são um formato que corresponde à funcionalidade de pequenas equipes com metas de curto prazo. Os arranhões ajudam os programadores a executar rapidamente o trabalho e, em seguida, fazem o mesmo no próximo projeto.
Você pode olhar para um diagrama de caminho crítico e pensar: “Ei, isso se parece muito com um roteiro de produto” (uma combinação de aparência um tanto útil da parte em cascata de um gráfico de Gantt e do diagrama de caminho crítico dependente). Ou você pode olhar para um quadro Kanban e pensar: Ok, posso me acostumar com isso. Mas observe que a Asana apregoa seu domínio de Kanban, Caminho Crítico e Scrum, bem como um novo termo: ágil. O software PM apresenta-se como Frederick Taylor no final de 1800, viajando de um lugar para outro e garantindo aos proprietários de fábricas que seu sistema poderia ser aplicado igualmente à carpintaria e à lavanderia industrial. A diferença é que Taylor ofereceu uma solução adequada para um sistema, enquanto o software PM se vende como um “pau para toda obra” e “pau para toda obra”.
Mais popular
A ciência
Uma bomba-relógio demográfica está prestes a atingir a indústria da carne bovina.
Matt Reynolds
Negócios
Dentro do complexo ultrassecreto de Mark Zuckerberg no Havaí
Guthrie Scrimgeour
Engrenagem
Primeiro, dê uma olhada no Matic, o aspirador robô redesenhado
Adriane So
Negócios
As novas alegações de Elon Musk sobre a morte de macacos estimulam novas demandas de investigação da SEC
Dhruv Mehrotra
Além de prometer demais, o modelo de software PM também exige que os programas façam o que Taylor faz, mas com retornos consistentes. O atual modelo de negócios de tecnologia baseia-se na receita recorrente esperada, portanto, esses programas devem aproveitar equipes técnicas de vendas e modelos de software como serviço para atrair clientes recorrentes e garantir um fluxo de caixa previsível. As empresas podem prometer uma solução para problemas de fluxo de trabalho, mas estão vendendo um serviço.
O Wrike foi fundado em 2006, o Asana em 2008, o Trello em 2011 e o Monday. com e o Airtable em 2012. Em uma corrida armamentista de marketing, cada um encheu a Internet com seus próprios sites de conteúdo (o Asana tem seu próprio jornal falso), pagou por por análises falsas, respostas sensacionalistas no Quora e afirmações de que somente eles têm o software certo para organizar todo o fluxo de trabalho. Para cumprir essa promessa, mesmo que remotamente, o software deve ser útil para vários tamanhos, estilos e tipos de forças de trabalho.
O Wrike pode fazer diagramas de Gante ou pequenas mesas elétricas. Asana pode fazer roteiros, diagramas de cascata e tábuas de cananga. Mas o que esses programas realmente fazem sob o capô? No videogame, o mundo está modelando o mundo – Gravity atrai objetos para o chão, as conchas se comportam de uma certa maneira, seu personagem pode manter tantos objetos antes que ele tenha que sair de um. O software PM promete sistemas confiáveis para resolver problemas complexos, mas suas soluções geralmente são uma interface de usuário de superfície, sobreposta a bancos de dados relacionais (relacionados). Esses programas geralmente não “funcionam” para comandos porque são muito complicados para tarefas simples ou não são confiáveis o suficiente para as complexas, e também porque os bancos de dados relacionais não são uma bala de prata para o lobisomem de decepções no local de trabalho.
O problema é ux
Como o objetivo dos fornecedores de software como serviço é vender e reter assinatura, essas empresas são forçadas a adicionar constantemente funções individuais para resolver quaisquer problemas emergentes. Mas quando seu software é construído com base no pensamento do banco de dados, novas funções geralmente complicam o trabalho. Adicionar pensamento em um banco de dados relacional à tarefa do tipo “Preciso aposentar uma foto de um brinquedo para cães” cria dificuldades desnecessárias, a menos que o software seja realmente conveniente para o usuário e não imite os programas usuais.
Por um longo tempo, muitos desses programas (por exemplo, asana) não possuíam um botão de cancelamento. Um retocador competente, mas não muito feito, pode entrar no “cartão” em Asana e excluir acidentalmente a tarefa ou sua história, arruinando involuntariamente tudo.
Mais popular
A ciência
Uma bomba-relógio demográfica está prestes a atingir a indústria da carne bovina.
Matt Reynolds
Negócios
Dentro do complexo ultrassecreto de Mark Zuckerberg no Havaí
Guthrie Scrimgeour
Engrenagem
Primeiro, dê uma olhada no Matic, o aspirador robô redesenhado
Adriane So
Negócios
As novas alegações de Elon Musk sobre a morte de macacos estimulam novas demandas de investigação da SEC
Dhruv Mehrotra
Isso é um problema quando um usuário comum tem uma oportunidade universal para adicionar, excluir e remover tarefas, e essa é uma escolha que (ou não fez) alguém no Asana. Obviamente, você não deve excluir arquivos em seu trabalho, mas o software criado em gravações no banco de dados dificulta a adaptação a uma pessoa cujo cérebro é treinado na experiência moderna do usuário (UX).
Programas como o PM, construídos com base na mentalidade de um programador, mostram a enorme lacuna entre o modo como os computadores funcionam e a compreensão do leigo sobre como eles funcionam. Em meados da década de 1990, seria de se esperar que uma pessoa com um PC fosse capaz de navegar por árvores de arquivos ou bancos de dados, já que a interface do usuário ainda não havia atingido o nível visto em telefones e aplicativos modernos. O Gmail é tão bom agora que um Zoomer novato pode nem ser capaz de pensar em termos de árvores de arquivos ou bancos de dados relacionais, e provavelmente não será capaz de consertar essa pequena falha estranha em seu software PM. Se considerarmos adicionar uma lata de lixo ou um botão de cancelamento ao que ainda é um banco de dados, veremos uma lacuna crescente entre o conhecimento do usuário e o conhecimento do desenvolvedor, à medida que, digamos, o Gmail UX continua a obscurecer habilmente as coisas reais do computador que acontecem na Web. computador.
O botão cancelar eventualmente apareceu, mas foi acompanhado por uma janela de 20 segundos, semelhante ao Gmail. Não é rápido o suficiente? É uma pena. Muito provavelmente, esta função simplesmente armazena suas ações na memória local, colocando-as no topo da interface de forma que o tempo entre suas ações e o servidor do programa que as recebe seja o tempo que você precisa para desfazer. Do ponto de vista do servidor, você não está cancelando, apenas não está fazendo isso.
A razão pela qual existem tantas dessas empresas e nenhum aplicativo matador é porque é fácil levantar capital e criar novo software baseado no banco de dados. Jira coloca um aplicativo Web baseado em Java entre você, o usuário e o banco de dados. E a maneira como você acessa e manipula o banco de dados é projetada como um sistema de gerenciamento de fluxo de trabalho real e robusto – os fluxogramas e quadros kanban mencionados acima. Mas a maioria de nós não sabe trabalhar com bancos de dados. Se algo der errado, não começaremos de repente a pensar como programadores.
Também não somos todos gestores e nem todos pensamos em árvores de decisão. A ideia do MBA de que a gestão é uma competência que transcende as disciplinas individuais faz parte da campanha publicitária do software PM: as pessoas que vendem estes serviços afirmam que se o seu software funciona para os seus desenvolvedores, então deve ser bom para todos. O uso consistente do produto que eles criam – também chamado de “comida para cachorro” – é um motivo de orgulho para empresas como a Asana, mas para este revisor, não é um endosso tão retumbante quanto eles podem imaginar.
Fim da parte
O trabalho com informações exige cada vez mais complexidade dos funcionários, mas não deveríamos ter que gerenciar nossa produtividade sozinhos em sistemas quebrados, construídos com base em uma mentalidade de programador, apenas para realizar o trabalho.
Como não existe uma maneira única de organizar projetos e cargas de trabalho, nenhum software pode ser tudo para os trabalhadores de hoje. Você pode gostar de um desses programas – e isso é ótimo! Mas a utilidade de programas como o Jira depende dos programadores. Softwares menores e mais específicos como o Clio para advogados têm maior probabilidade de resolver problemas para um tipo específico de trabalho do que algo que força os trabalhadores a vasculhar listagens otimizadas para SEO para encontrar um conjunto de recursos que possam adaptar ao trabalho de sua equipe.
Uma grande parte do seu trabalho hoje pode ser resolver e redefinir a entropia natural no escritório, mas os prazos mal definidos permanecerão assim, sejam eles escritos em uma ficha, enviados por e-mail ou adicionados a uma “tarefa” na Asana. Se você colocar algo em um quadro Kanban digital sem informações suficientes, não será mais útil do que o que estava lá antes de você criar a tarefa. O software Workforce transforma o trabalho de gerenciamento de projetos em inúmeros miniprojetos, cada um dos quais é tão útil quanto a habilidade e utilidade individual do usuário. E não podemos esperar que cada usuário seja ao mesmo tempo criador e gestor, principalmente dada a imperfeição das ferramentas disponíveis no mercado. Quando alinhamos Trellos, Asanas, Wrikes, Airtables e infinitos clones das mesmas falhas inerentes de gerenciamento de projetos, suas diferenças importam menos do que os resultados finais – parafraseando a frase de Anna Karenina sobre família, todos os projetos de aplicativos de gerenciamento prometem a mesma felicidade, mas cada à sua maneira, cria usuários insatisfeitos.
