Como fornecer valor? [fechadas]

As metodologias ágeis são tão populares porque são muito bem-sucedidas em fornecer apenas as coisas que fornecem valor comercial o mais rápido possível. Tudo o que é feito e que não agrega valor aos negócios, independentemente de quão bacana, engenhosa, legal ou inteligente é um desperdício de dinheiro.

Concentre-se no que é importante

Os desenvolvedores não estão preocupados com o valor do negócio porque eles não são pessoas de negócios, se eles tivessem obtido um MBA e não um grau de CS. O que as metodologias ágeis como SCRUM, por exemplo, fornecem transparência, prioridade e direção aos desenvolvedores sobre o que é importante para os negócios e ainda permitem que os desenvolvedores tenham controle sobre a parte do processo de desenvolvimento. o tempo que muitos desenvolvedores desperdiçam fazendo e refazendo apenas por uma questão de "hacking" ou "seria legal se" codificasse.

Engenheiro do LifeCycle

A manutenção em projetos ágeis é muito muito menos custosa que projetos em cascata, porque a manutenção é incorporada ao processo por meio do conceito de Dívida , coisas que podem não ser ideais, mas úteis, são documentadas e listadas como um trabalho potencial a ser feito posteriormente no backlog, tudo é rastreado, priorizado e contabilizado. Otimização prematura desnecessária e código de gravação para recursos que não são solicitados pelo proprietário do produto; portanto, não agreguem valor ao negócio e não se acostumem ou aumentam a complexidade por causa do "design", causando mais problemas de manutenção do que qualquer outra coisa. O melhor de tudo é que se você acertar na hora certa da primeira vez, não haverá muita manutenção para fazer mais tarde.

Adicionando valor como legado

Melhorar o processo e a cultura é a única coisa que você pode "deixar para trás" que será de qualquer valor duradouro. "Clean Code", que é o paradigma do Design, não sobreviverá ao primeiro contato com um desenvolvedor de manutenção Junior, ou mesmo um Senior, na maioria dos casos. Todas as bases de código de qualquer tamanho não-trival se transformam em um Big Ball of Mud através da entropia eventualmente, isso é inevitável. Mas mudanças no pensamento e processo duram de projeto para projeto.

Não sei se entendi totalmente a sua pergunta (é um pouco complicada), mas acredito que a mais importante seja a atitude orientada para o cliente. Pode ser ainda mais importante do que um grande conhecimento técnico e habilidades de codificação. Um ótimo programador sem orientação para o cliente pode facilmente montar um aplicativo tecnicamente incrível, com alto desempenho e sólido - que acontece de fazer algo completamente diferente do que o cliente realmente queria.

A programação é basicamente sobre a tradução de desejos e idéias vagas e obscuras para formas compreensíveis à máquina - portanto, necessariamente rigorosas e restritas. Uma grande parte desse processo requer habilidades de pessoas como comunicação, empatia, gerenciamento de conflitos, etc. Não necessariamente todos nós desenvolvedores precisamos dessas habilidades, mas quanto mais, melhor.

Isso é algo que eu raramente vi de consultores por razões óbvias. A melhor maneira de agregar valor é tornar-se dispensável por boas razões. por exemplo. Faça o seu trabalho compreensível. Mantenha co-desenvolvedores no loop. Ensine as técnicas adequadas aos co-desenvolvedores etc ...

Primeiro, o cliente tem que estar totalmente investido na ideia para que qualquer valor real ocorra. Como desenvolvedores, devemos procurar resolver os problemas que os clientes enfrentam ou encontrar formas de aprimorar o que eles fazem. Minha opinião é que o usuário comum gasta muito tempo coletando dados, enquanto o trabalho real deles deveria estar usando, ou analisando esses dados, não coletando-os.

Um problema em obter o cliente investido é o efeito "campo dos sonhos". Muitas vezes os clientes não sabem o que realmente querem até que algo seja construído para eles. É por isso que muitas vezes há tantas mudanças de requisitos depois do fato. O cliente não entende o que é possível até ver algo concreto que possa entender.

Um bom desenvolvedor entenderá isso, entenderá as necessidades do cliente e tentará antecipar quais recursos trarão valor que o cliente ainda não imaginou.

No meu trabalho, há momentos para codificar (porque o recurso realmente precisa ser colocado), e os tempos para justificar não alterar o código (quando o risco não é grande).

Parece-me que o que aconteceu com você é que você mudou de programador para engenheiro. Um engenheiro não é um macaco de código. Um engenheiro percebe o impacto do que ele faz e os leva em consideração antes de agir. Eu deveria dizer engenheiro "bom", suponho.

Em relação aos recursos "secretos" / trabalho. Existem tempos (e culturas de trabalho) onde você sabe que algo precisa ser feito para consertar isso, e você gastou muito esforço para convencer os tomadores de decisões a aceitar que esse trabalho é necessário. Depois de ouvi-lo pela primeira vez (ou fingir ouvir, de qualquer forma), eles concordam que vêem seu ponto de vista, mas não podem justificar o custo e o risco do que quer que você queira fazer.

Você então vai e faz de qualquer jeito. Uma vez obtido o protótipo e 80% funcional, você o revela aos seus colegas e gerentes e tomadores de decisão, que, pensando nisso como "na maioria das vezes, precisando apenas de alguns ajustes", dizem para você ir em frente e finalizá-lo. Normalmente, esse tipo de coisa é feito fora do expediente e é praticamente a única maneira que as coisas normalmente melhoram.

"... é mais importante produzir rápido rápido e barato ..."

Mais do que ser apenas uma declaração sobre a indústria de programação, acho que você praticamente cravou o mantra da nossa sociedade moderna.

A maneira mais importante de agregar valor a um esforço de software é comunicação , não código.

Comunicação escrita

• O projeto tem um wiki? A primeira página do wiki é boa, com uma boa visão geral de alto nível?
• Alguém falou com usuários reais e escreveu um resumo do que eles disseram?

Comunicação verbal

• Você pode atuar como engenheiro técnico de vendas do produto, acompanhando a equipe de vendas para responder a perguntas técnicas?

Observação: marcando isso como wiki da comunidade para que outras pessoas possam adicionar exemplos.

Conhecimento do domínio

O conhecimento prático do domínio no qual você está criando software ajuda a gerar um grande valor comercial.

• Um desenvolvedor da NASA com formação em engenharia aeroespacial.