É normal que os desenvolvedores sugiram idéias de recursos aos proprietários de produtos? [fechadas]

Comecei a trabalhar como desenvolvedor recentemente, tendo trabalhado como administrador de sistemas antes.

Meu entendimento de como uma equipe de desenvolvimento de software usando funções ágeis é que a comunicação "o que precisamos implementar" acontece principalmente em uma direção, do proprietário do produto aos desenvolvedores. Os desenvolvedores podem expressar suas preocupações ao proprietário do produto sobre dívidas técnicas, mas apresentar ideias de recursos não deve ser uma de suas principais responsabilidades.

A empresa em que estou trabalhando tem uma visão diferente. Para eles, os desenvolvedores não devem ir apenas aos proprietários de produtos de sua própria equipe para sugerir idéias de recursos, mas também aos proprietários de produtos de outras equipes, se acharem que têm algo a contribuir para o produto dessa equipe. A idéia é que somos todos uma grande equipe <nome da empresa>, e todos os desenvolvedores devem usar seus conhecimentos para aprimorar os recursos que consideram úteis.

Essa abordagem é "normal", por falta de uma palavra melhor? Estou sendo muito passivo, devo tomar a iniciativa e começar a enviar idéias aos proprietários do produto? Por outro lado, a empresa entendeu tudo errado e eu deveria procurar emprego em outro lugar?

Depende do que você entende por idéias de recursos.

No jogo de planejamento, não é incomum os desenvolvedores fornecerem informações sobre uma história que pode acabar na iteração. No entanto, isso é muito diferente dos desenvolvedores que apresentam histórias por conta própria.

Em sistemas maduros, os desenvolvedores podem sugerir uma maneira de contornar um problema conhecido que poderia transformá-lo em uma iteração.

Aprimoramentos podem ser bons, por exemplo, adicionar um gráfico para um relatório, mas os alarmes soariam para mim se os desenvolvedores estiverem apresentando novas histórias de boa-fé. Se houvesse valor real nisso, eu questionaria por que não havia uma história não implementada para isso ou por que nunca surgiu na retrospectiva.

A razão pela qual muitos desenvolvedores são "passivos", como você diz, é porque é preciso uma certa quantidade de conhecimento e experiência no domínio antes que boas idéias de produtos cheguem até você. Mas se eles vierem, não há razão para não sugeri-los e defendê-los.

Lembre-se: desenvolvedores, proprietários de produtos, vendedores etc. estão todos na mesma equipe, com o mesmo objetivo: construir um produto de sucesso. Trabalhe para esse objetivo da maneira que puder.

Com sua palestra sobre desenvolvedores e proprietários de produtos, parece-me que você não tem uma pessoa do meio responsável pelos recursos da sua organização.

Bem, na minha organização, sou essa pessoa. Eu sou o engenheiro de requisitos, aquele que aprendeu a fazer boas especificações e escolher os recursos que resultam em um software de alta qualidade com design de interação amigável. (Em outras organizações, é a pessoa do UX que consegue o mesmo emprego, você pode estar mais familiarizado com esse termo).

E posso lhe dizer: obter uma boa especificação é difícil. Obviamente, os desenvolvedores odeiam fazê-lo. É um fardo para eles - eles estão lá para construir um software, para não pensar em jogos de poder entre as partes interessadas e nos modelos mentais de usuários preguiçosos. Mas você sabe o que? Também é um fardo para os proprietários do produto. Eles não sabem melhor quais recursos o software deve conter do que os desenvolvedores ou os usuários. Criar uma especificação viável é uma habilidade aprendida e, se você nunca aprendeu, não poderá ser bom nisso. Claro, existem muitos desenvolvedores e proprietários de produtos que podem fazê-lo, porque eles precisavam fazê-lo em projetos anteriores. Mas o proprietário ou desenvolvedor médio do produto luta com ele, porque naturalmente não é o trabalho deles fazê-lo. Nem todo mundo que pode dirigir um carro pode projetar um carro; similarmente,

Você pode desenvolver software sem um engenheiro de requisitos? Certamente você pode. Mas colocar todo o peso da especificação nos ombros do proprietário do produto não é justo nem bom para o resultado do projeto. Especialmente porque ele se depara com uma tarefa que é incomumente difícil para ele, obter ajuda e apoio de outras pessoas é muito útil. Se você estiver nessa situação, não olhe para o seu pobre proprietário de produto e diga "me diga o que fazer para você e eu farei você", ele realmente não sabe do que precisa. Mas uma discussão com você o ajudará a articular seus pensamentos e explorar suas idéias.

Quando não há engenheiro de requisitos na estrutura do projeto, há outro problema: não há moderador. Todos os desenvolvedores estão do lado técnico, todos os proprietários do produto estão do lado comercial. Quando as duas culturas se chocam, conflitos podem surgir, com cada lado julgando o outro estúpido e irracional (porque usa seu próprio sistema de valores para julgar). Portanto, converse com o proprietário do produto sobre os possíveis recursos, mas seja educado e paciente, mesmo quando achar que ele não merece; o sucesso do projeto depende de quão bem vocês dois podem se dar bem e, às vezes, tomar a decisão subótima é melhor do que tomar nenhuma decisão devido a conflito. Pode ser útil estabelecer uma hierarquia e dar a última palavra a um de vocês, pois isso evita conflitos de conflito. Se ele receber a última palavra, adie-a mesmo que você ache injusto.

Sobre a parte "passiva": se você não tem idéias, não tente criar algo apenas para mostrar atividade. Se o proprietário do produto já é inseguro e não conhece bons critérios para avaliar suas idéias, idéias estranhas "apenas para ter alguma coisa" tornarão uma situação já difícil ainda mais difícil. Apresentar boas idéias de recursos não é mágico, mas requer conhecimento. Se você não aprendeu isso com os livros, provavelmente precisará de alguns anos de experiência com desenvolvedores, especialmente em projetos nos quais está exposto a usuários ou dados de usabilidade gerados por usuários (análises, medições de satisfação) antes que seu cérebro decida os padrões por si mesmo. e você começa a perceber: há um problema aqui que podemos resolver. Parece que os usuários estão perdendo algo nesta página, O que pode ser? Então você terá boas idéias para compartilhar.

Conclusão 1: Em projetos sem engenheiro de requisitos, é bom fazer sugestões quando você os tiver. Faça com sensibilidade e tato - é imperativo evitar conflitos, mesmo que isso signifique que sua boa ideia é cortada pela raiz.

E se você estiver em uma equipe com um engenheiro de requisitos?

Eu adoro ouvir idéias de recursos de todos! Sim, às vezes as idéias dos desenvolvedores são terríveis (quando querem que a interface do usuário siga a lógica de programação). As idéias dos proprietários de produtos também costumam ser terríveis (quando querem o sol e a lua com um orçamento apertado - ah, e o usuário deve inserir páginas de informações pessoais com a mais alta qualidade de dados, sem receber nada em troca). Mas é meu trabalho apresentar uma especificação que seja boa para todos da equipe. E mesmo que sua ideia nunca funcione, ouvir isso me faz perceber que você tem uma preocupação. Você pode ter escolhido a solução errada a sugerir, mas isso não torna sua preocupação menos válida. Se você o localizou, provavelmente precisará ser abordado (ou eu preciso apresentar uma razão pela qual não é uma ameaça). Se você possui um engenheiro de requisitos responsável pela especificação, nunca hesite em procurá-lo com sugestões. Se eles não o ouvem, estão fazendo algo errado (observe que "considerar" não significa "aceitar").

Um engenheiro de requisitos deve visualizar o projeto do ponto de vista de cada parte interessada separadamente (e às vezes ao mesmo tempo). Nós somos apenas humanos, e falhamos com frequência. Se você está lá para fornecer seu ponto de vista verdadeiro, em vez do ponto de vista que achamos que você tem, sua opinião é muito valiosa.

Você pode ser mais livre em seu comportamento aqui. É meu trabalho fazer a dança da sensibilidade. Não seja abertamente agressivo, isso atrapalha meu trabalho, mas você precisa de menos autocontrole e consciência cultural / comunicacional, porque eu posso assumir a folga. Você também não está flutuando, em uma situação em que existem duas idéias conflitantes e ninguém pode julgar qual é a melhor. Eu deveria saber disso, e se não der certo, é minha cabeça no laço.

Conclusão 2: Se houver um engenheiro de requisitos na equipe, consulte-o com sugestões de recursos do produto. Você não precisa de luvas de veludo neste momento.

E, finalmente, e se não houver engenheiro de requisitos, o proprietário do produto estiver sobrecarregado e lutando por idéias, o chefe estiver olhando diretamente para você e você não tiver idéias para oferecer?

Você tem poucas opções. O primeiro é, como você mencionou, sair. Nem todas as organizações funcionam dessa maneira e, se esse ambiente não for adequado para você, encontre um melhor. Será bom para você a longo prazo.

Você também pode esperar e ver se algo muda. O próximo projeto pode ter um proprietário do produto mais experiente (ou um com mais liderança). Mas você não pode parar para sempre.

A terceira opção é realmente aprender alguns requisitos de engenharia por conta própria. Essa é uma habilidade muito procurada atualmente. Mesmo que você nunca planeje assumir posições em que é engenheiro de requisitos em tempo integral, essa habilidade aprimora seu valor como desenvolvedor, pois permite entender melhor os outros membros de sua equipe (e seus usuários) e torna o processo de desenvolvimento é mais tranquilo. E você não precisa se aprofundar nisso. Um livro básico que explica tarefas, fluxos de trabalho, modelos mentais e modelos de dados centrados no usuário já permitirá identificar muitas oportunidades de melhoria em um software projetado por uma equipe de empresários e desenvolvedores. Don ' Não procure os livros mais espessos, como referência para os acadêmicos (como a recente tradução de Pohl para o inglês) - eles são mais uma lista de todos os métodos possíveis para cada pequeno passo, sem uma explicação sobre como realmente fazê-los. Escolha algo orientado para a prática.

Se você tentar e achar que não tem interesse pessoal na área, tudo bem. Não se force a fazer algo que você não gosta. Mas você provavelmente deve estar procurando emprego em uma organização com uma estrutura de equipe diferente.

Conclusão 3: em vez de esperar anos para obter um entendimento intuitivo, leia um ou dois livros e você já terá boas idéias para fornecer

Sim, é bastante normal.

Há um modelo bem conhecido de 80% de trabalho - 20% no google, onde as pessoas em 20% de seu tempo se dedicam a algo que gostam. Dessa forma, eles não apenas obtêm novos recursos, mas também produtos e serviços totalmente novos.

Estou sendo muito passivo, devo tomar a iniciativa e começar a enviar idéias aos proprietários do produto?

Isso depende da sua personalidade. Eu trabalhei com pessoas realmente apaixonadas, mas também com pessoas sem emoção que fazem o turno de 8 horas e vão para casa.