Quais são as piores economias falsas no desenvolvimento de software? [fechadas]

126

Quais são as piores economias falsas (ou seja, maneiras de economizar dinheiro que acabam custando mais do que economizam) predominantes na indústria de software e como você as combate?

programming-practices project-management Jon Hopkins
fonte
2
:( Eu já vi muitas delas com muita frequência. #
177 Tony Tony
3
programadores
cmcginty 17/11/2010
@ Casey: É um pouco relacionado, mas não totalmente. O link que você deu negocia diretamente com dinheiro, enquanto as respostas nesta pergunta tratam também de dinheiro e crenças. Exemplo, ver a minha resposta: programmers.stackexchange.com/questions/19573/...
Gan
Nunca que você acabou de visitar minha empresa .. mente; P
pramodc84
1
@ Mark - parece uma boa pergunta, vá em frente. Mais alguns detalhes podem ser bons.
Jon Hopkins

Respostas:

182

Dívida Técnica

ou seja, "basta fazê-lo rapidamente, refatoraremos mais tarde". Primeiro, porque ainda tenho que ver alguém se engajar nesse comportamento, na verdade, refatorar mais tarde. Segundo, porque fazer as coisas da maneira mais rápida, em vez da boa, torna mais difícil adicionar recursos futuros ou resolver bugs futuros, para que você perca tempo a longo prazo.

Infelizmente, muitos ainda acham que economiza ciclos de desenvolvedor para que eles façam algo rapidamente. Eu acho que é possível, mas ainda tenho que ver isso na prática.

Inaimathi
fonte
2
Não consigo contar o número de vezes que vi o gerenciamento parar os desenvolvedores (2 a 3) por um dia e depois um especialista em implantação travar consertar algo (e fazer isso várias vezes durante o ciclo de vida do produto) em vez de gastar 2 4 dias para fazer certo. Ótima resposta.
DevSolo
4
Se o tempo necessário para consertar for mensurável em dólares, por exemplo, consertar bug em um sistema de negociação de ações, a decisão da gerência se inclinará para um custo reduzido. Descobri que a proposta de "corrigi-lo agora para mantê-lo funcionando enquanto determinamos a correção correta para garantir que isso nunca aconteça novamente" satisfaz a urgência baseada em custos e também obtém o resultado certo, mas às vezes é preciso lutar por isso .
JBRWilkinson
9
Temos todo o código com comentários como "Este é um truque, substitua após a demonstração", que está na base há 3 a 5 anos. Ninguém nem se lembra que foi feito neste momento, então ninguém o encontra até que alguém (eu) esteja corrigindo bugs e correndo através dele. Desnecessário dizer que esta lição objetiva me ensinou muito bem a fazer certo da primeira vez, se eu sou capaz de fazê-lo.
CodexArcanum
22
E honestamente, fico continuamente chocado com o número de vezes que nem economiza tempo de curto prazo!
PeterAllenWebb
6
@Jorg - Hein? "Dívida técnica e dívida de projeto são sinônimos, metáforas neologísticas que se referem às conseqüências eventuais da arquitetura de software slapdash e do desenvolvimento de software apressado". pt.wikipedia.org/wiki/Technical_debt É exatamente a isso que estou me referindo. Um título mais específico talvez fosse "Incorrer em dívida técnica sem intenção de pagá-lo", mas muitas pessoas nessa situação dizem a si mesmas que realmente pretendem pagar (mas não o fazem), e eu queria um título contundente. texto em negrito na parte superior. "Dívida técnica" parecia ser um resumo suficientemente bom.
Inaimathi
163

Contratar 2 desenvolvedores baratos em vez de 1 realmente ótimo. (pelo mesmo preço)

user2567
fonte
9
Este pelo menos parece ter uma base na realidade; lembre-se de que pessoas não-técnicas não sabem dizer quem são os grandes desenvolvedores (portanto, é muito provável que paguem duas vezes mais a um idiota aleatório e consultivo do que a uma superestrela real).
Inaimathi
112
Ou infelizmente, apenas contratar um um barato ...
DevSolo
4
... ou contratar um guru onde dois manequins fariam o 1,5 do que o guru faz por 1,0 do salário do guru: /
bobah
14
Você não recebe 75% de um guru de um manequim , e qualquer programador realmente bom faz o que é necessário sem ser esnobe.
precisa
8
Os programadores de 10x ou 100x são um valor incrivelmente incrível para o dinheiro; eles só recebem 1,5, talvez 2x. Como Michael Lopp (Rands in Repose) diz, se você contratar apenas um deles em toda a sua carreira, é uma vitória líquida.
precisa
85

Meu exemplo seria o completo oposto do exemplo de NimChimpsky , a saber:

Tentando desenvolver internamente algo que possa ser comprado de prateleira.

Normalmente, isso ocorre devido a uma falha na verificação do mercado para ver se já existe algo que resolverá o problema. Isso pode ser composto por desenvolvedores que gostam de "mergulhar" na codificação antes de fazer qualquer pesquisa e por gerentes de projeto que não consideram esse tempo = dinheiro.

Um dos exemplos mais comuns que já vi em meu campo, desenvolvimento web, são empresas que tentam desenvolver e sistema interno de CMS. Eles invariavelmente começam pequenos, mas logo ficam inchados e fora de controle à medida que os recursos são aparafusados, enquanto o tempo todo há muitos produtos e estruturas gratuitos disponíveis, o que seria muito mais adequado.

Dan Diplo
fonte
17
Só porque pode ser, não significa que deveria ser. Um CMS básico, bem, sim, por que reinventar a roda. Mas quando você começa a falar sobre sistemas de grande escala e modelar processos de negócios complexos - por que tentar encaixar um pino redondo em um buraco quadrado? Especialmente se você tiver desenvolvedores e habilidades existentes em casa.
NimChimpsky
9
@NimChimpsky - Eu acho que existem exemplos válidos de ambos. Eu certamente vi pessoas quebrando seus processos de negócios e perdendo as vantagens que tinham ao tentar ajustá-las ao software de prateleira, mas também vi desenvolvedores sofrendo de síndrome "não inventada aqui" codificando coisas que eles poderiam ter baixado porque foi mais interessante para eles.
Jon Hopkins
3
@NimChimpsky Se a especificação requer um desenvolvimento sob medida, tudo bem - ela nos mantém em postos de trabalho :) O problema surge quando as pessoas não verificam primeiro se há algo já desenvolvido que se encaixa no projeto e mergulha diretamente no desenvolvimento. Um pouco de pesquisa pode percorrer um longo caminho!
quer
6
Por que reinventar a roda? Porque você é um engenheiro de rodas. Ou porque sua roda é melhor que a do próximo cara. Ou porque a roda não cabe. Veja: principalmentemaths.net/2010/03/…
Derek
2
Onde eu trabalho quase tudo OTS poderia ser comprados - e quase tudo é re-inventado em casa porque de acordo com os nossos líderes sem medo (TM) "nosso ambiente é tão complexo que nada no mercado poderia possivelmente lidar com isso". Pfeh! Mas o que o hey - paga as contas. Fomos informados ontem que um componente importante do nosso software será reescrito no próximo ano - COM UMA INTERFACE GRÁFICA! Ooooooh-aaaaaaah! Eu sou toda a-twitter ... (<pheh!>)
Bob Jarvis
73

Não há recursos dedicados para gerenciamento de projetos

Eu experimentei várias vezes quando alguns programadores foram contratados, e alguém que já tem um trabalho diurno exigente deveria ter gerenciado o projeto, mas na verdade estava muito ocupado com outras tarefas para que o projeto nunca realmente ganhasse impulso. Os programadores criavam "protótipos" e outras coisas, mas sem vantagem, grande parte estava em círculos para parecer ocupada.

Mau equipamento para novos programadores

Uma vez experimentei uma empresa em que a política era "novos programadores precisam trabalhar em um PC muito antigo com uma tela pequena até que provem que são dignos". Não surpreende que essa política tenha causado uma seleção negativa que afugentou pessoas boas que sempre têm a opção de trabalhar em um ambiente mais saudável.

user281377
fonte
19
+1. Não fornecer um bom equipamento para seus funcionários "está fadado ao fracasso", escrito por toda parte.
Terence Ponce
3
+1. Mas observe o seguinte: em muitas empresas, os orçamentos de hardware se enquadram na infraestrutura e mantidos separados dos orçamentos de desenvolvimento. O gerente de infraestrutura não será afetado por seu orçamento para ajudar a aliviar o orçamento do gerente de desenvolvimento. Eu já vi esse político desagradável acontecer várias vezes.
Fil
3
Que tal equipamentos ruins para TODOS os programadores? Meu ex-empregador pagou o salário do Vale do Silício para escrever código em computadores que eram medíocres cinco anos antes. Por causa dos prazos estipulados, eles demitiram metade da equipe há um ano e a maior parte do restante em julho - mas, rapaz, eles economizaram dinheiro em equipamentos!
Bob Murphy
1
Kaz: Todo desenvolvedor deve ter uma máquina adequada. Se comprar um novo hardware significa que o PC do novo desenvolvedor é um pouco melhor que o de outros desenvolvedores, no pior dos casos, você tem máquinas de troca, se elas são do tipo de pessoa que compensa o tamanho de um pau. As pessoas normais simplesmente não se importam, desde que tenham o equipamento que lhes permita trabalhar eficientemente. No local em que estou trabalhando, tenho um PC mais novo (provavelmente mais rápido) do que a pessoa que me contratou. As pessoas que vieram atrás de mim têm computadores ainda mais novos, provavelmente mais rápidos. Adivinha? Ninguém se importa, porque todas as nossas máquinas são rápidas o suficiente.
user281377
3
Quando o hardware é inadequado, faço questão de informar a gerência, geralmente fazendo um trabalho útil como cortar minhas unhas dos pés ou ler o jornal durante longas compilações. Eu recebo a velha máquina lenta? Claro, sem problemas. Oh, você tem uma correção rápida de erros e eu tenho que fazer a compilação? Com certeza, Mr-Manager-bwana-sahib-dude - vejo você em 90 minutos! (Uma vez um gerente me perguntou o que eu fiz o dia todo - eu disse a ele "Reconstruiu o aplicativo. Quatro vezes". "EM OITO HORAS?!?", Ele gritou. "Não, claro que não", disse eu. " que levou 10 horas" Nova máquina mostrou-se pouco tempo depois ... :-).
Bob Jarvis
71

Podemos economizar dinheiro fazendo com que os programadores funcionem como testadores / redatores técnicos

Se você está pagando salários de programador pelo trabalho de testador / redator técnico, está desperdiçando dinheiro e provavelmente obtendo um trabalho de menor qualidade do que alguém que dedicou sua carreira a essa tarefa. Além disso, quando um programador enfrenta um prazo apertado, a documentação e os testes têm grande probabilidade de serem descartados ou feitos pela metade para cumpri-lo.

BTW: Os desenvolvedores SEMPRE enfrentam um prazo apertado.

JohnFx
fonte
12
As pessoas inteligentes podem fazer qualquer coisa bem, falácia.
Jon Hopkins
3
Eu fiz a entrada de dados, embora eu certamente não iria diminuir minhas taxas por isso. Eles queriam alguém que fosse rápido e preciso para algumas entradas críticas de dados e não se importavam em pagar pelo menos taxas triplas de entrada de dados. A escolha deles.
precisa
1
Eu diria que é o trabalho dos programadores testar seu código, mas não tenho certeza se é a isso que você estava se referindo.
precisa
3
Os programadores devem testar seu próprio código, sem a exclusão de testadores dedicados, profissionais na quebra de software.
JohnFx
1
Concorde com a redação técnica, discorde sobre o teste. O teste é uma parte natural da escrita de um bom software. A redação técnica é uma mudança demais da codificação. Acho que preciso mudar muitas mudanças para passar da codificação para a redação técnica e isso parece um mau uso do meu tempo.
Adam Bruss 30/10/12
63

O código de pesquisa / leitura / escrita não relacionado ao desenvolvimento do produto é um desperdício de recursos.

Alguns programadores e até gerentes acreditam nisso. Normalmente, eles apenas fazem programação com base no conhecimento em suas cabeças, pesquisam e procuram respostas quando enfrentam problemas. Eles não melhoram continuamente seus conhecimentos proativamente. Na minha opinião, devemos sempre nos manter atualizados, e o conhecimento que coletamos nos seria útil para resolver problemas existentes e futuros. Obviamente, você deve alocar seu tempo com sabedoria para fazê-lo.

Isso também é semelhante à resposta de Dan . Alguns gerentes querem apenas que os desenvolvedores mergulhem rapidamente e desenvolvam o produto de acordo com os requisitos, sem pesquisar sobre os produtos existentes no mercado.

Gan
fonte
3
Eu gostaria de poder ter votado nisso mais de uma vez.
MAK
1
Vamos escrever uma biblioteca de GUI. Vamos criar um kit de ferramentas de mensagens. Se você NÃO VENDE o software, é apenas uma parte de uma coisa maior, pelo amor de Deus, use a implementação de outra pessoa. Pontos de segurança para o uso de uma solução de código aberto, você sempre pode corrigi-lo e suportá-lo, se necessário. Se você tiver dinheiro para comprar soluções com a fonte incluída, faça isso, mas cuidado com a baixa qualidade dos componentes de software comercial. Fornecedores raramente vender-lhe o componente duas vezes para que você pode se decepcionar uma vez que ele próprio (eu sei que eu trabalhei lugares que foram mordidas por isso antes)
Tim Williscroft
58

Em muitos casos, o offshoring custa mais dinheiro. Na minha empresa, é muito difícil conseguir novos funcionários, somos pressionados a terceirizar. Também é difícil conseguir contratados no local; há uma proporção de 3: 1 offshore para onshore que eles devem manter. Conseqüentemente, muitas equipes contratam uma dúzia de offshore e mal as utilizam, para conseguir 4 contratados no local.

Jeremy
fonte
18
+1. Minha experiência com off-shore é que, inevitavelmente, custa muito mais dinheiro do que economiza.
Adam Crossland
2
+1, mas offshore pode funcionar se usado corretamente
3
+1. Parece que temos diferentes desenvolvedores externos em cada novo projeto, ou seja, os desenvolvedores locais passam a maior parte do tempo ensinando aos novos desenvolvedores externos o modelo de domínio técnico e de negócios, além de fornecer suporte técnico. Fim do projeto e eles foram para outro lugar e começamos tudo de novo com o próximo conjunto de desenvolvedores 'baratos'.
Chris Knight
8
muitas equipes contratam uma dúzia de offshore e mal as utilizam, para conseguirem 4 contratados no local. Uau.
poolieby
1
E esquecer que a terceirização, por sua própria natureza, estenderá o prazo. Temos um controle de qualidade no exterior e pode levar de três a quatro dias para reaproveitar algo que duas pessoas no mesmo escritório poderiam refazer em menos de uma hora devido a diferenças de horário.
HLGEM
50

Loops de feedback longos!

Isso acontece com todo mundo: você constrói algo que acha incrível, e acontece que você estava errado. Esse não é o problema. O problema é quanto tempo você gasta construindo antes de descobrir que deve parar.

No nível alto, você vê esse problema com longos ciclos de liberação. Se você construir por um ano sem feedback, estará apostando o ano inteiro. Quanto mais vezes você lança, menores são as suas apostas e melhor você joga.

Mas isso também acontece nos níveis mais baixos. Como desenvolvedor, gosto muito de análises frequentes de código (ou melhor, programação de pares) porque limita a quantidade de tempo que posso continuar fazendo algo estúpido antes que alguém diga: "Ei, há uma maneira mais simples!" Pelo mesmo motivo, eu gosto que meus testes de unidade sejam executados com rapidez e frequência, para que eu possa capturar e matar bugs antes que eles cresçam.

Depois de começar a perceber a importância de pequenos ciclos de feedback, você o verá em todos os lugares. Por exemplo, a noção militar do loop OODA .

William Pietri
fonte
6
+1. Além disso: quanto maior o ciclo de feedback, menos você se lembra da tarefa. No extremo, você precisa se familiarizar novamente com toda a base de código.
Joseph Tanenbaum
Como isso é uma falsa economia? Qual é a economia pretendida?
22612 Chris Pitman
A intenção é economizar tempo "desperdiçado" nas coisas que você faz a cada ciclo. Por exemplo, construindo, testando, liberando, prestando atenção aos usuários. Essa é a desculpa, de qualquer maneira. Eu acho que está realmente enraizado em evitar desconforto.
William Pietri
É por isso que é imperativo que revisores e companheiros de dupla tenham humildade e respeito pelo codificador, tanto quanto possível. Um revisor problemático que trata mal o codificador e você pode garantir que o ciclo de feedback aumentará bastante.
27416 Jonathan Neufeld
47

Não é minha anedota, mas uma vez ouvi falar de uma loja que parou de fornecer café de graça aos seus desenvolvedores, dizendo-lhes que sempre que queriam tomar café, eles estavam livres para caminhar até a cafeteria mais próxima (algo como dez minutos cada viagem) e compre alguns.

Praticamente a definição de economia falsa.

EricBoersma
fonte
4
Isso é muito especial. Compare e contraste com alguns dos bancos comerciais de Londres que construíram um Starbucks subsidiado no prédio para eliminar o tempo necessário para sair e tomar café.
Jon Hopkins
48
Eu discordo que isso é automaticamente uma falsa economia - os 10 minutos de ar fresco enquanto caminha para fora para comprar café oxigenam o funcionário e melhoram sua concentração e a interação social (embora limitada) reduz a depressão, especialmente no inverno. Os funcionários que não tomam café porque não é gratuito, provavelmente voltarão para casa a tempo, dormirão mais e terão melhor saúde devido à redução da ingestão de cafeína.
JBRWilkinson
6
-1, uma caminhada de 20 minutos é perfeita para liberar sua mente e ter uma nova perspectiva sobre o problema.
Malfist
23
@ Malfist: Pelo que entendi, não foi apenas a caminhada de 20 minutos, mas também a espera de 15 minutos para realmente obter o café que interrompeu o trabalho. Uma pausa de 45 minutos em qualquer ponto do dia praticamente destruirá a produtividade por mais de uma hora e meia. Tudo para economizar 100 dólares por mês em café.
EricBoersma
8
20 + 15 = 35 [seis mais caracteres]
Malfist
47

Fornecer estações de trabalho de tela única porque um segundo monitor é muito caro . Mesmo que você economize apenas uma hora de trabalho por ano, uma segunda tela ainda é um bom investimento. Tenho certeza de que a minha me salvou muitas, muitas horas de trabalho.

Uma configuração de vários monitores pode tornar quase qualquer tarefa mais eficiente, não apenas tarefas de desenvolvimento. Três monitores são ainda melhores que dois, mas o efeito se torna menos pronunciado a cada tela extra.

Configurações para vários monitores:

  • diminuir sobrecarga de comutação de janela
  • permitem que você fique de olho nas coisas em execução em segundo plano (correio, compilação etc.).
  • dar-lhe uma sensação de liberdade. É como estar em um átrio versus estar em um armário de vassouras.
  • etc ...
Arjen Kruithof
fonte
2
Estava enfrentando exatamente esse problema uma vez. Escrevi um e-mail para um de nossos CEOs calculando explicitamente que, com um aumento de 5% na eficiência, eu economizaria uma quantia de dinheiro que vale o monitor em cerca de meio mês em relação ao meu lucro líquido. Este cálculo foi praticamente ironclad ... mas ... eu acho que você já sabe o final da história :)
Raffael
39

Hardware mais barato fornecido a um consultor quando o consultor custa mais de 150 $ / hora .

Colocando em perspectiva um hardware melhor, pode pelo menos tornar o trabalho 30 minutos mais eficaz por dia. Isso daria 30min * 20 dias de trabalho por mês = 600min / mês = 10 horas / mês> mais que 1 dia de trabalho = 10 horas * 150 $ / hora = 1500 $

Agora, um consultor não seria mais eficiente se tivesse um computador de US $ 1500? Isso tornaria o consultor menos irritado?

Agora, o problema parece ser que existem dois orçamentos, um para o consultor e outro para o hardware do PC.

Amir Rezaei
fonte
8
Como consultor, estive lá, fiz isso e comprei a camiseta. (Só tenho US $ 80 / hora, no entanto.) Mas ei, essa é uma das razões pelas quais gosto de contratar por hora. Ao contrário de uma posição assalariada, se um cliente de consultoria escolhe desperdiçar meu tempo e eu tenho que trabalhar mais para compensar isso, isso significa mais dinheiro no meu bolso.
Bob Murphy
2
Sem ofensa, mas se eu estiver pagando US $ 150 / hora por um consultor, é melhor ele ter seu próprio computador.
Steven Evers
8
@SnOrfus: Isso geralmente não funciona no ambiente corporativo, onde existe um controle rigoroso dos PCs permitidos no domínio. Você precisa fornecer a eles hardware.
HardCode
1
@ HardCode - Sim, suponho. Eu posso ver o ponto agora.
Steven Evers
3
@HardCode Em um projeto recente, em vez de nos adicionar (contratados) à sua rede corporativa interna, eles nos colocaram em quarentena em nossa própria linha DSL. Uma linha DSL dedicada para três desenvolvedores a US $ 40 por mês é uma mudança radical e facilitou o envio de atualizações remotamente, sem deixar a equipe de TI em pânico. Além disso, se o PC de produção executando nosso código for infectado e travar, será automaticamente nossa culpa, pois somos responsáveis ​​pela segurança de nossas comunicações e laptops pessoais. Você pode dizer ganha-ganha-ganha.
Evan Solha
38

Meses de trabalho economizam dias de planejamento

(Não investe tempo suficiente no planejamento)

serg
fonte
21
Na pós-graduação, dizia-se que algumas semanas no laboratório podem economizar uma hora de tempo na biblioteca.
precisa
7
Sim. Quando eu estava participando de uma aula de laboratório de graduação, onde identificamos substâncias químicas desconhecidas, o professor nos disse que "uma hora na biblioteca poupará quatro no laboratório". Eu o levei a sério, e foi hilário entrar no laboratório por uma hora por semana e receber olhares desagradáveis ​​dos médicos que estavam passando doze horas por semana fazendo testes de amina em compostos que claramente não eram aminas. E, quando lecionei no mesmo laboratório, vários anos depois, dei aos alunos o mesmo conselho, e poucos o seguiram.
Bob Murphy
3
Se você não planejar, você planeja falhar #
27

O mais prevalente suspeito é que os gerentes simplesmente não fornecem aos desenvolvedores as ferramentas necessárias para realizar seu trabalho com eficiência.

Basicamente, o ponto 9 no teste Joel .

richeym
fonte
2
Eu estive em projetos nos quais eles nos fazem desperdiçar uma semana ou duas, em vez de comprar, por exemplo, uma biblioteca de US $ 300 com o trabalho já realizado - e melhor (não somos "desenvolvedores de controle" onde trabalho). Ou escolha alguma ferramenta de software ", porque é feita por" essa ou aquela "empresa", em vez de procurar se há alternativas melhores, e então faça a nossa vida um inferno por anos.
MetalMikester
Eu já encontrei esse. O raciocínio do PM / cliente era que não tínhamos um item de orçamento para comprar coisas para o cliente (as alterações de contato eram uma vadia), portanto teríamos que reinventar a roda (novamente).
Ken Henderson
24

"Atirar corpos (suficientes) para o problema" ainda pode ser usado em alguns lugares, infelizmente. A Lei de Brook contraria isso em The Mythical Man-Month , embora alguns exijam experiência para aprender esta lição. Geralmente, isso não é algo ao meu alcance para parar, já que a gerência pode acreditar na falsa afirmação sobre adicionar pessoas e não ter que pagar um preço por isso.

JB King
fonte
2
+1. Oh Deus sim. Atualmente, isso está acontecendo em escala épica em um grande projeto em que trabalho.
Bobby Tables
3
Eu trabalho com vários líderes de projeto, gerentes etc., todos com sua certificação de gerenciamento de projetos tão maravilhosa (seja lá qual for o nome) e NINGUÉM ELES ouviram falar do The Mythical Man-Month antes de apresentá-los para isso. Sheesh!
22310 Bob
2
Ouvi uma ótima citação sobre isso uma vez: 9 mulheres não podem engravidar em um mês #
Richard Richard
@ Richard Eu usei esse em uma reunião. me deu imenso prazer!
Tjaart
21

Reuniões diárias :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...
Zzz
fonte
9
Que têm a reunião apenas por uma questão de ter reunião ...
Gan
5
Agenda para hoje: O que estará na agenda para a reunião de amanhã?
Mark C
9
A reunião diária é boa se for curta; As reuniões de stand-up de 3 minutos no estilo Scrum não perdem muito tempo, mas mantêm todos conscientes dos desenvolvimentos de todos os outros. No entanto, longas reuniões com inúmeros participantes desinteressados ​​são tóxicas.
9000
3
@ Mark C - Pode soar como uma piada, mas eu realmente ter sido convidados para as reuniões para planejar qual seria a agenda da próxima reunião dias ...
Gavin Coates
@Gavin Coates é um real e situação ... :)
Zzz
20

Comprar software de prateleira em vez de desenvolvê-lo internamente.

Tenho experiência em sistemas de gerenciamento de escala empresarial, focados em laboratórios de RH e biológicos.

Uma solução pronta para uso custa de 50 a 100 mil libras e precisa de mais desenvolvimento e personalização para atender aos requisitos de negócios.

A solução desenvolvida internamente levou (<6) meses para ser desenvolvida, com outros projetos sendo trabalhados em paralelo e utilizando um desenvolvedor já empregado.

Eu fui do setor público, onde tínhamos em funcionamento o LIMS (sistema de gerenciamento de informações de laboratório) desenvolvido internamente, para uma grande indústria farmacêutica internacional, onde a implementação de uma solução pronta para uso durou mais de um ano e não estava completa.

(6 meses de um desenvolvedor já contratado trabalhando em outros projetos em paralelo. Mais ou menos 10 mil. E isso não inclui os custos de suporte associados à solução pronta para uso). O ponto principal é que o sistema desenvolvido internamente estava realmente sendo usado! Então você tem o benefício de custo adicional associado a isso, que não posso calcular.

Eu concordo com sites básicos etc., por que se preocupar em desenvolver o seu próprio? Mas para qualquer sistema grande e complexo, e se você já possui habilidades internas, eu mesmo o construo .

NimChimpsky
fonte
26
Aposto que também há muitos exemplos opostos.
Jon Hopkins
13
Comprar ou desenvolver se resume às pessoas certas, fazendo a devida diligência. Simples assim. Pense antes de agir. (+1)
DevSolo 17/11
4
@ DevSolo: local. A decisão de construir ou comprar deve ser apoiada por uma análise de custo-benefício, em vez de uma atitude emotiva 'não inventada aqui' ou 'eu amo o software do XXX'.
JBRWilkinson
9
Se você deseja fazer uma declaração geral sobre compilar versus comprar, deve ser: prefira comprar soluções para problemas que não fazem parte da competência principal da sua empresa. Nem sempre é a resposta certa, mas é uma posição padrão sensível e tão confiável quanto um clichê. Afirmar que a compra de software de prateleira é uma economia falsa, porém, nem sequer é um clichê útil. Sinto sua dor nas soluções 'E' (que deveria significar 'Empresa', mas realmente significa 'Caro'). '). Mas a presença de más opções não significa que não existem boas por aí.
Evadeflow
2
Eu acho que o problema está comprando e, em seguida, ainda precisa de mais desenvolvimento e personalização , o custo de uma pequena personalização em um grande sistema trazido pode ser mais do que escrever seu próprio pequeno sistema que apenas faz o que você deseja. Portanto, compre se puder trabalhar da maneira que o sistema que você está comprando espera que funcione, mas a compra e a personalização podem dar o pior de ambos os lados!
Ian
15

Compra de produtos caros quando as alternativas de código aberto são melhores e gratuitas.

Quantas empresas usam o git? Quantas empresas usam algum controle de versão de baixa qualidade para empresas?

hasen
fonte
1
Erm, isso pode ser considerado "pior economia falsa"? Ou provavelmente você precisa elaborar mais ...?
Gan
3
Não tenho certeza se concordo totalmente com o exemplo de controle de origem, no mínimo. O Git foi projetado especificamente para solucionar problemas de código aberto: muitos desenvolvedores, pouco controle central, muitas filiais etc. O software "enterprisey" funciona sob um conjunto diferente de premissas: a necessidade de gerenciar uma variedade de produtos em uma empresa, segurança, fluxo de trabalho, etc.
PeterAllenWebb
1
@ Gan: Eles acham que usar código aberto é a falsa economia, mas eles têm tudo ao contrário.
hasen
3
Sou colaborador do X11 e GNOME e sou bastante competente no uso de git e na administração de servidores de gitosis. No entanto, neste verão, mudei meu trabalho de consultoria do git para um servidor Perforce pago pessoalmente, porque ele faz muitas coisas automaticamente que você precisa fazer manualmente com o git. Como sou pago por fornecer código e não mexer com o controle de versão, usar e pagar pelo "controle de versão ruim de empresa" é muito mais econômico do que usar o git.
Bob Murphy
7
Código aberto vs. produtos comerciais é realmente uma base "caso a caso" na minha experiência.
MetalMikester
14

Usando linguagens "simples" sem muita expressividade

Sim, torna mais fácil encontrar programadores para manter o código, mas torna mais difícil encontrar bons programadores que não aprendem apenas a última palavra da moda que os contratará. Sim, torna o código de bits individual mais fácil de entender, mas também o torna tão rígido quanto um 2x4 e aumenta o volume de código que precisa ser entendido. Sim, é apoiado por uma grande corporação, mas disse que uma grande corporação inova lenta e burocraticamente.

dsimcha
fonte
4
@burnt_hand: Estou basicamente me referindo à excessiva aversão ao risco da gerência em termos de escolha de idioma.
perfil completo de Dsimcha
1
+1: Continue usando C porque "nós temos essas habilidades e aprender alguma linguagem nova como Python / Perl / PHP aumenta muito o risco". Ouvi mais de uma vez. Isso significa que a equipe é burra demais para aprender um novo idioma?
precisa saber é o seguinte
1
@ Agentes S.Lott Recrutamento pensa que é !, mas isso é outra história
burnt_hand
2
ou seja, empresas que furam com Java e C # e são muito medo de tocar python ou ruby porque eles não são "padrão da indústria", que me lembra: paulgraham.com/avg.html
Hasen
1
@hansen: O ensaio de Paul Graham foi parcialmente o que me inspirou a escrever este post. Minha outra inspiração foi meu trabalho no desenvolvimento de bibliotecas (incluindo a biblioteca padrão) para a linguagem de programação D.
dsimcha
13

Maus gerentes de projeto / líder de equipe.

Uma vez que uma pessoa incompetente tem o poder de arruinar o trabalho de um grupo de pessoas. No final, o projeto se sairia muito melhor sem as decisões da alta gerência (líder do projeto / equipe).

Escolha a opção "Apenas faça isso rapidamente, refatoraremos mais tarde".

Amir Rezaei
fonte
4
Concordo que existem maus gerentes, mas "o projeto faria muito melhor sem as decisões da alta gerência"? Geralmente, essas são as pessoas que estão patrocinando o projeto. Isso me parece um pouco com os desenvolvedores que conheci que acham que entender a tecnologia é mais importante do que entender os negócios e esquecer quem é o cliente real.
Jon Hopkins
2
@ Jon Hopkins Com a gerência superior, não indico o cliente. O ponto é que "maus gerentes de projeto" são aqueles que cometem erros após erros e vão contra um grupo de pessoas. Quem você acha que decide "Apenas faça isso rapidamente, refatoraremos mais tarde". Leia a resposta com a taxa mais alta!
Amir Rezaei
ah, mais claro. Eu removo meu -1.
Jon Hopkins
Percebi uma tendência perturbadora dos gerentes de projeto reverenciando tempo e custo sobre qualidade. Tenho certeza de que não sou o único. Os PMs gostam de usar o diagrama de triângulo com Custo / Qualidade / Tempo, mas a Qualidade sempre começa primeiro. É muito triste, institucionalizar e forçar as métricas de gerenciamento de projetos (PMI) em algo tão complicado quanto o software apenas parece piorar as coisas.
Bernard Dy
1
@ Bernard - tempo e custo são mensuráveis. Qualidade? Não muito. Triste mas IMO verdade ...
Bob Jarvis
12

Requisitos de usuário ausentes

Uma etapa importante e difícil de projetar um produto de software é determinar o que o cliente realmente deseja que ele faça.

Acredite ou não, às vezes essa parte está ausente ou está desatualizada. O custo é que se cria funcionalidades que o usuário final nunca solicitou.

Amir Rezaei
fonte
Eu acho que isso deve estar no topo!
Roopesh Shenoy
8

Produtividade vale mais que criatividade

A criatividade é difícil de medir em geral e, na maioria das vezes, impossível de observar, não importa medir, quando se trata de desenvolvimento de software. A produtividade, por outro lado, pode ser medida (geralmente mal) e pode ser observada.

Como resultado, desenvolvedores que podem (escrever mais linhas de código | escrever código mais rapidamente | recitar technobabble mais rapidamente em resposta a perguntas | são mais visivelmente produtivos) tendem a ser mais valorizados do que aqueles que (usam menos linhas de código para resolver o mesmo problema | demore mais para escrever código, mas produza um produto mais confiável | entenda o assunto suficientemente bem para responder a perguntas de maneira clara e fácil de entender, inglês | resolva problemas de maneira criativa).

blueberryfields
fonte
6

Todos os itens abaixo podem ser ruins quando usados ​​ou não inadequadamente

  • software externo vs interno

  • Conformidade com a ISO 9001 (economia - uma atenuação do risco de perda de MSS se a qualidade do produto cair)

  • terceirização de desenvolvimento / controle de qualidade

  • procedimentos de desenvolvimento / construção / liberação / suporte

bobah
fonte
Como a ISO 9001 é uma (falsa) "economia"?
Andrew Grimm
@ Andrew Grimm - a conformidade garante um certo nível de qualidade que atenua os riscos resultantes da má qualidade (perda de MSS, por exemplo), para que a economia potencial fique clara. Para os pequenos departamentos este pode ser inadequada porque as perdas com sobrecarga são superiores aos de risco potencial
bobah
1
@ Andrew - na minha experiência, depende do que você quer. Se você deseja aumentar a qualidade, provavelmente é uma economia falsa, pois tende a ser cara e pode não ser adequada ao software. Se você deseja algo de marketing ou porque é apenas esperado no seu setor, é uma boa ideia.
Jon Hopkins
5
@ Andrew Grimm - A "única" coisa que a ISO 9001 garante é a qualidade consistente e reproduzível. Não garante qualidade "alta". No entanto, se uma qualificação ISO 9001 é necessária no espaço de mercado em que a empresa deseja estar, é necessária.
Vatine 17/11/10
1
@Vatine: O que a ISO 9001 garante é um processo consistente e repetível. Em alguns campos, onde processos consistentes produzem qualidade consistente, isso é importante. Não garante alta qualidade, mas se um cliente vê algo que você fez bem e sabe que possui a certificação ISO 9001, ele confia em qualidade semelhante.
precisa
4

Ter muitos gerentes de entrega não faturáveis.

Há alguns anos, em nossa empresa, tínhamos vários projetos de grande orçamento em andamento e o recrutamento estava no auge. Naquela época, nossa empresa contratou muitos gerentes de entrega (muitos deles não eram de TI!) E muito poucos codificadores / testadores. A proporção de gerente para programador era literalmente 1: 2. Mais tarde, após a conclusão desses projetos, tivemos uma situação em que muitos desses gerentes (alguns deles eram preguiçosos de verdade) sentados no banco sem fazer nada. Tivemos um ciclo de avaliação em que todos obtiveram pouco / nenhum aumento (até nós, programadores esforçados, suspiro), para que a empresa não precise dispensar ninguém! Felizmente, a empresa percebeu essa situação e fez o RIGHTSIZING no primeiro trimestre deste ano!

mananjani
fonte
3

Otimização antes da criação de perfil (também conhecida como otimização prematura).

Muitas vezes eu vi alguém buscar uma solução inteligente que desnecessariamente complica a manutenção e a legibilidade, porque é mais rápido. Naturalmente, o código não foi marcado como benchmark (nem mesmo com micro-benchmarks), tornando-se rapidamente "mais rápido com base no argumento mais persuasivo" sobre uma seção de código que provavelmente não afetou o desempenho geral de todo aplicação por muito.

Como tal, é uma economia muito falsa e o tipo de economia falsa que ocasionalmente envolve até os profissionais experientes.

Edwin Buck
fonte
3

Acesso limitado ou inexistente à Internet

Como é óbvio, seus funcionários usarão a Internet para jogar jogos no Facebook, e não pesquisar respostas para perguntas técnicas no Stackoverflow.

Na realidade, é claro que a Internet é um enorme aumento de produtividade e, embora possa ser apropriado usar algum tipo de filtro de site para sites realmente desonestos, há algo de errado se estiver bloqueando o arquivo leia-me do visual studio ou bloqueando as páginas de governo local de Telford por razões "turismo sexual"

jk.
fonte
2

Fazendo com que seus desenvolvedores usem um monitor de 15 polegadas e um PC de baixa especificação, pois é o padrão corporativo.

Monitores de tamanho razoável são baratos, rápidos de instalar e tornam os programadores mais produtivos, além de fazer com que seus programadores pensem que você se importa com eles.

Ian
fonte
2

Muitos Bacharéis em Administração de Empresas (ou similares), organizados hierarquicamente, que tentam aplicar o que eles acham da gerência moderna: incomodar as pessoas com "KPI" s, "SLA" e outras, exigindo "relatórios" (sem, é claro, se preocupando com a infraestrutura para gerá-los), para que os programadores percam seus dias preenchendo folhas EXCEL sofisticadas, relatórios do quarto trimestre e o que não e copiem de uma excelente nova ferramenta de gerenciamento e colem em outra (parece ser a regra que essas ferramentas nunca são integradas nem integráveis ​​entre si) e participam de reuniões em que os relatórios e figuras são apresentados (e todo mundo se sente culpado por não ter conseguido preencher este ou aquele KPI).

Ingo
fonte