PplWare Mobile

Como não gerir um projecto de software

                                    
                                

Este artigo tem mais de um ano


Autor: Marisa Pinto


  1. Hugo says:

    Muito bom artigo. Parabéns !

  2. Filipe Vinha says:

    Bom artigo, o maior problema em causa, é quando o “chefe”, não percebe nada do mesmo e dá palpites em que tudo funciona igualmente… funciona, um com 3 linhas de codigo, outro com 3001…

  3. Miguel says:

    Muito bom!
    Engenharia de Software aka programação, são cargos muito diferentes do comum. Como citado, é impossível tratar um programador como uma máquina. O programador, tem, mais que ninguém, a visão mais periférica / ampla do projeto, superando muitas vezes o seu gestor/chefe que nunca esteve com as mãos na massa. Ele é a pessoa mais indicada para sugerir alterações, entre várias outras coisas.
    Em relação ao esconder informação da equipa, é uma coisa impensável. Como já disse, o programador é a pessoa que tem a visão mais ampla, e se souber todas as informações do projeto e todos os planos para o mesmo, poderá adaptar o código ou programar de maneira mais eficiente, de acordo com o caso.
    O programador muitas das vezes é quem sabe melhor como desenvolver o projeto, daí também ser totalmente impensável a imposição de metodologias, etc etc.
    Já ao adicionar novos elementos à equipa… quando um projeto vai a meio, principalmente na programação, o novo elemento irá demorar muito tempo até se habituar ao código, até perceber o objetivo do projeto, entre muitas outras coisas. Até lá provavelmente não vai conseguir fazer muita coisa.

    My opinion.

  4. Carlos Carvalho says:

    Gostei muito do artigo, deixo uma questão, será que para se chegar a “bom gestor”,ajuda, primeiro ser programador?

    • Miguel says:

      Tudo depende da pessoa. Mas, quanto mais o gestor souber de programação e de engenharia de software e de como se faz um software, mais dentro do projeto poderá estar, e melhor será.
      O que conta é o entendimento do gestor dentro do projeto. Não precisa de ser um ás na programação, mas se souber o que deve saber, está ótimo. Isso não inviabiliza o facto de ele saber mais, isto é, quanto mais o gestor souber de programação, teoricamente, melhor irá ele gerir.

    • Luís Soares says:

      sinceramente, não sei a resposta.. à partida sim.
      mas acima de ser programador, tem de ser um developer..
      e acima de ser developer, tem de ter um jeito natural para lidar com pessoas. não basta ser um excelente developer.
      é só a minha opinião.

    • Johnny Boy says:

      À partida sim.

      Paralelizando com o ramo militar, um general que tenha sido soldado tem uma perceção muito diferente da realidade.

      • Luís Soares says:

        pois.. como pode um gestor saber se está a ser “enganado” (mesmo sem esse objetivo) se lhe dizem: “demora uma semana” ou “faço isso em meia hora”?

        é difícil ter sensibilidade para gerir algo se conhece mal e nunca se fez. não digo que seja impossível até porque o mais importante num líder é saber lidar com pessoas, mas o caminho fica mais difícil e menos natural.

  5. Glink says:

    Excelente artigo, venham mais destes 😉

  6. Shinx says:

    Muito bom. Parabéns.

  7. HJM says:

    Artigo muito bom, parabéns.

    Não acrescentando mais do que foi escrito e resumidamente acho que o grande problema é:

    1º Em grande maioria o cliente final, quer tudo e mais alguma coisa para ontem e a um preço muito baixo – Faz com que isto se torne numa bola de neve, pois é feita uma pressão ao “Fornecedor”, que por sua vez vai para o Gestor de Projeto, por sua vez para o gestor de equipa de desenvolvimento, equipa funcional e por outra para os funcionais e programadores… Só vantagens para quem pede a solução, evita que seja fechado alguma coisa e pode sempre pedir mais.

    2º Isto também é desculpa que os responsáveis da empresa “Fornecedores” se aproveitem disto, não querendo saber de metodologias, de analise de risco, se o desenho funcional está ou não fechado, etc…

    3º A prototipagem é vista como um exagero e uma mania dos funcionais ou exigência sem nexo dos programadores…

    Acho que cada vez mais se olha para o preço final e ganhar o projeto, independentemente de quem se explora e se na realidade, se cumprem os prazos, pois se cumprires o cliente ganha se não cumprires, existem penalizações… e ganha na mesma.
    Abraço

  8. Rodolfo says:

    Muito bom artigo, gostei. Parabéns!

  9. Tenrinho says:

    Tive uma conversa sobre este tema á exactamente 1 mês e as nossas conclusões foram no mesmo sentido de estas.
    Gostava de acrescentar outro ponto:
    – O facto de uma pessoa ter “10 anos”, “15 anos” ou ter feito “muitos deploys durante a noite” não significa que saibas o que estás a dizer, e quem sabe vai-te ouvir e em seguida julgar-te estupido. Se não sabes do que estas a falar só te enterras e so prejudicas a tua imagem como gestor.

    Quem gere tem de ter experiência mas tem de saber onde está o limite quando se põe a mandar os chamados “bitaites”.

    A humildade é a coisa mais bonita e a que menos existe no mundo da programação (e se formos para consultoria então nem vale a pena começar!).

    BTW vou enviar para todas as equipas de projecto com quem ja trabalhei.. espero que a carapuça sirva a alguns.

  10. Paulo says:

    “Idealmente, o chefe deve ser parte integrante da equipa, metendo as “mãos na massa” de vez em quando ou em alocação reduzida.”

    Na minha opinião falta uma parte:
    … sendo, preferencialmente, o “controlo de qualidade” da equipa.

    Obviamente é uma opinião mas acho que é uma das funções mais importantes (e desagradáveis) do chefe de projecto.

    “(O Scrum leva isto mais longe dizendo que não há chefes de equipa: todos o são e ninguém é; a equipa é responsável por analisar, atribuir prioridades e implementar.)”

    Acho que neste ponto o Scrum é utópico. Sendo um projecto informático desenvolvido para uma organização já existente(larga maioria dos projectos), o “cliente” vai querer sempre um alvo, o “cliente” não reúne com a equipa mas com o alvo, o “cliente” vai responsabilizar o alvo em primeiro lugar. Não considerar esta vertente não me parece realista.

    Cumprs

    • Luís Soares says:

      concordo.. eu tentei ser genérico mas há casos e casos.
      De qualquer forma, o Scrum master pode assumir esse papel, ao interagir com o dono de produto (do lado do cliente).

      O Scrum nem sempre se pode aplicar realmente. E quando se aplica é com aceitação de ambas as partes. Ser valorizado pelas partes é necessário para que se aplique.

  11. Redin says:

    Este artigo vem bem a tempo do lançamento do meu projeto antispam.P2T – até parece que vocês adivinham os nossos interesses, pah!

  12. Marcellus says:

    Excelente artigo… Parabens!!!

  13. Miguel Costa says:

    Muito bom artigo.

  14. Vítor Moreira says:

    Bem, vou passar a utilizar frase “9 mulheres não têm um filho num mês…” 😀

  15. Nuno says:

    Não me levem a mal, acho o artigo é interessante, mas parece escrito por um programador que aspira chegar a chefe/lider (peço desculpa se não é o caso).
    Apontar os problemas é facil… Não chega dizer que o problema é este ou aquele, é preciso saber como contorna-lo e isso muita vezes mexe com algo que se sobrepoe a tudo! O dinheiro, afinal é para isso que todos nós trabalhamos…
    Concordo que um gestor tem de saber gerir pessoas e motiva-las. Mas tambem tem ser capaz de olhar friamente para um projecto e tomar decisões menos “populares” e que podem até abalar o moral de uma equipa.
    Infelizmente nunca conheci nenhum gestor que defendendo apenas a sua equipa (e os interesses desta) perante uma administração, tivesse grande sucesso…

    • Mark says:

      Estás com sorte porque eu nunca conheci um verdadeiro gestor, só conheci pessoal a brincar aos chefes e a dar ordens sem nexo

      • V says:

        Concordo, o que mais há por aí são pseudo-gestores a debitar ordens sem nexo. Pior é quando abaixo dos pseudo-gestores há pseudo-chefes de equipa. Já testemunhei várias situações em que dois desses alinhados no “mumbo jumbo” a mandavam fazer algo que eles claramente não tinham noção do que estavam a pedir para ser feito, apenas uma série de chavões metidos numa frase. O coitado do programador respondeu corajosamente com um: “Não sei como fazer isso.”(por norma os chefes não conseguem processar bem esta frase) e a resposta é geralmente indicadora de um certo grau de autismo:”Já te explicámos claramente o que tens de fazer,agora é contigo.”

    • João says:

      +Nuno não concordo com a tua visão do artigo, quando li achei mais de um programador que já passou por muita coisa e expôs a experiência dele nos projectos onde esteve integrado.
      Quando à questão que falas: “O dinheiro, afinal é para isso que todos nós trabalhamos…”, sim concordo, muitas vezes é o que torna os projectos miseráveis, mesmo com bons gestores de projectos associados ao mesmo.

    • Luís Soares says:

      Nuno,

      obrigado pelo seu comentário. Concordo com a resposta do João. O artigo não foi escrito de nenhum pedestal. Foi apenas fruto da minha humilde experiência e do que tenho observado.

      De qualquer forma, eu concordo com o Nuno e o que escrevi não vai contra isso. Escrevi sob o ponto de vista do programador e não minimizei o que é feito pelo bom gestor. Falo apenas de más práticas de gestão e não abarco toda a gestão de projetos. É apenas um artigo de opinião.

  16. José Simões says:

    Na minha longa experiência o principal problema com que sempre me defrontei foi a dificuldade de estimar à priori quanto tempo se vai demorar a realizar uma tarefa, mesmo que bem definida à partida.

    Aliás à muito muito tempo nos li algures “uma tarefa demorará sempre o dobro do tempo previsto – no mínimo” e “se se previr o dobro de tempo em cima de uma previsão inicial, a regra aplica-se na mesma, demorando 4 x a previsão inicial”.

    • Luís Soares says:

      sem dúvida José,
      Nesse aspeto, o Scrum é bom. Já prevê que os humanos são péssimos a estimar de forma absoluta e portanto propõe que o façam de forma relativa.

      • Malic X says:

        O Scrum é uma falácia. Só deve ser utilizado quando a equipa e o product owner têm uma relação forte. Isto é pode e deve ser utilizado para manutenções, evoluções de algo que já exista. Para coisas novas criativas e interessantes, esqueçam. Nesses casos é necessário gestão de projetos a sério (PMBok ou Prince 2).

        E por fim, estão a esquecer-se que o desenvolvimento de software está cada vez mais transformado um fábrica de software. Logo numa fábrica, quem executa, maioritariamente programadores neste caso, vai ter que fazer muita coisa repetitiva, com standards, com reutilização de código, com ferramentas automáticas de testes, muito controlo de qualidade e assim sucessivamente.

        Portanto a treta do programador ser um artista, não tem cabimento nas fábricas de software. Isso é para alguns laboratórios de investigação e pouco mais. O programador tem que executar de acordo com as regras e pouco mais, tal como em qualquer indústria.

        Malic X (PMP, CSM, CSPO e brevemente CBAP)

        • Luís Soares says:

          sou apenas um eng. de software e dei apenas uma opinião de programador.

          é inútil argumentar com quem fala lá do alto e assina com os seus certificados.

          ser gestor de software não é só tratar os programadores como uma manada de “minions”. há a componente humana.

          portanto de certeza que nunca irá ser meu chefe e nem desejo isso a ninguém 🙂

  17. Mark says:

    Ou seja não gerir projectos á portuguesa….

  18. João says:

    Considero o artigo excelente ;). Parabéns pelo mesmo.

    Pela minha experiência revejo-me em alguns temas abordados no artigo, no entanto tenho a dizer que já trabalhei com diferentes gestores de projectos, e alguns posso considerar que eram o gestor ideal (o tipo de gestor que quando é para brincar é para brincar, mas quando é para trabalhar é para trabalhar) sempre a ajudar a equipa e não sentado no seu canto a mandar “bitaites”.

    Uma questão que considero bastante importante no artigo é considerar sempre a equipa em si e não só determinados elementos, acho que para uma equipa funcionar bem é necessário que todos estejam enquadrados com o que se está a implementar. E sim levantamento e análise de requisitos, um funcional e um técnico (na minha prespectiva obrigatoriamente) para que não sejam ditas coisas que se podem fazer, mas depois do técnico analisar não ser possível da forma como o funcional o disse que iria fazer.

    Mais uma vez parabéns pelo artigo.

  19. Nuno Rodrigues says:

    Boa tarde,

    Devo dizer que não concordo com muitas coisas que são escritas neste artigo, desde logo na primeira linha ‘A gestão de projectos não é uma ciência exacta’ acho que tá totalmente errado. A Gestão de projectos é uma ciência exacta não tenham duvida disso, o que não quer dizer que os projectos não possam ter as especificidades e características próprias.

    Tive o cuidado de aceder ao blog do escriba e do seu e-mail, e reparei num ponto curioso, não há qualquer referência a alguma certificação em gestão de projectos. Que fique claro que não duvido um minuto nas qualidades técnicas do autor, mas terei de duvidar dos conhecimentos em gestão de projecto.

    Posto isto, acho que se querem publicar artigos acerca de gestão de projecto, um bom principio talvez fosse que algum especialista escrevesse sobre eles.

    Não sou certificado nem especialista, apenas passo 90% do meu tempo a trabalhar em ‘ambiente’ de projecto.

    Obrigado

    • Luís Soares says:

      Olá Nuno,

      Obrigado pelo seu comentário.

      Assentando em pessoas e nas suas complexidades é complicado ser exato.
      “A gestão é a ciência social que estuda e sistematiza as práticas usadas para administrar.” Ora se é uma ciência social, não pode ser exata. Sei que é da Wikipedia, mas passa a ideia.

      Verificou mal os certificados então. De qualquer forma, a ideia não era essa. Se leu o artigo todo, pode verificar que foi escrito sob o ponto de vista de um *programador* e não de um gestor. É apenas um artigo de opinião de quem também está no terreno; não é um manual de gestão.

      Não sou nenhum especialista com 30 anos de gestão, mas a opinião de quem está lá dentro e faz as coisas acontecer também conta. Assim, sendo que também está em ambiente de projeto, qual a sua opinião sobre o tema do artigo? Que erros comuns já observou na gestão de projetos? Nunca passou por nenhuma situação das descritas?

      Obrigado

      • Nuno Rodrigues says:

        Luís,

        Agradeço desde já a resposta. De referir que não foi minha intenção ser ofensivo no meu comentário, ao reler posso ter passado essa ideia.

        Efectivamente não vi o CV com a atenção merecida uma vez que não reparei na certificação que possui do IPMA. Agora devo dizer que tendo essa formação com certeza que concorda que a actividade de gestão de projectos é totalmente definida e esquematizada, e por isso discordo quando refere que não é uma ciência exacta.

        Quanto à minha experiência pessoal devo dizer que passei um pouco por tudo, mas na minha opinião os factores chave de sucesso de um projecto são sempre os mesmos:
        1 – Qualidade da Análise de requisitos e especificação de âmbito. Onde incluo os exemplos que referiu de modelos de gestão, metodologias, imposição de uso de determinada tecnologia e dimensionamento;
        2 – Capacidade do Gestor de projecto. Onde incluo a proximidade de equipa e transparência, mas também a capacidade de gestão de expectativas a nível de equipa e cliente.

        Referiu o exemplo do SCRUM, que na sua concepção mais pura admite que não há um âmbito fechado. É muito difícil trabalhar desta forma e é um dos exemplos em que a capacidade do GP de gerir expectativas e entregas vai ditar o sucesso do projecto e a satisfação da sua equipa.

        O facto de ter equipas de diferentes geografias, que considera com um facto negativo, pode perfeitamente ser um elemento positivo noutro projecto, dotando o projecto de uma visão nova da realidade.

        Tudo isto para dizer que, sendo a sua visão sobre a realidade, tenho obviamente de aceitar, mas que não concordo com a maioria. Cada projecto é único e como tal terá características que mais nenhum tenha, a todos os níveis.

        Obrigado!

        • Luís Soares says:

          Nuno,

          Sem problema. https://en.wikipedia.org/wiki/Management
          Aqui diz até que é uma arte. Ter tabelas e diagramas não é sinónimo de ser ciência exata. Podes arranjar uma definição onde diga que é uma ciência exata?

          Sim, é certo que há muita coisa que pode ser feita “by the book”, mas isso não é sinónimo de sucesso… longe disso.

          Eu ter dado o exemplo do Scrum não significa que o defenda de forma fundamentalista. De qualquer forma, o Scrum tem o âmbito fechado: fechado àquilo que o cliente quer e precisa.

          Eu também defendo que cada projeto é único. Daí ter defendido que não se devem forçar tecnologias ou metodologias. Cada caso é um caso e por isso na prática concordamos na maioria das questões…

          • 100% de acordo… Acho incrível esta lengalenga de “não concordo com nada bla bla bla” quando no fim se percebe que concorda com tudo mas tinha de ser do contra…

            Além do mais, e peço desculpa se estou enganado, mas o Sr. Nuno demonstra perfeitamente que é um “gestor de projetos” ou algo parecido… Doeu-se xD

            César Teixeira

          • Nuno Rodrigues says:

            César, se acha que ‘no fim concorda com tudo’ tenho de depreender que não entendeu o que escrevi.

            De referir que, como referi no meu primeiro comentário não sou gestor de projectos, nem ‘algo parecido’. No entanto, faço parte uma equipa que está sempre a trabalhar naquilo que se pode chamar de ‘sede de projecto’, portanto a gestão destes, é algo que me afecta directamente, quando é bem ou mal feita, e passo frequentemente pelas duas situações.

            Não sou do contra por natureza, mas, para bem de uma discussão saudável que neste espaço costuma ser praticada, se não concordar com determinado aspecto digo-o, que foi o que aconteceu.

    • Tenrinho says:

      Se fosse uma ciência exacta não existiam multiplas “certificações” mas apenas uma, não conceitos abstractos de gestão onde se usa e abusa de palavras: holístico, sinergia, conteúdos, validações,stake-holders, e assegurar para designar algo que as próprias pessoas não conseguem definir.

      O problema é mesmo as pessoas não reconhecerem que é uma coisa abstrata e que cada caso é um caso. Depois coloca-se um manager que é expert em projectos de slideware (aqueles de fazer ppts) a gerir um projecto de TI e como ele não muda a metodologia de trabalho porque “é certificado e tem x anos de experiência a gerir projectos. No final admiram-se de sair “coco”.

  20. Steve says:

    Excelente artigo. Continuem com este tipo de publicações sff.
    Já cansa artigos de telemóveis 🙂

  21. Eu só sei says:

    que no meu projecto, repetitivamente mandam-nos fazer coisas inuteis e lindas como o caso de numa imagem, que faz zoom no hover, o click fazer um popup que mostra uma galeria com thumbs. Parece simples, mas são funcionalidades que nem percebem o tempo que demora a configurar (ja nem digo implementar ou criar), mas que as pedem e depois nem as usam e nem as divulgam…

    Os gestores/donos dos projectos mesmo quando percebem pouco ou nada do que estão a pedir deviam ver a pertinência e a dimensão de certas funcionalidades.

    Acho que é um dos defeitos da gestão de projectos, e algo que frustra quem ganha a renda e pouco mais a fazer sites web,ou outro tipo de projecto qualquer, é estar a trabalhar em coisas que nunca têm divulgação nem são utilizadas. Matam-se moscas com canhões e isso custa.

    • Luís Soares says:

      pois… lá está… o afastamento entre os programadores e a realidade do projeto e cliente.
      os programadores são considerados uns geeks incapazes de falar com o cliente.. e portanto os requisitos chegam-lhe já todos mastigados (fazendo lembrar aquele jogo infantil de se contar uma história ao ouvido, em cadeia; no fim já não tem nada a ver)

  22. André Correia says:

    O artigo está excelente, mas julgo que seria de bom tom publicar a fonte de onde o mesmo foi copiado. Tenho consciência que vivemos num país de plagiadores, com o exemplo a vir diretamente dos nossos governantes. Quem não se lembra do caso flagrante do projeto-lei sobre a taxação dos suportes de armazenamento digital, copiado quase na íntegra da lei espanhola? Não me parece que frases como “Qualquer programador se incomoda(…)” e “No entanto, sou cético no que toca (…)” tenham sido escritas pela Marisa Pinto, uma por estar em português do Brasil e a outra por estar no género errado. Quando muito a Marisa pode estar cética…

    • Marisa Pinto says:

      Caro André… realmente a ignorância é um dom…

      O post não foi copiado de lado nenhum, é da autoria do Luís.
      Eu sei que às vezes custa aceitar que as pessoas são capazes de fazer estes artigos brutais… pois bem, se lês o pplware, terás que te habituar a isso!

      Aquele abraço.

  23. David Bolas says:

    Muito bom artigo! Luis Soares como sempre a revelar ser um profissional de excelência. Tivessemos nós a sorte de ter muitos mais profissionais assim noutras áreas e seríamos uma nova Suiça

    • Miguel Costa says:

      Uma nova Suiça? Caro amigo, que grande utopia que para aí vai. Este país está próximo de ser um novo México, isso sim.
      Ontopic e relativamente ao artigo, está muito bem escrito e dou desde já os parabens ao Luís, muito bom mesmo. De referir que acertou mesmo na mouche na parte inicial do artigo, é que conheço mesmo um desses GP que afirma à boca cheia que gerir programadores é como gerir uma fábrica!

      Continuação de bom trabalho.

  24. Igo Feliphe says:

    Parabêns pelo artigo.Muito bom.

  25. Luís Soares says:

    Obrigado a todos pelos elogios! Espero que gostem deste novo artigo: https://pplware.sapo.pt/pessoal/opiniao/os-erros-mais-comuns-de-um-programador/

    Cumprimentos

  26. Malic X says:

    Errado
    Cada vez mais o software será encarado como uma linha de montagem. Todos os grandes fabricantes estão a investir nas chamadas “fábricas de software”.
    A componente criativa é tratada fora da fábrica, em departamentos de marketing e de comunicação.
    As metodologias sejam elas ágeis (Scrum, Agile) ou clássicas (PMI, Prince2) são fundamentais para o sucesso.

    A ideia de deixar os programadores sozinhos a “criar” é o maior disparate que já vi.

    Mas clao para brincar ás APPS até serve, mas para software a sério (clássico) ou em APPS esqueçam.

    • Luís Soares says:

      Olá Malic X

      Concordo com quase tudo o que disse. Menos na sua visão distópica do desenvolvimento de sw em modo linha de montagem. Passo então a um raciocínio lógico…:

      tudo o que dá para colocar numa linha de montagem pode um dia ser automatizado. É assim que tem sido ao longo dos anos. E portanto, vai desempregar todos os programadores, especialistas de UX, designers, gestores de projeto, analistas, sys admins, etc etc etc. (A não ser que afirme que desenvolvimento de software é só programadores, o que também dava pano para mangas).
      Os marketeers e gestores de topo é que vão decidir o que querem. E vão dar um clique no botão “criar site”.
      É este o futuro que resulta do seu sentido visionário.

      Também há outra possibilidade resultante da sua visão: os programadores serão operários fabris… Sem direito a pensar e a questionar… À imagem do filme “Modern Times”, o seu futuro tem centenas de operários de colarinho azul mal pagos. Vão ser meros executantes dos comunicadores e marketeers…….

      • Malic X says:

        Os programadores sim, cada vez mais máquinas.
        No entanto, existem outras funções criativas que vão continuar a sobressair e com valor acrescentado.
        O mundo está a mudar meus caros. Só com regras se consegue produzir, seja software ou noutra indústria qualquer.
        Em todas as indústrias existem criativos, mas o produto é feito em fábricas por operários e robôs.

        Noutros tempos também me iniciei no assembler e na linguagem C, em que tudo tinha que ser inventado, mas felizmente isso mudou.

        Divirtam-se

        Malicx

        • Luís Soares says:

          “O mundo está a mudar meus caros.” = mumbo jumbo
          ‘amigo’.. o mundo está a mudar há 4,54 x 10^9 anos… essa é daquelas frases que não acrescenta valor e só serve para mandar bazófia (i.e. swag) para o ar. vou dizer umas também: “amigos, o Google tem os dias contados!” “amigos, isto agora web 3.0 é que está a dar!” “amigos, este século vai ser espetacular!” “amigos, temos de unificar as sinergias dos departamentos!”

          “Os programadores sim, cada vez mais máquinas.”
          boa sorte a gerir projetos dessa forma…

          “Só com regras se consegue produzir”
          alguém disse o oposto? ou é daqueles que acha que Scrum é “tudo ao calhas”? e alguém disse que Scrum se devia usar sempre?

          “mas o produto é feito em fábricas por operários e robôs.”
          óbvio que há tarefas mais repetitivas que outras… o que sou contra é *APENAS* ao encarar do programador como um simples executante.

    • bin says:

      1. http://en.wikipedia.org/wiki/Faulty_generalization
      2. http://en.wikipedia.org/wiki/Argumentum_ad_populum
      3. A componente criativa na criação de software vai, felizmente, muito para além do marketing e da comunicação.
      4. Nem as metodologias ágeis nem as clássicas ditam que o programador seja um júnior inapto para tomar decisões de alto nível. Os gestores é que inventaram isso, porque…
      5. Numa perspectiva financeira, as empresas estão ansiosas para que se atinja a distopia que descreve no seu comentário.

  27. Luís Soares says:

    “A ideia de deixar os programadores sozinhos a “criar” é o maior disparate que já vi.”
    concordo se estiver a falar de tomar decisões de negócio.
    Nunca disse que os programadores devem tomar decisões de negócio..
    Mas é isso que parece ter percebido.
    Isso é o http://en.wikipedia.org/wiki/Cowboy_coding

  28. Ana Rito says:

    Mais um excelente artigo! Parabéns pelo bom trabalho!

  29. António says:

    Muito bom. Estou a passar por todos esses pontos numa “metamorfose” recente da empresa onde (ainda) trabalho e são infelizmente bem reais. Acho que conseguiram acertar em todos (vocês e eles).

Deixe um comentário

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.