Quase certo, mas acho que o pessoal de vendas ou finanças também não tem muito esse poder de compra. Por isso todo mundo acaba usando as ferramentas permitidas pela empresa ou planos gratuitos e, no fim, precisa vender a ideia para o chefe
É preciso convencer dizendo que economiza tempo, torna os projetos mais transparentes e reduz a liberdade
É bem provável que esse seja um dos motivos de o Excel ser tão amplamente usado. Ele também é a ferramenta mais poderosa que o TI corporativo costuma permitir
Você descobre isso quando trabalha em vendas ou finanças e tenta obter autorização para instalar o WSL no PC. Apps web também são populares porque o TI da empresa precisa conhecê-los para conseguir bloqueá-los
Um gerente de marketing talvez consiga pagar o Basecamp com o próprio cartão, mas, para trazer uma ferramenta auto-hospedada, o assunto cresce, porque precisa passar pela política de TI de “nós gerenciamos os computadores e nós decidimos a forma de trabalhar”
O motivo de o Excel ser amplamente usado é literalmente que qualquer pessoa consegue usá-lo. Ao contrário de um banco de dados, aquilo que você cria aparece em uma forma visual diretamente visível
Ele vem incluído em todas as licenças m365, e licenças perpétuas também foram relativamente baratas por muito tempo
Quando alguém fala em permitir WSL para a equipe de vendas, dá vontade de perguntar se já trabalhou com vendedores de verdade. Em 99% das empresas, mesmo vendedores com alguma familiaridade técnica mal conseguem enviar um anexo por e-mail sem ajuda; não sei o que fariam com WSL
Em geral, é isso mesmo. A empresa não aprova a compra de um livro individual, mas aprova uma assinatura de plataforma de aprendizado
Aprovar todas essas pequenas compras dá trabalho demais e, se não houver revisão, assinaturas não usadas se acumulam por toda parte, ou a empresa acaba comprando muita coisa que não ajuda muito
Pela minha experiência, o departamento de vendas até podia ter boas ferramentas em nível de área, mas não tinha muito poder de compra
Já o marketing parecia ter bastante poder de compra, talvez porque o trabalho em si esteja ligado a comprar todo tipo de coisa
Mesmo um chefe pode ter de vender a ideia para níveis mais altos para conseguir aprovação de compra de uma ferramenta, o que pode ser trabalhoso. US$ 80 por usuário por mês é praticamente grátis em comparação com custo de pessoal, mas ainda assim sempre vira uma barreira
A razão pela qual é difícil comprar aplicações auto-hospedadas é que o TI precisa se responsabilizar por custos de servidores, rede e armazenamento, instalação, upgrades, operação e suporte, login único baseado em AD, e-mail, Slack, backup e recuperação, exportação e migração de dados, além de cibersegurança
Se apenas uma aplicação for invadida, todo o TI da empresa pode ficar em risco; mesmo aplicando isolamento ou zero trust, a superfície de ataque e os custos de segurança aumentam
Na prática, comprar uma aplicação auto-hospedada é a parte fácil; o difícil é operá-la de forma estável todos os dias pelo período exigido pelo negócio. Em alguns casos, há exigências legais de manter dados por muito tempo
Mesmo que a ferramenta tenha sido solicitada pelo TI de negócios, talvez eles consigam cuidar de parte da gestão técnica, mas muitas vezes não têm tempo ou são desenvolvedores, não administradores de sistemas e redes
No fim, é preciso usar um sandbox separado do TI corporativo, abrir mão de recursos convenientes como backup e AD, ou implementar e manter tudo por conta própria como shadow IT
Por isso acho que um dos motivos do crescimento de SaaS e cloud foi externalizar esses custos
Se você precisa brigar para comprar um livro de US$ 50, provavelmente escolheu a empresa errada
Dito isso, alguns desenvolvedores criaram, com cartão, uma conta não oficial no Notion para testes internos e fizeram nela um documento importante de visão geral, depois compartilharam o link
Metade da empresa que tentou ver o documento acabou criando contas implicitamente, e no mês seguinte chegou ao CFO uma fatura de US$ 10 mil
A história de que desenvolvedores não devem ter poder de compra geralmente começa assim
Isso é apenas um exemplo de modelo de preços predatório e dark patterns
Há um motivo para muitas empresas de SaaS não oferecerem bem opções de pagamento antecipado ou teto de custo fixo. É quase uma fraude
Não sei quem acha uma boa ideia um sistema em que alguém pode ser cobrado só por clicar em um link. E se o cartão nem tinha um limite mensal razoável, toda a configuração é absurda demais
É difícil acreditar que isso seja “o começo da história de por que desenvolvedores deixam de ter poder de compra”
Para desenvolvedores, ou qualquer pessoa, comprar ferramentas diretamente muitas vezes pode ser uma otimização local à custa da organização inteira
Por exemplo, as ferramentas ficam fragmentadas, e não dá para encontrar informações com uma única busca, ou cada equipe precisa fazer login separadamente em ferramentas diferentes
Quando as equipes gerenciam separadamente ferramentas que contêm propriedade intelectual da empresa, isso vira um pesadelo de compliance quando o objetivo é conformidade com SOC
Comprar livros ou materiais de estudo me parece bom
Falando como alguém que já decidiu gastos trimestrais de mais de US$ 100 milhões em hardware, software e serviços de engenharia, se você cria ferramentas para desenvolvedores, primeiro precisa fazer com que os desenvolvedores atuais as considerem muito úteis e passem a defendê-las com força
Não deve tocar em itens de veto como contratos opacos, lock-in, segurança de dados e privacidade, integração com login único e autenticação
O preço também precisa fazer sentido. Um preço que cresce linearmente com alguma variável provavelmente não faz sentido na planilha financeira. Cobrança mensal por desenvolvedor é fácil de entender; licenças flutuantes para toda a empresa são melhores; em alguns casos, uma taxa fixa ilimitada para toda a empresa faz mais sentido
Mesmo nesse último modelo, custos de consumo como computação e armazenamento em cloud ainda podem ser repassados. Se for possível implantar diretamente na conta cloud do cliente, isso também resolve questões de segurança de dados e privacidade
É preciso oferecer controles de custo, como teto de cobrança, limite de uso, restrições a configurações que geram cobranças caras e relatórios de uso suficientes
Fazendo bem, também é possível fechar contratos de vários anos com gasto comprometido. É preciso manter a confiabilidade do serviço e fazer revisões trimestrais com grandes clientes para entender satisfação e necessidades não atendidas
Também é possível oferecer e cobrar por serviços profissionais avançados, como engenheiros dedicados e suporte. Eles têm alta rentabilidade e às vezes são essenciais para conquistar ou manter um cliente específico
Como o produto pode ser controverso dentro da empresa cliente e opositores podem fazer a adoção fracassar, se serviços profissionais cuidarem da integração e implementação inicial, isso reduz a intervenção dos gatekeepers de TI e ajuda a chegar aos usuários reais
É melhor não tentar vender produtos que o cliente acredita fortemente que pode construir por conta própria. Mesmo que esse julgamento esteja errado, você pode até vencer no começo, mas provavelmente perderá no fim
O item 7, sobre construir ou comprar, geralmente não é tão preto no branco. O caso mais difícil é quando já existe um produto interno e você quer substituí-lo ou adicionar uma nova funcionalidade
A questão é quando avaliar o retorno sobre o investimento de construir versus comprar
Comprar um produto com custo de integração muito alto é, na prática, quase o mesmo que construir. A integração exige tempo de desenvolvedor, e esse tempo poderia ter sido usado em outras coisas ou no próprio produto
Seria bom se isso ficasse claro durante a integração de prova de conceito, mas mesmo nessa etapa é necessário tempo de desenvolvedores para executá-la
Depende da empresa. Em uma empresa em que trabalhei antes, a política era: “Compre simplesmente o que for necessário para facilitar o trabalho — livros, licenças, até hardware. Como o custo administrativo usado na tomada de decisão sai mais caro, o padrão é aprovação imediata.”
Os desenvolvedores saíram comprando sem controle? Não; compraram apenas no mesmo nível de antes da política. Na prática, a vida ficou mais fácil.
Era como tratar livros, licenças e hardware como materiais de consumo, tipo canetas ou papel. Para softwares locais pequenos, como uma IDE, isso em geral pode funcionar.
É preciso partir do pressuposto de que se confia ao desenvolvedor privilégios de administrador, ou que o TI da empresa pode permitir a instalação.
Dá para dar um orçamento pequeno a todos ou gerenciar por equipe/departamento, mas no momento em que passa a exigir integração com o TI corporativo, isso deixa de funcionar bem.
Acho esse modelo bom e não estou dizendo que ele simplesmente não funciona, mas uma explosão repentina de compras não é o único modo de falha.
Se deixar por 10 ou 20 anos, pode parecer muito diferente. A elevação de custos lenta e invisível pode se acumular, e também pode virar uma cultura em que pessoas que gastam um pouco menos acabam tendo de comprar coisas para não fazer os outros parecerem desperdiçadores.
Há muitos mecanismos sutis que incentivam o aumento de custos, então é preciso algum dispositivo que empurre na direção oposta. Vejo isso como um problema ainda não resolvido.
Uma possibilidade seria definir um limite de orçamento generoso, mas deixar claro que isso não significa que ele deva ser gasto por completo, e criar uma regra para doar, no fim do ano, uma certa porcentagem do valor restante a uma boa causa aceitável para todos.
Algo como: “Você pode comprar o livro. Só lembre que, por causa dele, a doação para pôneis vai diminuir em 5 dólares.” Se for para peixes-boi, corro o risco de acabar trabalhando em um Chromebook.
O problema está em o gerente se meter em todas as decisões. As pessoas acham que os gerentes estão lá para ajudar, mas eles criam mais problemas do que resolvem.
Na melhor das hipóteses, muitos são incompetentes; é melhor reduzir alguns gerentes e usar esses salários como orçamento discricionário. Todo mundo sai ganhando.
Na minha empresa atual, há algumas pessoas com perfil de RH que cuidam desse tipo de compra. Você manda por e-mail o link do hardware ou software necessário e eles entregam na sua casa.
Eu não preciso saber nada sobre o processo de pedidos e entregas da empresa, então foi o melhor modelo que já vi até agora.
Tive uma experiência parecida. Deram cartão corporativo para todo mundo e incentivaram o uso.
Passei por esse problema uma vez quando era funcionário. Eu queria um ThinkPad, mas a diretoria insistia em um Dell horrível; no fim, recebi o ThinkPad.
Fora isso, quando eu pedia livros ou ferramentas, simplesmente recebia, e até um teclado dividido caro era possível.
Agora que sou autônomo, simplesmente compro o que preciso. Na prática, não preciso de tanta coisa assim.
Não há tantas “ferramentas de desenvolvedor” úteis a ponto de valerem o dinheiro, e menos ainda as que valem ser integradas ao meu fluxo de trabalho. Com o tempo, essa última parte ficou mais importante.
Vida corporativa é isso.
Recebi um Dell horrível, ele quebrou, recebi outro Dell horrível, ele quebrou de novo, recebi mais um Dell.
Dizem “só temos contrato com a Dell”, e, quando você pergunta se talvez não devessem ter feito contrato com a Dell em primeiro lugar, fica aquele silêncio e só então as engrenagens começam a girar.
Você acaba percebendo que o melhor momento da vida é quando o Dell quebra. Leva 5 dias para atravessar as camadas de pedido de compra e política de pedidos até enviarem um equipamento novo, e, nesses 5 dias, você não consegue fazer nada por causa das políticas de segurança draconianas da empresa.
Então, durante 5 dias, você dorme, fala com os amigos e volta a ser humano.
Eu amo a Dell. Não quero um ThinkPad.
Para uso pessoal, uso um MacBook.
Se você precisa perguntar, é porque não tem autoridade.
Trabalhei antes em uma subsidiária voltada a vendas de uma empresa de engenharia.
No começo, eu podia pagar sem problema um almoço de 100 dólares para alguém, mas não podia comprar uma placa de 30 dólares para o meu computador.
Em contrapartida, na matriz eu podia comprar facilmente um equipamento de teste de 5 mil dólares, mas precisava preencher três formulários para levar alguém a uma lanchonete de fast-food.
No fim do meu período lá, em ambos os lugares praticamente não dava para fazer nada sem aquele formulário.
Muitas empresas bem-sucedidas de ferramentas para desenvolvedores ganharam dinheiro fazendo marketing para o chefe, não para o desenvolvedor. Isso vale para várias áreas, não só tecnologia.
Concordo muito. Em uma das grandes empresas de tecnologia, precisei de um disco rígido para uma coisa, e era mais fácil comprar um array de drives de 5 mil dólares e retirar o disco de dentro do que lançar uma despesa de 200 dólares para um único HDD.
Tentar comprar algo fora da sua área era absurdamente complicado.
Recentemente, a empresa disse “vocês têm cartão corporativo, usem”, e os EVPs aprovaram despesas relacionadas a eventos. Não era algo comum, mas achei impressionante que eles soubessem que às vezes é preciso cortar a burocracia.
Da próxima vez que eu fizer uma prestação de contas comum, provavelmente vou acabar brigando com o financeiro porque um recibo de táxi de 20 dólares não tem origem e destino.
Eu compro licenças de software diretamente e deduzo nos impostos. É o jeito de evitar falsas economias.
Graças a encontrar ferramentas adequadas e baratas e comprá-las por conta própria, ganhei prêmios no trabalho, tornei-me indispensável em certos projetos, recebi aumentos e passei a poder escolher o que queria fazer.
Minha licença da Jetbrains é o exemplo principal. É difícil imaginar refatorar código sem ela.
Quando a economia de custos da empresa parar, haverá mais concorrentes no trabalho.
Em teoria, isso também é possível no sistema tributário do Reino Unido. O formulário de Self Assessment tem um campo para declarar despesas relacionadas ao trabalho que o empregador não reembolsou.
Um empregador anterior pagava uma taxa de milhagem baixa, então eu costumava declarar a diferença na declaração de imposto.
No caso de software, não sei bem como os critérios para despesa permitida seriam aplicados.
Eu também fiz assim por anos.
Como a maioria das empresas não compra o software certo para o trabalho, acabei me tornando a pessoa mais eficaz da equipe. Porque, ao contrário dos outros, consigo resolver as coisas de forma rápida e eficiente.
Em muitas empresas, se você fizer isso e for pego, vai se meter em uma grande encrenca.
Fico curioso sobre como um funcionário W2 isento nos EUA “deduz nos impostos”.
Também fico curioso sobre outros exemplos.
Se puder ser colocado no Azure, na AWS ou no Google Cloud, a conversa muda
A pessoa não consegue comprar nem um lápis sem aprovação, mas no cloud da empresa pode gastar milhares de dólares sem perguntar
É aí que entra a mágica do Amazon Marketplace. Dá para comprar até serviços que não são da AWS, mas eles continuam aparecendo na fatura da AWS e ainda contam para o compromisso de gastos da empresa
Exato. Pedimos a um desenvolvedor para configurar um servidor FTP. Ele era um bom administrador Linux e já tinha feito isso várias vezes em VPS de 10 libras
Só que, desta vez, escolheu um serviço da AWS que custava mais de 1.000 libras por mês. Quando recebemos a fatura do cartão, virou uma grande dor de cabeça, e a cobrança do mês seguinte já estava bem avançada
Depois disso, tivemos que controlar tudo com mais rigor
Comigo é parecido. Fazer as pessoas certas avaliarem o localstack parece que vai ser uma batalha grande e difícil
Mas, se comprarmos a licença corporativa, só a economia já pagaria o custo imediatamente, então sinto a pressão de tentar, mesmo não sendo minha função principal
Para ser justo, é porque ninguém ainda descobriu como integrar terraform apply ao fluxo de aprovação do SAP
Um modelo de negócio em que o engenheiro é o tomador de decisão é perfeitamente possível. Só que ele se limita a ferramentas em que o engenheiro consegue fazer otimização local sem impacto direto fora do escopo
O IDE é o melhor exemplo. Permitir que os engenheiros da empresa tomem decisões individuais sobre IDEs para aumentar a própria produtividade pode ter um impacto global aceitável quando todas essas decisões são somadas. A Jetbrains mostra isso
Mas nem toda ferramenta é assim. O texto original trata de exemplos da segunda categoria, como Redis, Terraform e AWS
Ao contrário de um IDE, decisões individuais em banco de dados, gestão de infraestrutura e infraestrutura de cloud viram problema quando se espalham. A empresa precisa manter stacks heterogêneos, e o vendedor não consegue fechar um contrato corporativo relevante só porque uma equipe escolheu Redis
Por isso passa a ser necessário algum grau de padronização. Nesse ponto, o impacto da escolha e o tamanho do licenciamento aumentam, e não só a liderança de engenharia, mas também o financeiro, quer ter voz. E há bons motivos para isso
E, no momento em que o financeiro entra, é preciso justificar a escolha em uma linguagem que é difícil para a maioria dos engenheiros
Minha autoridade de compra funciona assim. Digo ao meu chefe: “se comprarmos esta ferramenta de desenvolvimento, vamos economizar X horas de tempo de desenvolvedor”
Aí basta que X seja grande o suficiente em relação ao preço da ferramenta. Esse método funciona bem, então usei tantas vezes que meu chefe agora já olha com ceticismo
E ele está certo em ser cético. Superestimar os benefícios, seja de uma ferramenta ou de um redesenho, é tão comum quanto subestimar estimativas de esforço, e as duas coisas provavelmente estão fortemente relacionadas
Isso não quer dizer que não existam ferramentas valiosas. Elas existem, mas são muito raras
Fico me perguntando quanto tempo levaria até o chefe dizer: “somando todas as ferramentas que você mencionou nos últimos 3 meses, você disse que economizariam um ano de trabalho de desenvolvedor; então vou cortar 1 desenvolvedor da equipe e manter as tarefas e os prazos como estão”
A resposta pode ser: “tempo de desenvolvedor não é KPI, e o salário é o mesmo trabalhando 160, 180 ou 200 horas por mês”
1 comentários
Opiniões do Hacker News
Quase certo, mas acho que o pessoal de vendas ou finanças também não tem muito esse poder de compra. Por isso todo mundo acaba usando as ferramentas permitidas pela empresa ou planos gratuitos e, no fim, precisa vender a ideia para o chefe
É preciso convencer dizendo que economiza tempo, torna os projetos mais transparentes e reduz a liberdade
É bem provável que esse seja um dos motivos de o Excel ser tão amplamente usado. Ele também é a ferramenta mais poderosa que o TI corporativo costuma permitir
Você descobre isso quando trabalha em vendas ou finanças e tenta obter autorização para instalar o WSL no PC. Apps web também são populares porque o TI da empresa precisa conhecê-los para conseguir bloqueá-los
Um gerente de marketing talvez consiga pagar o Basecamp com o próprio cartão, mas, para trazer uma ferramenta auto-hospedada, o assunto cresce, porque precisa passar pela política de TI de “nós gerenciamos os computadores e nós decidimos a forma de trabalhar”
Ele vem incluído em todas as licenças m365, e licenças perpétuas também foram relativamente baratas por muito tempo
Quando alguém fala em permitir WSL para a equipe de vendas, dá vontade de perguntar se já trabalhou com vendedores de verdade. Em 99% das empresas, mesmo vendedores com alguma familiaridade técnica mal conseguem enviar um anexo por e-mail sem ajuda; não sei o que fariam com WSL
Aprovar todas essas pequenas compras dá trabalho demais e, se não houver revisão, assinaturas não usadas se acumulam por toda parte, ou a empresa acaba comprando muita coisa que não ajuda muito
Já o marketing parecia ter bastante poder de compra, talvez porque o trabalho em si esteja ligado a comprar todo tipo de coisa
Se apenas uma aplicação for invadida, todo o TI da empresa pode ficar em risco; mesmo aplicando isolamento ou zero trust, a superfície de ataque e os custos de segurança aumentam
Na prática, comprar uma aplicação auto-hospedada é a parte fácil; o difícil é operá-la de forma estável todos os dias pelo período exigido pelo negócio. Em alguns casos, há exigências legais de manter dados por muito tempo
Mesmo que a ferramenta tenha sido solicitada pelo TI de negócios, talvez eles consigam cuidar de parte da gestão técnica, mas muitas vezes não têm tempo ou são desenvolvedores, não administradores de sistemas e redes
No fim, é preciso usar um sandbox separado do TI corporativo, abrir mão de recursos convenientes como backup e AD, ou implementar e manter tudo por conta própria como shadow IT
Por isso acho que um dos motivos do crescimento de SaaS e cloud foi externalizar esses custos
Se você precisa brigar para comprar um livro de US$ 50, provavelmente escolheu a empresa errada
Dito isso, alguns desenvolvedores criaram, com cartão, uma conta não oficial no Notion para testes internos e fizeram nela um documento importante de visão geral, depois compartilharam o link
Metade da empresa que tentou ver o documento acabou criando contas implicitamente, e no mês seguinte chegou ao CFO uma fatura de US$ 10 mil
A história de que desenvolvedores não devem ter poder de compra geralmente começa assim
Há um motivo para muitas empresas de SaaS não oferecerem bem opções de pagamento antecipado ou teto de custo fixo. É quase uma fraude
É difícil acreditar que isso seja “o começo da história de por que desenvolvedores deixam de ter poder de compra”
Por exemplo, as ferramentas ficam fragmentadas, e não dá para encontrar informações com uma única busca, ou cada equipe precisa fazer login separadamente em ferramentas diferentes
Quando as equipes gerenciam separadamente ferramentas que contêm propriedade intelectual da empresa, isso vira um pesadelo de compliance quando o objetivo é conformidade com SOC
Comprar livros ou materiais de estudo me parece bom
Falando como alguém que já decidiu gastos trimestrais de mais de US$ 100 milhões em hardware, software e serviços de engenharia, se você cria ferramentas para desenvolvedores, primeiro precisa fazer com que os desenvolvedores atuais as considerem muito úteis e passem a defendê-las com força
Não deve tocar em itens de veto como contratos opacos, lock-in, segurança de dados e privacidade, integração com login único e autenticação
O preço também precisa fazer sentido. Um preço que cresce linearmente com alguma variável provavelmente não faz sentido na planilha financeira. Cobrança mensal por desenvolvedor é fácil de entender; licenças flutuantes para toda a empresa são melhores; em alguns casos, uma taxa fixa ilimitada para toda a empresa faz mais sentido
Mesmo nesse último modelo, custos de consumo como computação e armazenamento em cloud ainda podem ser repassados. Se for possível implantar diretamente na conta cloud do cliente, isso também resolve questões de segurança de dados e privacidade
É preciso oferecer controles de custo, como teto de cobrança, limite de uso, restrições a configurações que geram cobranças caras e relatórios de uso suficientes
Fazendo bem, também é possível fechar contratos de vários anos com gasto comprometido. É preciso manter a confiabilidade do serviço e fazer revisões trimestrais com grandes clientes para entender satisfação e necessidades não atendidas
Também é possível oferecer e cobrar por serviços profissionais avançados, como engenheiros dedicados e suporte. Eles têm alta rentabilidade e às vezes são essenciais para conquistar ou manter um cliente específico
Como o produto pode ser controverso dentro da empresa cliente e opositores podem fazer a adoção fracassar, se serviços profissionais cuidarem da integração e implementação inicial, isso reduz a intervenção dos gatekeepers de TI e ajuda a chegar aos usuários reais
É melhor não tentar vender produtos que o cliente acredita fortemente que pode construir por conta própria. Mesmo que esse julgamento esteja errado, você pode até vencer no começo, mas provavelmente perderá no fim
A questão é quando avaliar o retorno sobre o investimento de construir versus comprar
Comprar um produto com custo de integração muito alto é, na prática, quase o mesmo que construir. A integração exige tempo de desenvolvedor, e esse tempo poderia ter sido usado em outras coisas ou no próprio produto
Seria bom se isso ficasse claro durante a integração de prova de conceito, mas mesmo nessa etapa é necessário tempo de desenvolvedores para executá-la
Depende da empresa. Em uma empresa em que trabalhei antes, a política era: “Compre simplesmente o que for necessário para facilitar o trabalho — livros, licenças, até hardware. Como o custo administrativo usado na tomada de decisão sai mais caro, o padrão é aprovação imediata.”
Os desenvolvedores saíram comprando sem controle? Não; compraram apenas no mesmo nível de antes da política. Na prática, a vida ficou mais fácil.
É preciso partir do pressuposto de que se confia ao desenvolvedor privilégios de administrador, ou que o TI da empresa pode permitir a instalação.
Dá para dar um orçamento pequeno a todos ou gerenciar por equipe/departamento, mas no momento em que passa a exigir integração com o TI corporativo, isso deixa de funcionar bem.
Se deixar por 10 ou 20 anos, pode parecer muito diferente. A elevação de custos lenta e invisível pode se acumular, e também pode virar uma cultura em que pessoas que gastam um pouco menos acabam tendo de comprar coisas para não fazer os outros parecerem desperdiçadores.
Há muitos mecanismos sutis que incentivam o aumento de custos, então é preciso algum dispositivo que empurre na direção oposta. Vejo isso como um problema ainda não resolvido.
Uma possibilidade seria definir um limite de orçamento generoso, mas deixar claro que isso não significa que ele deva ser gasto por completo, e criar uma regra para doar, no fim do ano, uma certa porcentagem do valor restante a uma boa causa aceitável para todos.
Algo como: “Você pode comprar o livro. Só lembre que, por causa dele, a doação para pôneis vai diminuir em 5 dólares.” Se for para peixes-boi, corro o risco de acabar trabalhando em um Chromebook.
Na melhor das hipóteses, muitos são incompetentes; é melhor reduzir alguns gerentes e usar esses salários como orçamento discricionário. Todo mundo sai ganhando.
Eu não preciso saber nada sobre o processo de pedidos e entregas da empresa, então foi o melhor modelo que já vi até agora.
Passei por esse problema uma vez quando era funcionário. Eu queria um ThinkPad, mas a diretoria insistia em um Dell horrível; no fim, recebi o ThinkPad.
Fora isso, quando eu pedia livros ou ferramentas, simplesmente recebia, e até um teclado dividido caro era possível.
Agora que sou autônomo, simplesmente compro o que preciso. Na prática, não preciso de tanta coisa assim.
Não há tantas “ferramentas de desenvolvedor” úteis a ponto de valerem o dinheiro, e menos ainda as que valem ser integradas ao meu fluxo de trabalho. Com o tempo, essa última parte ficou mais importante.
Recebi um Dell horrível, ele quebrou, recebi outro Dell horrível, ele quebrou de novo, recebi mais um Dell.
Dizem “só temos contrato com a Dell”, e, quando você pergunta se talvez não devessem ter feito contrato com a Dell em primeiro lugar, fica aquele silêncio e só então as engrenagens começam a girar.
Você acaba percebendo que o melhor momento da vida é quando o Dell quebra. Leva 5 dias para atravessar as camadas de pedido de compra e política de pedidos até enviarem um equipamento novo, e, nesses 5 dias, você não consegue fazer nada por causa das políticas de segurança draconianas da empresa.
Então, durante 5 dias, você dorme, fala com os amigos e volta a ser humano.
Eu amo a Dell. Não quero um ThinkPad.
Para uso pessoal, uso um MacBook.
Trabalhei antes em uma subsidiária voltada a vendas de uma empresa de engenharia.
No começo, eu podia pagar sem problema um almoço de 100 dólares para alguém, mas não podia comprar uma placa de 30 dólares para o meu computador.
Em contrapartida, na matriz eu podia comprar facilmente um equipamento de teste de 5 mil dólares, mas precisava preencher três formulários para levar alguém a uma lanchonete de fast-food.
No fim do meu período lá, em ambos os lugares praticamente não dava para fazer nada sem aquele formulário.
Muitas empresas bem-sucedidas de ferramentas para desenvolvedores ganharam dinheiro fazendo marketing para o chefe, não para o desenvolvedor. Isso vale para várias áreas, não só tecnologia.
Tentar comprar algo fora da sua área era absurdamente complicado.
Recentemente, a empresa disse “vocês têm cartão corporativo, usem”, e os EVPs aprovaram despesas relacionadas a eventos. Não era algo comum, mas achei impressionante que eles soubessem que às vezes é preciso cortar a burocracia.
Da próxima vez que eu fizer uma prestação de contas comum, provavelmente vou acabar brigando com o financeiro porque um recibo de táxi de 20 dólares não tem origem e destino.
Eu compro licenças de software diretamente e deduzo nos impostos. É o jeito de evitar falsas economias.
Graças a encontrar ferramentas adequadas e baratas e comprá-las por conta própria, ganhei prêmios no trabalho, tornei-me indispensável em certos projetos, recebi aumentos e passei a poder escolher o que queria fazer.
Minha licença da Jetbrains é o exemplo principal. É difícil imaginar refatorar código sem ela.
Quando a economia de custos da empresa parar, haverá mais concorrentes no trabalho.
Um empregador anterior pagava uma taxa de milhagem baixa, então eu costumava declarar a diferença na declaração de imposto.
No caso de software, não sei bem como os critérios para despesa permitida seriam aplicados.
Como a maioria das empresas não compra o software certo para o trabalho, acabei me tornando a pessoa mais eficaz da equipe. Porque, ao contrário dos outros, consigo resolver as coisas de forma rápida e eficiente.
Se puder ser colocado no Azure, na AWS ou no Google Cloud, a conversa muda
A pessoa não consegue comprar nem um lápis sem aprovação, mas no cloud da empresa pode gastar milhares de dólares sem perguntar
Só que, desta vez, escolheu um serviço da AWS que custava mais de 1.000 libras por mês. Quando recebemos a fatura do cartão, virou uma grande dor de cabeça, e a cobrança do mês seguinte já estava bem avançada
Depois disso, tivemos que controlar tudo com mais rigor
Mas, se comprarmos a licença corporativa, só a economia já pagaria o custo imediatamente, então sinto a pressão de tentar, mesmo não sendo minha função principal
terraform applyao fluxo de aprovação do SAPUm modelo de negócio em que o engenheiro é o tomador de decisão é perfeitamente possível. Só que ele se limita a ferramentas em que o engenheiro consegue fazer otimização local sem impacto direto fora do escopo
O IDE é o melhor exemplo. Permitir que os engenheiros da empresa tomem decisões individuais sobre IDEs para aumentar a própria produtividade pode ter um impacto global aceitável quando todas essas decisões são somadas. A Jetbrains mostra isso
Mas nem toda ferramenta é assim. O texto original trata de exemplos da segunda categoria, como Redis, Terraform e AWS
Ao contrário de um IDE, decisões individuais em banco de dados, gestão de infraestrutura e infraestrutura de cloud viram problema quando se espalham. A empresa precisa manter stacks heterogêneos, e o vendedor não consegue fechar um contrato corporativo relevante só porque uma equipe escolheu Redis
Por isso passa a ser necessário algum grau de padronização. Nesse ponto, o impacto da escolha e o tamanho do licenciamento aumentam, e não só a liderança de engenharia, mas também o financeiro, quer ter voz. E há bons motivos para isso
E, no momento em que o financeiro entra, é preciso justificar a escolha em uma linguagem que é difícil para a maioria dos engenheiros
Minha autoridade de compra funciona assim. Digo ao meu chefe: “se comprarmos esta ferramenta de desenvolvimento, vamos economizar X horas de tempo de desenvolvedor”
Aí basta que X seja grande o suficiente em relação ao preço da ferramenta. Esse método funciona bem, então usei tantas vezes que meu chefe agora já olha com ceticismo
Isso não quer dizer que não existam ferramentas valiosas. Elas existem, mas são muito raras