Fábrica de Software é uma Besteira
O maior desserviço à área de Desenvolvimento de Software já criado na nossa história recente foi o termo “Fábrica de Software”. Pior ainda depois que a Índia implementou esse conceito em larga escala, tornando-o famoso e com credibilidade.
Digo isso porque a partir do momento que se encara “Desenvolvimento de Software” como uma tarefa de “Fábrica”, onde entra uma especificação de um lado e sai um software do outro, você acabou de destruir qualquer inovação na área. Pior ainda, considera que todo programador é necessariamente um “operário”.
Porque estamos falando de “Fábrica”, os cursos de “Engenharia de Software” se tornaram mais populares que os de “Ciências da Computação”. E mais paradoxal ainda é ver estudantes se formando como “engenheiros” mas trabalhando como “pedreiros”.
Mais ruim ainda é quando gerentes de TI, “CIO”s, “CTO”s, que sequer foram da área de software, sequer escreveram uma linha, acham que entendem como se faz software. Dado que o mercado fala de “Fábrica”, o que eles vão implementar são “linhas de produção” e junto com isso todos os procedimentos que colocam o operário em linha. Planilhas de horas, métricas de linhas de código, ou pontos de função ou pontos de história ou qualquer bobagem dessas, gantt charts e cronogramas “precisos” de entrega, etc.
A metáfora está completamente errada. Desenvolvedores não são operários, e sim os “arquitetos” propriamente ditos. O trabalho de operário em software é do compilador, este sim, que empilha um byte sobre o outro seguindo uma especificação: o código do software. Repetindo: o código do software é a especificação, a planta baixa, e o compilador é o operário que faz o trabalho braçal.
O que chamamos hoje de “arquitetos” não são arquitetos, na verdade não são nada. Não há como ser um arquiteto sem ser um programador sênior antes. Um bom programador pode se tornar um arquiteto.
Agora, o problema é que o conceito de “Fábrica” se espalhou rapidamente. O governo e as instituições de ensino abraçaram isso. Me deixa extremamente triste visitar áreas do Brasil onde as únicas opções de trabalho para programadores são essas “Fábricas”. As faculdades também se depreciaram para atender essa demanda e formar “operários” com diplomas de “engenheiros”, e assim toda uma nova geração de programadores pensa com cabeça de operário.
Uma ressalva para ser politicamente correto: não tenho nada contra operários, muito pelo contrário, é uma profissão tão respeitada como qualquer outra. Porém, ninguém vende operários de obra como arquitetos e nem os próprios operários se acham arquitetos.
Eis porque digo que foi um desserviço: toda uma geração inteira de programadores desperdiçada pensando em software enquanto empilhar tijolo. Levará pelo menos mais 2 gerações inteiras para, talvez, conseguirmos reverter isso.
Agora pensemos: e se em vez de “Fábrica” mudássemos o termos para algo mais adequado como “Atelier de Software”? Como isso mudaria a forma como você pensa e trabalha com software?
domingo, 11 de abril de 2010 -
14:11
|
Fabio Akita é um conhecido blogueiro e evangelista da comunidade Ruby on Rails e Agile. Atualmente é Gerente de Projetos pela Gonow Tecnologia. Foi Gerente de Projetos na Locaweb, onde também fez parceria na concepção da conferência anual Rails Summit (rebatizada de "RubyConf Brasil"). Já trabalhou como Brazil Rails Practice Manager para a consultoria americana Surgeworks LLC. Por mais de 5 anos foi consultor de integração e desenvolvimento no mundo SAP. Tem mais de 15 anos de experiência nas áreas de desenvolvimento de software e gestão de projetos, dá palestras em faculdades e conferências de tecnologia e gestão
Realmente é muito infeliz essa metáfora de desenvolvimento de software com a manufatura taylorista/fordista. Akita, as tais planilhas de horas, assim como as demais “ferramentas” que você cita, são uma grande besteira em se tratando de desenvolvimento de software tratado com uma atividade de criação, não repetitível, que se distancia do modelo de linha de produção taylorista/fordista, certo? Essas ferramentas só fazem sentido numa linha de produção, onde o trabalho repetitível é inerente; é essa a idéia?
O pior ainda é que fábricas de software ainda conseguem obter bons lucros, entregando elefantes brancos, com orçamentos bem engordurados.
E muitos “operários” tem que dançar conforme a música e fazendo jornadas de trabalho de até 16 horas.
Hoje, eu vejo que essa situação só irá mudar quando os clientes perceberem a roubada que entram ao contratar uma fábrica de software, algumas até CMMI 5, ou melhor, com um setor que não entrega “nada” que foi certificado nível 5.
Muitas dessas fábricas só estão interessadas em prazo, tempo e dinheiro, para elas pouco importa se a solução desenvolvida irá realmente ajudar o cliente, se o software está sendo produzido de forma sustentável, se os funcionários estão motivados com o trabalho realizado, etc. Infelizmente, o importante para elas é entregar produto o mais rápido possível, colocar o dinheiro no bolso e um abraço.
Concordo contigo, comparar desenvolvimento de software com uma fábrica, foi uma péssima metáfora.
Abraços! E parabéns pelos excelentes artigos publicados aqui no site da Info e no seu blog!
Existe vida inteligente. Primeira vez que vejo um gerente de projetos com esse discurso, esperei isso minha vida toda e juro que não estou sendo dramático. Parabéns pela visão, Fábio.
Sempre costumo dizer que Fábrica de Software é um conceito interessante. Pena que, quando importaram isso ao Brasil, foi com a mentalidade americana (e não dos criadores do conceito): reduzir custos. Então, implementaram pela “metade”, ou seja, só a parte que trazia custos de implementação mínimos para a empresa.
A taylorização estragou o mercado de TI por muito tempo. Acho que você é pessimista quando fala em duas gerações, acredito até que o quadro já deu uma pequena revertida (depende de tecnologia, claro), infelizmente muito modesta para fazer uma diferença.
“Levará pelo menos mais 2 gerações inteiras”. Acredita ser tanto tempo assim para tal reforma? Vejo que o mercado anda mudando rapidamente, tento ter um pensamento mais positivo.
Excelente artigo Akita !!!
A verdade é que não somente o processo de construção e gestão de software no mercado é baseado na industria convencional, mas aspectos como contratação, gestão de pessoas, etc. Tudo isso possui visão de “chão de fábrica”.
Falando sobre os comentários do pessoal, percebe-se que a “culpa” pelo modelo é direcionada somente para as prestadoras de serviço de TI. Elas (Claro), são as maiores culpadas pelo surgimento do modelo, mas infelizmente os clientes – ou contratantes de serviços – também se moldaram a contratar software como se fosse uma obra com início-meio-fim, a preços, prazos e escopo fixo.
Concordo que ainda levaremos um tempo substancial para que o mercado e as pessoas se recuperem do efeito “fábrica de software”.
Escrevi também há alguns dias atrás um post sobre fábrica de software na mesma linha que você:
http://blog.anascimento.net/2010/03/29/fabrica-de-software-o-modelo-falido-porque/
Espero mesmo que seja possível reverter isso, pois esse conceito de FS está acabando com a criatividade e a capacidade de pensar de muitos programadores.
Porque acha que serve essas tecnicas, que vc chamou de bobagem?
“Planilhas de horas, métricas de linhas de código, ou pontos de função ou pontos de história”.
Não podemos falar para nossos clientes: “Olha vou começar o seus sistema hoje, mas como é um processo criativo, não sei quando vou entregar, ok!”
A realidade é essa, tempo e dinheiro!
Criticar é fácil, quero ver é dar soluções!
É esse o problema de partir das premissas erradas. Tempo e dinheiro são recursos finitos, e claramente precisam existir limites e milestones a eles. O que não é escrito em pedra é o escopo e a premissa que tanto o cliente quanto a “consultoria” sabem como o software deve ser no final (e nunca sabem, por sinal). O primeiro passo a entender é o significado de desenvolvimento iterativo: http://agileproductdesign.com/blog/dont_know_what_i_want.html
Fábrica de Software não é um termo igual ao definido por Ford. As fábricas de software devem – ou os gestores delas deveriam – entender e adotar medidas para desenvolvimento e controle do software. Todos gostam de criticar o RUP – muito presente nessas ditas fábricas, mas poucos pegam para estudar a fundo a ideia por trás dessa metodolodia toda. Lendo, é possível perceber que a “base” do Agile – processo iterativo e incremental, é dita como priordial no RUP. O modelo waterfall não é sinonimo do RUP.
Se isso acontece, temos aí um problema de interpretação por parte dos gestores e todos aqueles que acreditam que o RUP e suas adjacências são modelos baseados lá na época do senhor Ford.
Agile não é bala de prata, galera.
Com certeza, Nada é bala de prata. Nāo vou entrar nos meritos do Rup, que de uma boa intencao acabou sobrando apenas uma pessina implementacao, e eu diria que o Scrum esta indo nos mesmos moldes. O problema é o termo em si, como eu disse no artigo, que evoca – querendo ou nao – as metaforas de … “fabrica”, de linha de producao, de operarios, de controle restritivo, de previsibilidade de producao. Independente se a intencao era boa, a realidade é que a grande maioria das “fabricas de software” seguiram o modelo errado.
Alias, a unica forma de entender como gerenciar projetos de software é praticando desenvolvimento de software e nao seguindo qualquer uma dessas metodologias, sejam elas “ageis” ou nao. Metodologia sem experiencia pratica na area nao serve para nada da mesma forma que um livro de receitas nao vai torna-lo um grande “chef”.
Fiz algumas observações sobre o uso do termo arquiteto no seu artigo, em meu blog.
http://lfamorim.com/post/515909529/definicao-de-programador
Sinceramente, acredito que a sua intenção e indignação muito válidas e até mesmo boa, no entanto o que você escreveu é fraco e sem uma argumentação capaz de embasar o título apelativo do artigo.
Essa mágica que você citou: Entra especificação e sai software não existe, até porque se existisse, não seria necessário delegá-las a ninguém.
Mesmo com uma especificação, bem ou mal escrita, é preciso de inovação, capacidade, criatividade e competência para transforma-la em um código confiável e que funcione de forma correta e esteja alinhado com as necessidades reais de quem contratou o serviço.
Em qualquer ambiente sempre existe espaço para problemas, sejam ágeis ou não. Sempre vai existir retrabalho, atrasos e etc.
Nenhum mundo é perfeito, todos tentamos achar a melhor forma de trabalhar mas acho que esse discurso religioso não nos leva a nada.
Rodrigo, com certeza, o artigo precisaria de pelo menos 10 vezes mais volume para explicar todos os pontos. Muitos deles eu já expliquei em artigos anteriores e pretendo continuar explorando nos artigos seguintes nesse blog. O tema central deste em específico é o “mind set”, algo para quebrar o que é considerado “normal” e justamente provocar reações como esta, de pensamento em “ok, o que podemos fazer”. E a desculpa de que “nada é perfeito, portanto podemos continuar como está” é justamente o que quero quebrar, “nada é perfeito, mas podemos perseguí-la continuamente” me soa muito melhor.
“Digo isso porque a partir do momento que se encara “Desenvolvimento de Software” como uma tarefa de “Fábrica”, onde entra uma especificação de um lado e sai um software do outro, você acabou de destruir qualquer inovação na área. Pior ainda, considera que todo programador é necessariamente um “operário”.”
Muito exagerado, não? Acho que nesse ponto você esquece que inovação pode acontecer em muitos níveis; desde a etapa de projeto do software até um simples trecho de código cheio de arte.
Um software pode ser inovador desde o momento da sua idealização, restando apenas ser implementado; o que se poder ser feito seguindo um processo bem definido ou não (mas sempre vai existir um processo), dentro de uma ‘fábrica de software’ ou não. Essas últimas questões irão depender de prazo, custos, recursos e, inclusive, habilidade e conhecimento dos desenvolvedores (em qualquer nível).
Acho que a questão aqui é não ser xiita quanto ao emprego do termo ‘fábrica de software’. É praticamente senso comum admitir que uma fábrica de software não funciona como uma fábrica de tijolos.
Quanto ao termo sugerido, de início não vejo o que mudaria. Mas acho que não mudaria drasticamente a maneira como desenvolvemos software. E logo logo iria aparecer gente dizendo que precisamos de mais organização, processos, etc.
Parabéns pelo texto.
Pois é, deveria acontecer inovação, mas com a mentalidade de “siga o procedimento, não importa porque” não acho exagerado. Já passei por diversas empresas e conversando com diversos profissionais da área na última década, a conclusão sempre é a mesma: a maioria dos projetos de software dá muito errado – grandes empresas conseguem cobrir o prejuízo, mas as pequenas não. Não importa que nós, desenvolvedores, saibamos que mesmo que o lugar se chame “fábrica”, não precisa agir como “operário”, mas toda a gerência e diretoria e acionistas pensam exatamente desta forma.
Já ouviu falar do Standish Group e do seu Chaos Report? Este de 2009 (http://www1.standishgroup.com/newsroom/chaos_2009.php) mostra o mesmo resultado dos últimos anos: somente 32% dos projetos de software da indústria conseguem ser entregues no prazo, no custo e com o que foi prometido. É uma taxa vergonhosamente baixa para uma indústria que se orgulha tanto em ter tantos processos e certificações, tantos PMPs e tantos CMMis.
Bem , já que você falou em Chaos Report, é bom saber que esses dados estão sendo contestados, e não é nada menos que um artigo da IEEE Software: http://portal.acm.org/citation.cfm?id=1729468.1729501. Enfim, é importante também refletir sobre essas afirmações de relatórios vindos de empresas que sempre tem algo a ganhar com isso.
Mas de qualquer forma, é fato que nossos projetos sempre atrasam e os custos vão além do estimado…
Eu sei que ele esta sendo contestado, mas nao é importante. Empiricamente, centenas de profissionais no mundo todo questionam a forma como se faz software hoje – por isso inclusive existem iniciativas como da comunidade agil – eu ja presenciei varios projetos que dao errado, sabemos exatamente porque da errado, pergunte a qualquer cliente que ja tenha encomendado software se ele esta perto de 100% de satisfacao e a maioria tera ressalvas (muitos, ressalvas grandes). O mercado esta cheio de exemplos disso. Veja o feedback que esse artigo teve no twitter, diversos programadores sabem disso porque vivem isso todos os dias – e voce tambem pelo visto
Nao estamos falando de algo abstrato, mas de algo muito real: o software costuma “parecer” barato na entrada e sempre sai caro na saida. Cansei de ver licitacoes que buscam preco mais baixo e depois o projeto sai 50%, 100% ou mais caros.
De qualquer forma, é o que eu sempre digo: “There are lies, damned lies, and statistics”
Fábio,
infelizmente isso que você diz é uma grande verdade. Utilizando uma fábrica de software em média se gasta o dobro do tempo para desenvolver algo que você desenvolveria. Geralmente não há padrão no código enviado, até porque essas fábricas pagam uma mixaria pros desenvolvedores que sem emprego ou por serem recém-formados, aceitam qualquer coisa como salário. E tem mais uma coisa, errado é aquele que pensa que o processo de desenvolvimento de software não é criativo, que é apenas apertar parafusos. Um sistema não é e não pode ser encarado como carros e outros produtos industriais, pois o software assim como uma jóia é feito a mão e sob medida.
O que cai melhor em uma pessoa: um terno feito em alguma fábrica da china ou um terno feito sob medida para o dono, feito em um bom alfaiate? A primeira vista o terno chinês pode até parecer mais barato. Contudo, após algum tempo, o terno feito no alfaiate continua intacto e com ótimo caimento, já o chinês, será o terceiro ou quarto. É o famoso barato que sai caro.
Ótimo texto!
Parabéns!
Fábio, concordo plenamento com a sua visão de que “o termo Fábrica de Software é o maior desserviço à área de Desenvolvimento de Software já criado na nossa história recente”. Sou do tempo em que um ótimo gerente de projetos, um ótimo analista de sistemas e alguns excelentes programadores é o bastante, e melhor maneira, para desenvolver sistemas dentro do prazo, custo, qualidade e escopo definidos. Taleto meu velho, talento… isso é o que está difícil de achar hoje em dia e a tal “linha de produção”, que robotiza tudo, é uma boa maneira de disfarçar essa falta de talento, em uma tentativa de transformar todos em iguais. Ah, e antes que eu me esqueça, “Atelier de Software”? Nem tanto ao céu, nem tanto ao inferno meu caro Fábio.
Tomei conhecimento do seu artigo através de amigo que sabe que gosto dos assuntos relacionados ao tema; li e embora considere que existam passagens interessantes, sou obrigado a discordar de algumas delas. Como para expor todos os meus pontos de vista teria que fazer uma análise parágrafo a parágrafo, vou evitar tecendo apenas algumas considerações:
• Primeiramente você coloca o termo Fábrica como sendo um local onde existem apenas operários, o que não é verdade. Qualquer fábrica de porte razoável possui várias escalas (hierarquia) de detentores de conhecimento e em boa parte delas pelo menos um engenheiro;
• Também gostaria de considerar que embora pessoalmente não seja muito a favor das fábricas de sotfware ou dos seus antecessores similares tipo “pools de programação”, acho que em determinadas situações e se bem administradas, elas possuem seu valor e dão bons resultados. Ressalto o bem administradas;
• Considerando válida a sua preocupação quanto à formação de operários com diplomas de engenheiro, acho que este seu parágrafo fica contrastante com o outro onde você considera as medições (métricas, pontos de função, cronogramas, etc.) como itens dispensáveis em trabalhos com um mínimo de organização.
Respeitando sua experiência na área, pelo que li do seu artigo e destacando apenas os itens que estou citando, fiquei (me perdoe mas coloco isto de maneira construtiva) com a impressão de que algo muito ruim deve ter acontecido de forma a motivar a sua elaboração, o qual tenho certeza não reflete o seu conhecimento do assunto.
Caetano, como seria uma fábrica bem administrada?
Essa fábrica bem administrada sobreviveria sem um gerente (ou sem os gerentes), provavelmente um PMP?
“Qualquer fábrica de porte razoável possui várias escalas (hierarquia)…”
A hierarquia de cima p/ baixo que inibe a emergência do novo, o respeito pelas pessoas e a melhoria contínua?
Acho que o X da questão está no fato do gerenciamento tradicional ser um paradigma diferente da abordagem ágil; é uma questão das origens e princípios serem diferentes. Ao meu ver são mundos que não se comunicam, por isso comparações entre um paradigma e outro não têm sentido. Não é questão de agile ser a bala de prata, não é, é um paradigma diferente e ponto.
Engraçado que eu bloguei sobre isso 4 anos atras..
http://loogica.wordpress.com/2006/11/21/fabricas-de-software-x-alfaiataria-de-software/
Inclusive usando o termo alfaiataria.. coincidencia, não?
Atualmente as faculdades realmente formam mais operários do que cientistas, disso eu não duvido, mas o mercado precisa dos dois. E tem mais, quando não precisar dos operários de hoje, é porque automatizou tanto que a “seleção natural” vai prezar pelos melhores e ainda assim haverá um novo perfil de operário . Hoje ela já exclui alguns. De vez em quando, sei de gente que tem formação em computação e afins, chegou a trabalhar na área por algum tempo sem muito destaque e depois pulou fora. Simplesmente não dá pra todo mundo ser cacique, precisa-se de índios.
O que antes era tido como atividade de alto nível intelectual, realmente tornou-se braçal. E dizer que quem faz o trabalho braçal é o compilador, é o mesmo que dizer que quem trabalha é a pá e não o operário, ambos são ferramentas e pronto. Acho que já passou o tempo em que se pensava: “O cara é crânio, sabe programar”. Se pensarmos bem, 20 anos atrás o simples fato de se saber usar um computador dava ao ser, o status de gênio. Por que com nós programadores e afins seria diferente. Darwin falou disso há 150 anos e nem todo mundo entendeu. É só evolução.
Falou,
Pastor
P.S.: Eu realmente queria estar enganado quanto a isso, mas acho que não.
De jeito nenhum, a ferramenta que você usa todos os dias para trabalhar, sua IDE, seu compilador, suas bibliotecas, seu sistema operacional, o servidor onde você faz deployment, tudo isso não foi feito por um programador-operário e nem nunca será. O trabalho de desenvolver meros cadastros (que é o grosso do que muitas “fábricas de software”) fazem, basicamente CRUDs, de fato tem muitas oportunidades de “automatização”, digamos.
Porém, ignore que o trabalho exige algum tutano e você terá sistemas bugados, lentos, difíceis de dar manutenção depois, que rapidamente se tornam obsoletos. Um exemplo muito simples: o velho caso do iniciante que colocar uma tabela na interface web, conecta numa tabela, puxa todos os dados em memória (à la “select *”) e faz o grid visual ser o filtro. Com 10 linhas na tabela funciona tudo bem. Em produção, quando a tabela tem 1 milhão de linhas de repente “nossa, como o programa está lento”. E isso acontece muito.
Ou outra: o caso onde resolvem dar manutenção numa tela, acrescentam 10 campos a mais, acrescentam validação de dados na tela e esquecem que o model é reusado em integração com outro sistema, e no model esquecem de acrescentar validação. Em pouco tempo alguém pergunta “nossa, porque os dados estão incorretos nessas milhares de linhas?”.
O trabalho do compilador não é o trabalho da pá. A pá do operário cibernético são os registradores e instruções de baixo nível do processador. O software, o código-fonte é exatamente como uma planta baixa de construção. Uma planta baixa serve como especificação para que os operários saibam onde colocar cada estrutura e cada tijolo para formar um prédio ou uma casa. Um código-fonte é uma especificação para que um compilador saiba onde colocar cada byte que forma o binário do software. A “casa” é o “software”. O operário é o compilador. E o programador é o arquiteto/engenheiro de obras.
Da mesma forma que um arquiteto precisa pensar pra não criar um cômodo onde falta uma porta, um programador tem o cuidado de criar códigos-fonte que façam sentido. Não estou dizendo que o programador tem que ser Einstein, mas sim que ele precisa raciocinar em vez de apenas burramente seguir procedimentos, precisa ser criativo para resolver problemas, precisa ser flexível e adaptável para se moldar aos requerimentos da “obra”, em termos de recursos, orçamento e prazos. Querer achar que “basta seguir o processo e reusar esses 100 componentes que o software será entregue no prazo certo” é um mito.
Prezado José, respondendo as suas colocações
“Caetano, como seria uma fábrica bem administrada?
Essa fábrica bem administrada sobreviveria sem um gerente (ou sem os gerentes), provavelmente um PMP?”
Não sobreviveria sem uma liderança, liderança esta que poderia ser representada ou não por gerentes, ou qualquer outro nome que se queira dar. Só como curiosidade, existem experiências de fábricas controladas pelos seus operários com excelentes resultados.
Quanto ao PMP, particularmente não gosto muito desta onda de certificações, embora ache que o conhecimento dela advindo, se bem aplicado, pode trazer bons frutos.
“Qualquer fábrica de porte razoável possui várias escalas (hierarquia)…
A hierarquia de cima p/ baixo que inibe a emergência do novo, o respeito pelas pessoas e a melhoria contínua?”
Do ponto de vista metodológico, qualquer método de trabalho, seja ele da linha que for, leva em consideração a necessidade do “feedback” das informações, de forma a possibilitar que erros cometidos não sejam repetidos, enquanto os acertos sim. Hierarquia no caso de processos de trabalho não significa ditadura, mas um fluxo ordenado de informações.
“Acho que o X da questão está no fato do gerenciamento tradicional ser um paradigma diferente da abordagem ágil; é uma questão das origens e princípios serem diferentes. Ao meu ver são mundos que não se comunicam, por isso comparações entre um paradigma e outro não têm sentido. Não é questão de agile ser a bala de prata, não é, é um paradigma diferente e ponto.”
Permita-me colocar que considero que definir-se algo, principalmente no nosso âmbito profissional, como totalmente ruim ou totalmente bom é que é um problema.
O que acredito, é que diante da quantidade de vertentes e ferramentas existentes hoje em dia, o primeiro grande trabalho que deve ser realizado antes de atacar-se um problema é fazer-se uma reflexão sobre qual seria a melhor abordagem (ou até mais de uma) a ser adotada para encontro da solução e não considerar que “A” não presta e “B” é excelente.
Bom post!
Concordo muito contigo! Outra besteira de igual tamanho é comparar engenharia civil com engenharia de software…já pensou se os clientes de engenharia civil pensassem igual os cliente de software “Ah… porque você não tira esta janela desta parede aqui, faz ela caber dentro desta porta, depois você muda esta parede de lugar o coloca ela em cima do telhado…” (isso com o prédio já construido)…e gosto muito menos do termo fábrica de testes…
Gostei muito do artigo, parabéns. Gostei especialmente da sugestão de se trocar o conceito para “atelier de software,” que me faz imaginar um grupo que mescla desenvolvedores experientes e aprendizes, onde todos participam de todas as etapas do processo. Assim os aprendizes tem mais oportunidades de crescimento profissional e cria-se um ambiente menos hostil.
Também escrevi um artigo inspirado no seu em meu blog: http://micosderealejo.blogspot.com/2010/04/fabricas-de-software.html
Fábrica de software já é escravisar a criatividade dos desenvolvedores!
E pensar da seguinte forma:
“quando recebemos determinada tarefa de um cargo para exerce-mos de um superior, independente de onde for temos que cumprir”
É nada mais nada menos que aceitar essa condição de alienação!
Alienar os desenvolvedores, é o mesmo que fizeram com os operários na revolução industrial!
Lembrando que todo desenvolvedor também é analista, e aprendemos a analisar os sistemas que temos que desenvolver, trabalhar em uma fábrica de softwares, no futuro, pode ser simplesmente ter que abandonar a análise e apenas desenvolver o que nos pedirem, não vamos progredir em nada! seremos simples empregados alienados e completametne descartáveis e substituiveis por outro que sabe fazer o mesmo!!!!
Aposto que tem o dedo de alguem de Infra nessa piada de péssimo gosto!!!
Não vai demorar muito e teremos um presidente sindicalista, que trabalhava em uma linha de produção de softwares, sem curso superior ou segundo idioma, e com apenas nove dedos porque perdeu um, digitando em um teclado de segunda!!!
De forma alguma podemos deixar que isso aconteça, devemos compreender que nosso papel como desenvolvedores e analistas não é só programar! temos que ser criativos e oferecer sempre o algo a mais! isso é o que as empresas sérias de verdade pedem de seus funcionários, e nem precisa ser desenvolvedor para isso!!!
Oi Fabio, já faz tempo que acompanho seus artigos e sempre comento com os colegas. Hoje escrevi algo que relaciona este artigo e outros e é ótimo para apresentar aos chefes. Confere lá… http://blogdojonas.com.br/blog/?p=987
Muito interessante o texto, mas não tá satisfeito… muda de área!!! Como não existe exame de proeficiência, sindicato, nada que regulamente a profissão isso vai continuar acontecendo. Abraço e boa sorte.
Eu diria não diria que “Fábrica de Software é uma besteira”, mas que “A forma com que as Fábricas de Software são implantadas no Brasil é uma besteira”.
Parabéns pelo artigo Akita, ultimamente esta difícil suportar os artigos e listas que estão em atividade ultimamente. Boas e inteligentes colocações.
As empresas hoje em dia, principalmente as que atendem contratos públicos, diga-se de passagem, tem tratado o Desenvolvimento de Software de forma vergonhosa. Apenas visando lucros e interesses envolta disto, ou seja, mais lucros. Implantando em muitos casos falsas fábricas de software ou fábricas de software que são verdadeiras geringonças, monstros de várias cabeças que lançam fogo, entre ouras fantasias imagináveis. Em suma se tornam fábricas sem a capacidade de produzir o produto final (que é o software) com qualidade, que atenda o usuário e seguindo corretamente as melhores práticas.
Quanto ao programador é outro problema, ele é realmente tratado como operário hoje em dia, prova disto é que basta o camarada ter um curso técnico ou uma faculdade qualquer em exatas (muitos nem de exatas são) e ele já é facilmente contratado. A degradação do programador hoje em dia começa aí, talvez devido às grandes demandas, mas isso não é desculpa. Se desde a seleção não é tratado como tal, como será na execução do seu trabalho em meio à equipe? Pra mim é claro, não é qualquer um que esta apto a ser um bom programador, um os requisitos mais importantes é ter aptidão e notável gosto para isso, mas a maioria entra na jogada por outros motivos. E para ser programador nem precisa ser formado, mas ter estes dons. Eu tenho um amigo que é um dos melhores programadores que conheço e não tem formação, da aula para muitos formados por aí.
Outro ponto importante que o Akita relatou é o fato de os estudantes serem formados como engenheiros e cientistas, mas trabalharem como operários. Isso hoje em dia é extremamente normal e pior, as pessoas nem se importam, se sujeitam a isso enquanto as empresas acham bom. Concordo que o programador/desenvolvedor tem uma importância muito maior do que a forma que tem sido tratado. A forma como os programadores são encarados hoje em dia desmerece a categoria, diminui a importância e revolta os programadores natos. Eu diria que são os “artistas que fazem com que as funcionalidades desejadas no requisito sejam implementadas” ou quem sabe “analistas de código” e poderíamos achar mais nomes bonitos para qualificá-los. Mas no fundo nenhum programador quer ser chamado de outro nome, mas ser chamado de programador e reconhecido merecidamente como tal.
Porém, gostaria de colocar apenas uma ressalva. Um programador é uma coisa e um arquiteto é outra, tanto que tem nomes diferentes por isso. A questão é que todo programador pode um dia ser arquiteto e todo arquiteto deveria (em minha opinião deve obrigatoriamente) ser um programador e na maioria das vezes é realmente. Um arquiteto se diferencia por ser um programador sênior, experiente, ter conhecimentos de análise e banco de dados, conhecer bem padrões de projetos de software, melhores práticas do processo de desenvolvimento, deve ter capacidade de propor e desenvolver mecanismos e funcionalidades avançadas e por aí vai. Se não se encaixa na maioria destes quesitos, sem chance de assumir um cargo de arquiteto!
Outra coisa que bato em cima é a questão da “ingovernança” e da “ingerência”. Hoje atuo como líder de projetos e sei bem do que estou falando, já vi de tudo. Não basta técnicas de gestão, modelos, ferramentas e discursos para que os projetos dêem certo, é muito mais do que isto. Mas este é outro papo que vai longe. Não adianta, para ter sucesso em uma coisa deve-se dominá-la, ponto final.
Tudo isso é fruto de uma má direção pedagógica nas universidades, má intenção das empresas e conseqüente má estrutura organizacional no mercado.
Com relação ao tópico, ótimo artigo, sempre achei “burrice” este termo “fábrica” de softwares. Nunca consegui ver sequer a mesma empresa produzir o mesmo software para clientes diferentes. Acho que tudo isso é fruto da falta de estruturação da profissão de TI no Brasil. Não temos sindicato, conselhos regionais e afins, logo, o mercado vai tentando dar o seu jeito de gerenciar carreiras e profissões e se auto regulamentar. Felizmente muitas empresas sérias não pensam assim e dão o devido valor a seus profissionais, mas como no meio do trigo há o joio, logo chegam as “espertas” e vulgarizam a profissão. É certo que assim como o mercado de desenvolvimento vai se ajustando, as universidades e afins se preparam para formar estes “operários” para não perderem tempo e não ficarem “fora da onda”. Vergonhosamente digo que hoje curso o 5º período de um curso de sistemas de informação e possui colegas que estão bem próximos de se formar, destes, apenas 10% teria capacidade hoje de interpretar um problema real e traduzí-lo em especificação de software. e dos 10% que conseguem fazer isso, apenas 2% seriam capazes de implementá-los. Além do mais estas ditas “fábricas” só se mantém com profissionais de segunda linha, pois os “arquitetos” (profissionais experientes) são caros demais para suas propostas de custo e lucro. Veremos até onde estas sobrevivem.
Bom o texto, finalmente alguem falou dessa porcaria que e’ “Fabrica software” de um monte de amigos do amigos para tirar ou ganhar dinheiro facil dos outros – Acho que existe mais de 15 anos …este nome. … Somente no Brasil eu acho que tem isto… Mais para empregar ou manter um monte de incompetente de gerentes de projetos, chefes, BA(business analyst),etc.. que nda sabe de TI(IT) e mais para ganhar um dinheiro facil dos cuidados dos Analistas/Designer/Programadores que sao realmente da area de TI.
Palhacada isto, que tem um monte de gerentes do qual nao fazem nada e que os pobres do caras de TI tem que trabalharem ou pensam para resolver a qualquer custo algo do que eles nao participaram, ou nem sabe do que se trata.. Nao existe formacao ou participacao na expecificao do problema e na participacao do lucro na solucao, ja que
teria ter direitos autorais p/ escrever os codigos
Moro a mais dez anos fora do pais, aqui nao existe estas empresas… tem claro que estao chegando da India, e vao dominar a area.. Porem eles tem solucao para todos tipos de empresa…
Mas tambem escravizam mao de obra barata.
O Brasil esta dominado por monte de bucrocatas do qual sabe mandar e poucos sao que realmente fazem.. Estilo ingleses, sabe mandar porem que
faz sao os indianos…
O mundo caminha infelizmente p/ isto, melhor
seria trocar de profissao, e nunca mais estudar esta area… e nem aconselhar ninguem jovem estudar em universidade
Ou virar “gerente de projetos” e criar formulas mirabolantes p/ resolver problemas do qual nda sabem ou nda fazem..
Solucao : estilo GOOGLE, YAHOO, todos tem divisao no lucros, ou
partipacao na acoes da empresa, se ter lucro todos ganham…
Melhor seria os cara da area de TI, (analista, desenvolvedore,arquitetos,etc..) contratar gerente de projetos,etc..
e pagar por cada projeto concluido, e repartir os lucros com
todos do projeto. Com isto todos projetos teriam datas mais
viaveis e final certo…
Quero parabenizar o Autor e demais interlocutores pela abordagem sobre a engenharia de software. Observem o termo engenharia foi utilizado para que pudéssemos agregar conceitos de processo, metodologia, ferramentas de suporte, tudo na busca pela melhor determinação do quanto de esforço é necessário para construir o software. Certamente a inquietude está na reorientação de projetos para o sucesso. Entretanto, deixamos de considerar a essência de nossa atividade profissional, em especial, a captação do conhecimento (tácito e explícito) sobre um determinado problema do mundo real e a efetiva construção de artefatos para agilizar o tratamento AUTOMATIZADO/COMPUTADORIZADO deste problema no mundo real. Ou seja, estamos analisando o objeto (mundo real) para buscar uma representação que nos permita orientar o processamento de uma solução com a Tecnologia da Informação.
É, portanto, um trabalho de inteligência, um trabalho que transpassa por todos os momentos do processo de gestão da informação e que através da gestão do conhecimento consegue transformar a TI em um artefato prático e de utilidade para tangenciar problemas do mundo real. Digo tangenciar porque o mundo real sofre mutações constantes, fazendo com que a “fotografia” construída seja temporal, e passível de ser incrementada a partir de t + 1. Daí os conceitos de interação, iteração, visão incremental.
De qualquer forma essa é apenas a minha percepção do tema discutido, passível é claro da análise dos senhores. Obrigado.
Prezado,
Normalmente não faço comentários por entender que a internet é livre para qualquer um escrever o que bem quiser, mas desta vez o farei.
Vamos a um breve do resumo de história:
Na era da revolução industrial, as indústrias foram o resultado de uma necessidade da sociedade por obter determinados recursos em larga escala, existia uma quantidade limitada de mão de obra e era necessário aumentar à escala de produção de forma a mão-de-obra existente não suportar de forma artesanal.
As pessoas começaram a ser agrupadas por conjunto de processos de forma a aumentar a produtividade e assim conseguir atender a demanda da época. Eis a criação das indústrias.
Muito tempo se passou, e estamos na era da informação, mas os problemas são os mesmos, temos uma demanda grande por desenvolvimento de software com uma escassa mão-de-obra.
O termo amplamente divulgado “Fábrica de Software” tem por objetivo aumentar a produtividade e diminuir os custos do desenvolvimento de software, agrupando pessoas por processos específicos dentro de todas as etapas de uma fabricação do software.
Quando você diz: “Digo isso porque a partir do momento que se encara “Desenvolvimento de Software” como uma tarefa de “Fábrica”, onde entra uma especificação de um lado e sai um software do outro, você acabou de destruir qualquer inovação na área. Pior ainda, considera que todo programador é necessariamente um “operário”.”
Discordo totalmente, a inovação não está no “desenvolvimento de software”, mas está em TODO LUGAR, inovação ocorre, por exemplo, na criação de maneiras mais rápidas e eficientes de desenvolver determinado ponto de um software. A função de um programador é ser o melhor programador possível, saber de tudo sobre as ferramentas que utiliza, se ele quer projetar software, sugiro mudar de área e pensar um pouco na equipe de arquitetura.
Quando você diz: “Porque estamos falando de “Fábrica”, os cursos de “Engenharia de Software” se tornaram mais populares que os de “Ciências da Computação”. E mais paradoxal ainda é ver estudantes se formando como “engenheiros”, mas trabalhando como “pedreiros”.”
O problema de se formar um engenheiro ou cientista da computação e o mesmo trabalharem na área de codificação de uma fábrica de software está na “Fábrica de Software” ou no profissional, ou ainda, na faculdade que ao invés de formar um cientista ou engenheiro forma um programador?
Quando você diz: “Mais ruim ainda é quando gerentes de TI, “CIO”s, “CTO”s, que sequer foram da área de software, sequer escreveram uma linha, acham que entendem como se faz software. Dado que o mercado fala de “Fábrica”, o que eles vão implementar são “linhas de produção” e junto com isso todos os procedimentos que colocam o operário em linha. Planilhas de horas, métricas de linhas de código, ou pontos de função ou pontos de história ou qualquer bobagem dessas, gantt charts e cronogramas “precisos” de entrega, etc”
A tarefa de um gerente, CIO, CTO, ou qualquer um que seja do tático ou estratégico não é conhecer os bits da tecnologia, ele não precisa ter sido um ex-programador, são funções completamente distintas, cada profissional tem a sua atribuição, um gerente tem que gerenciar pessoas, conflitos, etc…, um programador tem que programar, um analista de testes tem que testar, e por ai vai…
Quando você diz: “A metáfora está completamente errada. Desenvolvedores não são operários, e sim os “arquitetos” propriamente ditos. O trabalho de operário em software é do compilador, este sim, que empilha um byte sobre o outro seguindo uma especificação: o código do software. Repetindo: o código do software é a especificação, a planta baixa, e o compilador é o operário que faz o trabalho braçal.
Um compilador é uma “FERRAMENTA”, o programador é o “OPERADOR” da ferramenta, que deve ser utilizada conforme as especificações do projeto feitas pelo “ANALISTA”.
Quando você diz: “O que chamamos hoje de “arquitetos” não são arquitetos, na verdade não são nada. Não há como ser um arquiteto sem ser um programador sênior antes. Um bom programador pode se tornar um arquiteto.”
Como você já mencionou sobre paralelos e também já utilizou o termo “pedreiro’, sinto-me a vontade de fazê-lo também:
Quantos grandes arquitetos do mundo foram pedreiros? Quantos grandes arquitetos de sistemas foram programadores?
O trabalho de arquitetura de software não contempla a construção de código, contempla a estrutura de um projeto.
Outro detalhe, como você pode afirmar “Não há como ser um arquiteto sem ser um programador sênior antes”? Baseado em quais fatos você pode afirmar isto? Você se posiciona como um “guru” de tecnologia?
Quanto ao restante, o movimento de “Fabricação de Software” não é novo do ponto de vista histórico, é uma saída encontrada para tornar a criação de software comoddities, é uma necessidade da sociedade a criação de softwares com rapidez, qualidade e com custos acessíveis e isto nunca poderá acontecer com o trabalho artesanal ao qual você defende neste post.
A todos: Talvez tenha utilizado um tom exagerado, mas o conteúdo deste post se faz necessário. Entendam que não sou contra programadores, analistas ou gerentes, apenas exponho o fato de que no mundo corporativo cada profissional tem sua louvável função, e que precisamos deixar o amadorismo de lado.
Devo dizer que sua visão sobre uma Fabrica de Software está um pouco deturpada meu amigo, não o culpo por isso, afinal de contas, muito provavelmente as experiencias que teve com empresas que se diziam Fabricas de Software, não devem ter sido boas.
Gostaria de elencar alguns pontos com relação a sua explanação:
“Planilhas de horas, métricas de linhas de código, ou pontos de função ou pontos de história ou qualquer bobagem dessas, gantt charts e cronogramas “precisos” de entrega, etc.”
Quando mencionamos tarefas em ambito Profissional, estes procedimentos que você chama de “bobagens” são extremamente necessários e importantes, quando você se dispõe a produzir algo para alguém essa pessoa no mínimo gostará de saber em quanto tempo ficará pronto o que lhe foi prometido. Quando você leva seu carro no mecanico, você simplesmente deixa o carro na rua e diz: “Meu carro está com problema e esta parado lá fora!”, acredito que não, muito provavelmente você gostará de saber em quanto tempo poderá utiliza-lo novamente.
A relação que você expoe entre Fabrica e criatividade, sinto lhe dizer está muito fora da realidade, uma fábrica nem de longe irá desencorajar, ou tão pouco inibir, a criatividade de um profissional de desenvolvimento, muito pelo contrario ela ajudará pois organizará as idéias e informações.
Os clientes tem aderido cada vez mais as fabricas devido a redução de custos que isso lhes propociona, não só isso, eles viram que através de uma fabrica garatem o funcionamento do software sem percalços. É sabido por todos que profissionais de desenvolvimento muitas vezes se assemelham a radicais religiosos, ou seja, eles defendem a supremacia de uma tecnologia sobre outra, ou mesmo metodologia com outra, quando na realidade conseguesse fazer de tudo com todas, isso para um empresa é péssimo pois a cada novo profissional de TI, ele quer migrar tudo para a tecnologia que ele considera a melhor, agora vem a pergunta quem pagará as vaidades de um profissional de TI?
Outro ponto equivocado da sua parte, quando menciona que desenvolvimento de software não possui eforço repetitivo, vou elencar alguns: Cadastro, Alteração, Consulta, Validação, Conexões (BD, XML, DataSource), webServices, isso para elencar alguns. Agora com esses pontos que lhe apresentei, seja sincero, de todos os projetos que participou até hoje, quantos não tinham alguns desses pontos? ou melhor, de todos os projetos qual percentual representou essas atividades nos projetos, garato que essas tarefas que citei representam mais de 60% de todos os projetos.
Enfim meu amigo, eu poderia aqui escrever e elencar inumeros cenários e argumentos demonstrando que o problema não está no conceito, fabrica de software é fantastico e auxilia e muito a vida dos desenvolvedores, agora se não for implementado da forma correta, pode trazer grandes transtornos. Se algum dia tiver oportunidade de conhecer internamente como funciona a Microsoft, IBM, Oracle, Nintendo, Ubisoft, Eletronic Arts, Capcom, Samsung, Nokia entre outros, cuidado para não se desapontar, pois internamente todas essas gigantes da TI possuem uma enorme estrutura de fabrica de software, e tudo isso para que? Para que se possa tirar o máximo das idéias e capacidade dos grandes profissionais de desenvolvimento de software que trabalha nessas empresas.
Prezados
O artigo escrito como também os inúmeros comentários descrevem uma realidade que precisa mudar. Cada um tem uma opinião diferente, porém o que cada um disse tem um ponto de verdade.
Acredito que o principal motivo que causa os problemas em um processo de desenvolvimento de software usando fábrica de software é a falta de uma metodologia onde todos os envolvidos a conheçam, acreditem e a respeitem. Isto deve envolver o cliente e a consultoria, como também, todos os envolvidos no projeto. Trabalhei em um empresa onde isto ocorria e umas das soluções foi treinar as consultorias na metodologia que usávamos.
O principal item que leva ao insucesso fica por conta da definição abstrata do escopo. Este sempre é assumido em um nível de abstração em que não reflete as necessidades do cliente. O fato do cliente não saber o que quer é uma verdade. Porém a consultoria (que agrega a fábrica de software) deve procurar resolver esta questão ainda na fase do levantamento de requisitos. As mudanças durante o desenvolvimento também afetam e muito a qualidade do resultado apresentado. Na minha opinião para um software ser desenvolvido com qualidade é necessário que primeiramente seja realizado um levantamento minucioso do escopo (e isto leva tempo e todos devem respeitar), a representação deste escopo em um modelo de análise e design (de preferência utilizando orientação a objetos com UML), e somente após estas atividades estarem bem definidas e aprovadas iniciar o desenvolvimento. É importante observar que o processo de análise e design deve ser feito por um analista que tenha tido experiência no desenvolvimento, caso contrário, a comunicação entre o que deve ser feito (visão do cliente) e como será feitao (visão do programador) será comprometida. O uso de um modelo interativo também é muito bem vindo nestas situações.
Espero ter contribuído com o assunto.
Recomendo que você leia sobre alguns dos pontos que você levantou em alguns dos meus artigos anteriores:
http://info.abril.com.br/noticias/rede/gestao20/gestao/repetitivel-vs-imprevisivel/
http://info.abril.com.br/noticias/rede/gestao20/software/gerenciando-riscos-em-projetos-escopo/
http://info.abril.com.br/noticias/rede/gestao20/gestao/introducao-a-agilidade/
http://info.abril.com.br/noticias/rede/gestao20/gestao/processos-metodologias-e-o-cerebro-humano/
[...] Rails, dotNET, CakePHP, JQuery e Prototype. Delegue tarefas de baixo nível e terá lucro. Conheça os verdadeiros operários. [...]
[...] já viu uma equipe de tecnologia da informação e comunicação trabalhando? Já entrou em uma “fábrica de software”? A diversidade de pessoas, mentes, comportamentos e, muitas vezes, etnias – apesar de serem [...]
O termo está na moda. As fábricas de software são encontradas em quantidades crescentes, tanto no Brasil como no mundo. Por isso podemos encontrar vários estudos a respeito de seu conjunto de processos e métodos formais, que visam produzir um programa computacional eficiente.
O autor critica duramente esta abordagem, a partir do momento em que este observa que os programadores estão se tornando operários, com suas criatividades em decadência, tendo em vista que tudo é tratado como uma especificação padronizada.
Segundo o autor, a larga e constante adoção do uso das fábricas de software faz com que o problema se agrave. Cada programador tem acesso a apenas uma parte do conhecimento que envolve um sistema, e não sabe o problema do cliente em sua totalidade.
Contudo, percebe-se que o autor em vários momentos mostra-se extremista em ir contra a metodologia de linha de produção e utiliza jargões vulgares, como “bobagem”, “besteira” como argumentos para defender seu ponto de vista. O autor não informa ao leitor casos em que o método de linha de produção é utilizado com sucesso, a exemplo da IBM e da Microsoft.
A padronização do trabalho deve ser observada como forma de ganhar tempo e reduzir custos. Metodologias como Extreme Programming defendem a reusabilidade de código como aspecto que leva ao desenvolvimento de uma solução computacional eficiente.
Muitas fábricas dão responsabilidade e organização no trabalho de seus funcionários. Esse é um ponto positivo. Discordo quando o autor generaliza que a criatividade do programador é afetada quando o mesmo trabalha no ambiente em estudo: isso vai depender de pessoa para pessoa.
Existem fábricas que adotam políticas de capacitação, encorajando o funcionário a explorar novas soluções e se aperfeiçoar, dando a este uma gratificação em seu salário. Se o trabalhador não está satisfeito com o seu trabalho, a solução é simples: mude de emprego, pois ninguém é obrigado a trabalhar com o que não gosta ou onde não lhe agrada.
Para realizar uma crítica sobre uma metodologia, devem-se analisar seus aspectos positivos desta e propor soluções para cobrir seus pontos falhos. O autor foi infeliz ao ser extremista em suas opiniões.
O conceito de fábrica de software pode não ser perfeito, mas acredito que quem o elaborou não iria perder seu tempo em algo que soubesse que não traria resultados positivos, em algum campo aplicável.
Não acho o termo e o conceito de “fábrica de software” errado. Errado talvez esteja o modo como clientes e executivos os vêem.
Trabalho com fábrica de software na minha empresa e os vejo como um grupo de pessoas altamente especializadas, com metodologia que lhes confere precisão e eficiência. Talvez o termo atelier fosse dar uma idéia de algo artesanal, que não é a idéia a ser passada. A idéia a ser passada é eficiência: os programadores e analistas (não operários!) sabem gerar o código mais correto e eficiente, reaproveitando, minimizando retrabalho e consequentemente custos e prazos.
[...] então as fábricas de software, muito bem descrito no artigo do Akita, Fábrica de Software é uma Besteira , como: “O maior desserviço à área de Desenvolvimento de Software já criado na nossa [...]
[WORDPRESS HASHCASH] The comment’s server IP (187.45.241.124, 200.123.198.205) doesn’t match the comment’s URL host IP (187.45.241.124) and so is spam.
Permita-me discordar de sua afirmação: “Porém, ninguém vende operários de obra como arquitetos”.
O que a prática tem mostrado é justamente o contrário. Na visão da contratação de fábricas de software pelo serviço público, e ainda contando com as falhas homéricas de controle e nem se podendo exigir (a nível público) a especialização do corpo técnico, porque tudo é feito por meio dessa bobagem de Ponto de Função (que é excelente pra que vende e péssimo pra quem compra), o que as empresas fazem é justamente vender operários (profissionais pouco qualificados e sem experiência alguma) como se fossem arquitetos gabaritados e experts e ainda jogam a culpa pelos insucessos, que são comuns, na especificação do cliente (que via de regra não sabe mesmo o que quer).
[...] um pouco sobre isso no meu artigo anterior Fábrica de Software é uma Besteira justamente porque um dos motivadores para fábricas de software é apenas diminuir custos, sem [...]
[...] Um profissional que habitue-se a constantes mudanças e esteja disposto a passar a maior parte do tempo fora da zona de conforto, ele muitas vezes precisará buscar respostas por si próprio, sem ter instruções precisas do que deverá ser feito, e desenvolver a multi-disciplinaridade. Nós não somos um fábrica de software! [...]
Concordo que quando se encara “Desenvolvimento de Software” como uma tarefa de “Fábrica”, qualquer inovação na área pode correr o risco de ficar comprometida devido à falta de flexibilidade dos processos e da metodologia. Entretanto, são os mesmos processos e metodologia que conferem precisão e eficiência às fábricas.
[...] Site Info Categories: Negógios Tags: desenvolvimento, engenharia de software, fábrica de software, [...]
Fábrica de Software vs Mundo Real
OK, virou mania criar fábricas de software, mas me pergunto se este nome é merecido, ou é um padrão quando vários programadores desconexos trabalham juntos e produzem mil sistemas específicos?
São fábricas iguais a de automóveis? Ou ateliês de pinturas onde artistas criativos produzem obras de arte?
Estas fábricas tem produtos prontos para vender? Ou produzem novos produtos que serão cobaia para testar no mercado?
Será que são fábricas provedoras de mão de obra especializada para produzir todos os seus aplicativos customizados e entregam o fonte de graça para você?
Olhe para a segmentos sérios da indústria automobilística e compare.
Será que todas as fábricas produzem os mesmos produtos? Você acha que uma empresa especialista em produzir um tênis de corrida, terá a mesma desenvoltura para produzir carros de fórmula 1?
Imagine que seu software é como um computador ou carro comprado para uma atividade profissional. E pense comigo, você como dono de uma indústria, irá pensar quais segmentos de mercado irá atender, ou terá uma Matriz de construção de projetos, pouco reutilizável?
Sua fábrica é multi-tarefa? Depende de pessoas ou processos?
Irá produzir carros esportivos, ou motos? No que você irá especializar sua fábrica?
Quem serão seus operários? Quem serão seus engenheiros? Quem serão seus atendentes de pós venda ?
E você ser pensante e super criativo, que adora virar noites a fio programando e é viciado em tecnologia, gostaria de ser um operário?
Bom, administração, engenharia, planejamento de mercado não são linguagens de programação.
Como outras ciências, acho que uma fábrica se constrói do jeito certo para atender o mercado e gerar produtos de qualidade.
Se não meu amigo, logo logo, seu software estará em algum 1,99 no máximo se merecer…
E considere isto um elogio, porque alguém achou útil e quis piratear…
Soluções não são control+c e Control+V , soluções são software, equipe de suporte, CRM e retorno sobre o investimento para seu cliente.
Postado por Lapuinka às 16:17
quinta-feira, 11 de setembro de 2008
Eu amo programação, sempre gostei, as vezes ficamos insatisfeitos com os projetos, mas há espaço para sermos heróis e embutirmos funcionalidades nos projetos para que eles funcionem, dêem certo e façam o mercado funcionar, girar e ter credibilidade.
Alguns projetos podem ser uma furada, mas a experiência sempre me mostrou que ficando de boca quieta, e gastando a nossa energia para utilizar o tempo para fazer um Super Refactory e concertar o que ninguém percebeu, salva os projetos.
As pessoas não sabem o que querem, elas só conseguem perceber uma coisa por vez…
Nos pensamos mais rápido do que falamos.
Agir é um sentimento silencioso que salva o mercado.
As vezes, precisamos zerar nossas idéias, voltar para as coisas simples, refazer aplicativos sem utilizar tantas camadas e framework.
Acho que o legal mesmo da área que vivemos num ecosistema de software infinito e tem de tudo. Coisa boas e coisas ruins.
Não sejamos pessimistas.
Quem ama esta área, sempre estará lá para ajudar e inspirar aqueles que não conseguem.
Salvemos os projetos sempre que pudermos!!!
Abraço a todos!
http://lapuinka.blogspot.com/2008/09/fbrica-de-software-vs-mundo-real.html
Pelo amor de Deus!
Como querem não ser tratados como “pedreiros” se publicam um texto com “MAIS RUIM”? “MAIS RUIM” não existe! É “PIOR”!
Para ter credibilidade, além de ideias consistentes (o que o artigo tem!), o domínio da língua deve ser impecável. Até “pedreiros de software” sabem que não há nada que compile erro de sintaxe…