Mais de uma década atrás eu vi uma empresa gigantesca bater na mesa o contrato de um projeto fechado de software que estava atrasado e que ela tinha com uma consultoria. Essa história explica um dos motivos pq a Lambda3 até hoje foge de contratos assim. Explico...
A tal empresa gigante tinha muito dinheiro e muitos andares de um prédio em uma grande capital brasileira. Ela usava seu tamanho pra impor contratos leoninos aos fornecedores. Os fornecedores pequenos quebravam, os grandes, em sua soberba, se achavam mais espertos que o cliente.
Um certo dia passo por um andar cheio de gente aparentemente muito ocupada. Pergunto o que era e me explicaram. Uma grande consultoria multinacional estava trabalhando de graça há dois anos naquele andar. Era o andar inteiro pra ela.
O projeto foi vendido fechado, com prazo, escopo e custo, pela grande consultoria. O prazo era um ano, mas o projeto já estava em 3,5 anos. Quando o cliente sentiu o cheiro de sangue, atacou. Puxou o contato e ameaçou um processo na justiça.
A consultoria tremeu. Não pelo prejuízo, mas pela mídia. Pegaria muito mal ter que indenizar o cliente por um projeto mal estimado, mal vendido e mal feito.
Não seria o primeiro. Vocês já devem ter lido alguma notícia dessa consultoria fazendo isso.
Ainda assim, pega mal.
Tudo que a consultoria multinacional de renome não queria era ser conhecida com a empresa que não entregou pro cliente X.
Pra evitar a propaganda ruim fecharam um acordo. Trabalhariam até entregar. Era uma aplicação que substituiria diversas outras, unificando-as. Complexo pra caramba. Erraram a estimativa da correção (de novo) e deu nisso. Mais de dois anos trabalhando de graça.
Pior: o projeto, fiquei sabendo, não estava nem perto de entregar. Não sei quanto tempo levou, mas deve ter rodado uns cinco anos ou mais.
E o pior é que vocês nunca leram essa história na mídia, pq a consultoria tem dinheiro p/ rasgar e proteger seu nome. E que nome!
Pra mim foi uma lição do que não fazer. O cliente era espertalhão, queria passar um risco pra frente. Risco que era dele, e de mais ninguém. Mas não havia risco, o cliente sabia da certeza da falha, ele só não queria pagar a conta.
Já a consultoria tentou dar o golpe no malandro. Mal sabia ela que malandro é malandro, mané é mané. Isso lhe custou milhões.
Ao ver aquilo aprendi que eu não queria jogar aquele jogo. Eu queria entregar software e aquilo não era entregar software.
Até hoje gestores de grandes empresas contratam consultorias "de grife" pra se protegerem quando der problema. E as consultorias sabem disso e cobram caríssimo, já que não estão vendendo software, e sim um tipo de seguro. Não a toa a RFP costuma existir patrimônio pra participar.
Uma seguradora precisa de patrimônio, que é o lastro caso o sinistro ocorra. E muitas consultorias operam como seguradoras. Eu prefiro vender software, não seguro.
Por isso que fujo de projetos fechados: eles não são bons pra ninguém sério que trabalha com desenvolvimento de sw.
Não recomendo trabalhar nem em clientes nem em consultorias que operam assim. Você pode até ganhar dinheiro, mas vai ter um burn out e o risco de ser tratado como um número, um recurso, é alto.
Já viram algo parecido? Compartilhem com a gente.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
"O principal desafio de TI não é técnico, é de negócios" é uma frase que vem cada vez mais sendo repetida.
Sim, entender o negócio é importante, mas de longe não é o principal desafio. Segue a thread, vou explicar.
Não vou nunca argumentar para diminuir o desafio de negócios na tecnologia. Ele existe, é inegável. O foco aqui serão os desafios técnicos, que estamos ainda muito longe de resolver, e esses sim, os principais.
Nossa área é carente de pessoas preparadas para entregar software bem feito. Temos problemas de falta de gente, e as pessoas com frequência não tem todo o conhecimento necessário para lidar com os desafios que lhes são apresentados.
Sinto muito pelos meus amigos que trabalham com UX, pq a implementação do #pix pelos bancos, digitais ou tradicionais, está toda mal feita. Nem os modernosos fizeram um bom trabalho. É tanta coisa mal feita, que se eu não conhecesse como a linguiça é feita ficaria surpreso. 🤦♂️
Sabe a chave aleatória, gigante? Tem banco que não deixa você copiar com o celular. Você tem que copiar na mão pra outro lugar. Sério isso? 🤦♂️
E banco que não reconhece a chave já cadastrada e testada em outro banco? Só pq coloquei um `+` no email, algo que está de acordo com a RFC que define endereços de email. Erraram na regex de validação. Erro primário, amador, exemplo de clara falta de testes. 🤦♂️
Quer descobrir os melhores lugares pra trabalhar na TI? Procure quem usa agilidade de verdade, quem exige a escrita de testes, quem tem uma política clara de inclusão (e meios pra denúncia anônima de abusos). Fuja de empresas em que gerentes de projeto têm muito poder. Fio.
Mais palpável: a empresa busca diversidade na contratação, respeita as pessoas pelo que elas são, e as incentiva a serem elas mesmas no ambiente de trabalho. Se esforça por usar linguagem neutra de gênero.
Pergunte se a empresa já teve conflito com clientes (internos ou externos) por assédio. Se disser que não teve, está mentindo. Daí pergunte como ela lidou. Ela ficou do lado do lucro ou dos funcionários?
"O Giovanni pega pesado nas opiniões."
Não amigas e amigos, eu tenho mais de duas décadas nesse mercado. Não tenho mais tempo ou paciência pra quem não quer fazer um trabalho bem feito.
Quer fazer pela metade, sem agilidade, com cover your ass? Tá falando com o cara errado.
Além disso, respeito profundamente meus clientes. Não seria profissional da minha parte entregar nada menos do que todo o profissionalismo que desenvolvi ao longo desses anos. Ou não pedir o mesmo a quem trabalha comigo.
Tem muito lugar que faz assim, quem quer o fácil vá pra lá.
Isso não significa virar noites e gritar com funcionários. Isso não é profissional. Nossa área precisa de seriedade e compreensão do que significam prazos e escopos de um projeto de software. Quem grita é amador, nada profissional. Uma vergonha à nossa área.
Tratar desenvolvimento de software como linha de produção fabril continua sendo um dos maiores erros que a indústria de tecnologia comete.
Cada projeto é único.
Boas práticas só são boas dentro de um contexto.
Padronizações devem ser opcionais e atender cenários.
Segue o fio...
Frameworks devem ser extensíveis ou são inúteis, ou pior que isso, vão atrapalhar.
E qual o problema do momento atual?
A complexidade está cada vez maior. SPAs, APIM, Kubernetes, microsserviços, NoSQL, nuvem, poucos estão acompanhando.
Pra piorar, muitos talentos estão saindo do país ou trabalhando pra fora.
Pra piorar, os orçamentos estão menores (e os salários maiores - e isso é bom), os prazos estão mais curtos, então a pressão pra entregar mais é ainda maior.
Acho importante esclarecer alguns pontos sobre esse twit. Quero aprofundar alguns conceitos, depois de várias conversas que aconteceram e em mais de 280 caracteres.
O primeiro ponto que notei que causou desconforto foi a palavra "relevância". A intenção era levantar o fato de que temos brasileiros falando com brasileiros em inglês, e isso exclui quem não entende o idioma.
Não acredito que exista uma forma de medir relevância, e não tive a intenção de medir valor por popularidade. Mais sobre isso mais pra frente.