O gerente continua alterando a especificação de requisitos após cada demonstração [fechada]


21

Antecedentes do meu ambiente de trabalho

Meu gerente não tem experiência ou conhecimento de computadores ou software. É muito provável que ele não tenha visto código de nenhuma forma (nem mesmo a uma distância física de três metros ou menos) em sua vida.

Não há ninguém que entenda a complexidade do que me pedem para implementar. A tal ponto que se eu semi-codificasse ninguém saberia.

No teste de Joel, obtemos uma pontuação inacreditável 0.

Os problemas

  • O gerente e outras vezes "sênior" continuam alterando a especificação de requisitos. Alterações que, se uma boa engenharia for feita e não "correções" irregulares, exigirão alterações no design subjacente.
  • Não existe absolutamente ninguém que veja o código (provavelmente porque ninguém sabe como, ou mesmo se deve ser feito), o que significa que ninguém jamais será capaz de:
    • Aprecie a complexidade do problema ou a elegância da solução.
    • Sugira melhorias para a abordagem.
    • Aprecie a qualidade do código.
    • Indique onde o código pode ser aprimorado.
  • Muito jargão é usado, o que faz sentido gramaticalmente, mas não faz sentido de outra maneira.
  • Não se sente, se comporta ou funciona como uma empresa de software.

A questão

O que deveria ser feito? Especialmente em relação a não haver ninguém que apontasse melhorias no meu código.

Atualizar

Para responder à pergunta do HLGEM (e possivelmente de outros) sobre o que eu fiz para tentar corrigi-lo. Ofereci-me para configurar o Redmine e introduzir o controle de origem para todos. Eu disse que recomendaria distribuído (git ou mercurial), mas também falaria sobre os centralizados e deixaria a equipe decidir. A resposta foi que as coisas estão sendo feitas e serão feitas dentro de semanas. Não vi isso nem sei se outras partes da empresa o usam.


36
para antecipar a resposta óbvia: EXECUTAR !!
keppla

3
A menos que haja algo importante que você não esteja nos dizendo, comece a procurar um novo emprego.
Zachary K

11
"O gerente e outras vezes" sênior "continuam mudando a especificação de requisitos." Bem, ter uma especificação marcaria 1 no teste de Joel. : P
R. Martinho Fernandes

11
Nenhuma organização pontua menos que 2 no teste Joel apenas por causa de gerentes não técnicos. Há várias coisas que você e outros membros técnicos da equipe podem fazer sem a contribuição de gerentes não técnicos para aumentar sua pontuação. Você não tem desculpa para culpar apenas o gerente.
maple_shaft

6
Parece que você também tem a equipe de vendas como gerente de software, simpatizo.
wildpeaks

Respostas:


30

A versão curta :

Corre.


A versão um pouco mais longa :

Se o gerente não souber como executar um projeto, e se o senior concordar com ele, você terá quase nenhuma chance de consertar as coisas.

Para gerenciar projetos de software, um gerente precisa entender algo sobre software. Se os gerentes não, eles precisam aprender primeiro. Quais são as suas chances de convencer sua gerência e seus séniores a entenderem tudo errado? Quais são as chances de você lhes ensinar alguma coisa?

Eu já estive em uma situação semelhante uma vez (apenas não havia seniores). Parei depois de um ano terrível e nunca olhei para trás (exceto com nojo).


3
+1 para esta citação: "Se o gerente não souber como executar um programa e se o sênior concordar com ele, você terá quase nenhuma chance de consertar as coisas."
maple_shaft

17

... continue alterando a especificação de requisitos. Alterações que, se uma boa engenharia for feita e não "correções" irregulares, exigirão alterações no design subjacente.

Parece o mundo real. Isso acontece o tempo todo, em qualquer lugar. Sim, é péssimo, mas é suportável com algum tipo de atitude ágil. Além disso, uma medida da qualidade do software é sua maleabilidade. Tome isso como um desafio.

Muito jargão é usado, o que faz sentido gramaticalmente, mas não faz sentido de outra maneira.

Novamente, não parece tão familiar ;-)

Não há ninguém que entenda a complexidade do que me pedem para implementar.

Nem mesmo você? Se você entende isso, então há uma pessoa no espelho que entende isso. Portanto, sua responsabilidade pelo bem-estar da sua empresa é provavelmente mais pesada do que o seu título formal sugere. Se você entende os problemas e seu gerente não, é de sua responsabilidade deixar as coisas claras para a gerência, para que elas possam direcionar adequadamente a empresa. Pode ser razoável supor que seus gerentes mais próximos deve ser tecnicamente competente (não necessariamente tão competente quanto você - enquanto eles são gerentes, você é o especialista - mas pelo menos um pouquinho competente), mas se eles não são obviamente e você poderia ajudá-los, por que não?

Uma solução escapista simples é mudar de empresa. Mas como outra opção, considere implementar os itens do teste Joel. Embora os itens de 5 em diante exijam mais cooperação com a gerência, os itens de 1 a 4 são tais que você pode configurá-los sem perguntar a ninguém.

Dito isto, ninguém aqui no SE pode conhecer sua situação exata. É possível que você esteja em uma empresa lotada de idiotas incompetentes, e fazer algo de bom com essa bagunça pode ser demais para qualquer um. Você deve avaliar a situação você mesmo.


Que tal alguém apontar meus erros? Me ajudando a melhorar e aprender.
Jungle Hunter

4
@ Jungle Hunter: É claro que seria mais fácil estar em uma empresa onde tudo foi prontamente configurado, todo mundo já está seguindo todas as melhores práticas imagináveis ​​etc. para que você possa ser apenas um aprendiz e imitar os outros. Mas você também pode melhorar e aprender muito assumindo a responsabilidade e sendo ativo na melhoria de sua empresa. Melhorar e aprender está finalmente em suas próprias mãos. Outras pessoas podem ajudar, mas seu chefe não precisa ser um deles.
Joonas Pulakka

Sim você está certo. Estou tentando melhorar, mas acho que meus esforços estão sendo vistos mais como reclamar do que tentar melhorar. Honestamente, meus esforços são os dois, mas vamos ver se consigo fazê-los ver a segunda metade - tentar melhorar.
Caçador de Selva

@ Jungle Hunter: Entendo, a linha entre reclamar e melhorar pode ser confusa . Mas nunca é demais se inclinar para o lado construtivo.
Joonas Pulakka

4
@Joonas: Eu estive em empresas onde introduzi o VCS, revisões de código, dei seminários em C ++ e outros itens para melhorar a qualidade do código. E eu estive em uma empresa praticamente como o OP descreve. Se for um caso sem esperança, você deve admitir a derrota e procurar um emprego em que sua luta seja recompensada, permitindo que você tenha sucesso.
SBI

16

Você diz em um dos comentários que este é seu primeiro emprego. Os gerentes geralmente não são técnicos em lugar algum, exceto na minha experiência em uma loja de software dedicada. Isso faz parte da vida, apenas se acostume com isso.

Você chora e se queixa porque não há ninguém que aprecie a elegância de suas soluções. O verdadeiro problema aqui não é que não haja ninguém para apreciar a elegância de suas soluções, mas que não haja ninguém para lhe ensinar que suas soluções não são tão boas quanto você pensa que são. Praticamente todos os novos programadores superestimam suas habilidades reais. Sem mentor, não há ninguém para ajudá-lo a melhores práticas. Se não houver ninguém lá para orientá-lo, participe de grupos de usuários locais, participe ativamente e leve alguém para orientá-lo. Melhor ainda, isso o ajudará a encontrar um emprego melhor eventualmente.

Você marca um zero no teste Joel? Se você é o único codificador (e parece que você escreveu), eles não estão usando o controle de origem? O que está impedindo você? Se você não é o único codificador, por que ninguém pode fazer análises de código? Todos os nossos desenvolvedores fazem revisão de código, não é uma função de gerenciamento, especialmente quando os gerentes não são técnicos.

Os requisitos mudam em praticamente todos os lugares. As necessidades comerciais mudam continuamente e os não programadores geralmente não conseguem visualizar o que o programa fará até que eles façam algo. Então eles percebem que não é o que precisam. É por isso que o Agile surgiu realmente porque os métodos mais antigos não estavam lidando bem com essa mudança.

Configure o rastreamento de erros, mesmo que o gerenciamento não queira inserir os dados. Seja responsável por inserir novos erros / recursos à medida que alguém os mencionar. Realmente ajuda poder dizer ao gerente, quando ele quer uma mudança, que lhe foram atribuídas outras 27 coisas, e aqui está a lista. Qual você deseja que eu mova para baixo na lista de prioridades para acomodar essa nova alteração? Isso ajudará no momento da revisão, pois você poderá contar o número de correções e recursos implementados. Se todo mundo não está usando, pelo menos você pode fazer o seu próprio trabalho. Se eles não permitirem a instalação de nenhum software, use uma planilha do Excel. Tome alguma iniciativa. Depois que você mostrar os resultados, outros ficarão mais interessados. Se você acha que há muito trabalho para uma pessoa, o rastreador de erros o ajudará a provar isso.

Não faça demonstrações de aparência polida! As demonstrações devem parecer rabiscadas com caneta em um pedaço de papel. Quanto mais polida a interface, mais a pessoa não técnica pensa que está concluída.

Mesmo que ninguém saiba se você não segue as práticas recomendadas e o código semi-difícil, por exemplo, você saberá e entrará em maus hábitos desleixados. Isso não o servirá bem em seu próximo emprego. Portanto, faça as coisas o mais próximo possível da maneira correta, dadas as circunstâncias. Certifique-se de escrever testes (considere isso como parte do tempo de desenvolvimento e reserve tempo para fazê-lo em qualquer estimativa que você administre, mesmo que você não diga especificamente que isso faz parte da estimativa) e use-os para garantir mudanças posteriores não quebram outra coisa.

Você precisa ver isso como uma oportunidade inestimável para crescer e melhorar. Você tem mais liberdade na codificação real do que muitas pessoas têm nessa fase da sua carreira. Portanto, considere isso uma oportunidade para criar um portfólio de projetos implementados com sucesso. Quando você procura o próximo trabalho, ser capaz de apontar realizações como controle de origem instituído, rastreamento de erros instituído, número X criado de implementações bem-sucedidas de projetos etc. fará com que você se destaque do resto.

Você também tem uma grande oportunidade aqui para aprender como gerenciar as expectativas para cima. Isso é algo que será útil no resto de sua carreira. Você não tem nada a perder ao tentar fazer isso aqui, as coisas já não são boas. Mas você pode aprender as habilidades políticas que o ajudarão em lugares melhores posteriormente. Aprenda a fazer uma análise de custo-benefício. Aprenda a subestimar o domínio comercial para que você possa ser convincente ao conversar com eles. Aprenda a falar em termos de benefícios para a empresa e lucro. Faça estimativas para todas as tarefas que lhe foram atribuídas e, mesmo que não correspondam ao que o gerenciamento lhe oferece, mantenha registros do que você estimou e do que foi realmente necessário para melhorar sua capacidade de estimar o trabalho. Depois de mostrar que suas estimativas historicamente foram mais precisas que as de gerenciamento, eles serão mais propensos a ouvir quando você diz que a estimativa é muito baixa. Mas é preciso construir um histórico primeiro de estimativas mais precisas e, mais importante, da capacidade de entregar os projetos e fazê-los funcionar. Novamente, é uma boa habilidade a ter à medida que você avança em sua carreira.

Acima de tudo, não seja passivo e espere que a melhoria venha de cima.


1
Esta resposta tem partes muito úteis. E algumas coisas que sinto incorretas em entender minha situação. Como, eu mencionei os dois casos, ninguém para apreciar quando é bom. Ninguém para apontar quando eu entendi errado. Eu uso o controle de origem, mas em uma equipe de 2 a 3 ninguém mais. Código, quando compartilhado, é compartilhado usando pendrives e usando o Airdrop. Se você estava lendo o comentário, acho que também mencionei que já instalou o Redmine no meu laptop, que acaba sendo usado apenas por mim. E o mesmo com o git. Tentou implementar isso para todos. Meu nível, recém-saído da faculdade. Senior deve codificar, mas não o faz.
Jungle Hunter

Vou seguir os conselhos sobre a construção de um histórico. Vou lembrar que tenho mais liberdade no meu estágio do que geralmente falo. Eu poderia aprender a gerenciar as expectativas e outras habilidades políticas e pessoais.
Caçador de Selva

3
Pare de dar código a eles em pendrives. Se eles quiserem o seu código, diga a ele que está no controle de origem e mostre como usá-lo.
Hugo Hugo

1
@JungleHunter Quando eles solicitarem seu código, diga a eles que você está no meio de uma alteração que não será executada, mas que eles podem obter a última versão estável do controle de origem.
Kirk Broadhurst

1
@HLGEM "Você chora e lamenta"? Muito duro, com voto negativo apenas para isso.
21714 Ben Ben

6

Se eu fosse você, tentaria encontrar outro emprego. Por quê? Eu acho que você sabe que, infelizmente, seu gerente não é bom. Você deve tentar resolver algumas coisas com seu gerente.

Se você não quiser sair, e / ou não vai falar com ninguém, terá que encontrar alguma coisa. Se ninguém na empresa conhece seu código, como seu gerente deve saber que você atende aos requisitos? Apenas dizendo.


Ele apenas olha para uma demonstração. Diz, vamos mudar isso dessa maneira e dessa maneira. E então há uma enxurrada de jargões.
Jungle Hunter

2
@ Selva, eu não colocaria quase nenhum trabalho em demos, pois elas provavelmente mudarão muito quando ele as vir. Ele soa como uma pessoa visual em primeiro lugar. Você já tentou desenhar capturas de tela de diferentes casos de uso para ele? Isso pode ser muito mais fácil de montar do que protótipos funcionais.
maple_shaft

@ maple_shaft: acho que é uma excelente ideia.
Caçador de Selva

1
@ maple_shaft: Ou talvez, em vez de entregar muito antes do tempo, entregue no final. ;)
Jungle Hunter

1
Conselho trabalho de um estudante do ensino médio ...

4

Converse com seu gerente e com os idosos sobre isso. Explique seus problemas e sugira soluções. Prepare a conversa um pouco para que você saiba a mensagem geral que deseja transmitir.

Após a conversa, aguarde um pouco . Veja se as coisas mudam ou não. Caso contrário, tente implementar você mesmo as alterações e mostre ao gerente e aos idosos os resultados positivos de suas alterações .

Se a conversa não ajudar e suas alterações forem descartadas, você deverá avaliar por si mesmo o quanto gosta de trabalhar naquele local. Sim, o trabalho pode ser ruim, mas talvez o pagamento seja bom e você tenha apenas uma viagem de 5 minutos? Os aspectos positivos do seu trabalho superam os negativos? Se eles não, eu começaria a procurar um novo emprego.


1
Eu falei. Ofereci-me para configurar um sistema de bilhética, introduzir um controle de versão, mas ele não se importa. Ou entenda. Ou ambos. Eu perguntei conversei com ele sobre ter uma especificação confiável e ele concorda. Muda mesmo assim. Ele não é orientado por dados. (Ah, e removido a ênfase no texto da minha pergunta.)
Jungle Hunter

2
@ Selva: Em seguida, execute o mais rápido possível.
sbi 31/08/11

1
Eu concordo com o sbi, se você ainda não tivesse pedido para ser abatido, poderia legitimamente simplesmente sair e fazer isso sozinho. Você já perdeu o quarto e, se eu estivesse na sua situação, começaria a procurar.
maple_shaft

3

Seu problema é que os sistemas de emissão de bilhetes e o controle de versão são questões TÉCNICAS e você deve fazer isso independentemente da entrada de um gerente não técnico. Isso deve ser assumido como uma prática recomendada tecnicamente e, se eles não tiverem essa configuração, você deve fazer isso acontecer.

Você não pode esperar que um gerente não técnico entenda os benefícios do rastreamento de defeitos, controle de origem e integração contínua. É por isso que eles não são técnicos, não devem saber ou se importar com isso, são especialistas em domínio e conhecimento de negócios. A única coisa que eles devem fornecer é orientação e requisitos de alto nível.

Também tenho um gerente não técnico e fui capaz de aumentar a pontuação do Teste Joel de 4 para 8 apenas porque fui e fiz e não pedi permissão.

Seu grupo precisa de um forte líder técnico e ninguém se adiantou.

Confira http://community.rallydev.com/. Eles têm uma edição da comunidade que faz um excelente trabalho de gerenciamento de projetos Agile e rastreamento de defeitos. Isso por si só aumentará sua pontuação no Joel e não custará NENHUM espaço ou tempo no servidor para configurar.


Sim! Essa é a principal questão. Não temos um líder técnico forte.
Jungle Hunter

2

Se esta é uma pequena loja em que você e o outro "sênior" são basicamente as únicas pessoas que codificam, na verdade pode ser sua responsabilidade indicar ao gerente o que precisa ser feito para satisfazer o "Teste Joel".

As mudanças nos requisitos sempre estarão presentes, e seu trabalho é adotá-las, que é um dos princípios básicos do desenvolvimento ágil :

Bem-vindo a mudanças nos requisitos, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.

Mas adaptar-se às novas exigências significa seguir também outros princípios ágeis. No nível gerencial, isso significa que o gerente deve poder apresentar de forma transparente ao cliente que todas essas alterações têm um custo: o escopo do projeto deve ser alterado para atender aos prazos ou os prazos devem ser alterados (o último não é recomendado).

Se esse é um tipo de projeto em que seu gerente é responsável por todos os requisitos, você deve agir como se fosse seu cliente ágil e explicar a mesma coisa para eles (o escopo <--> compromete o prazo )

Mas no nível do desenvolvedor em uma pequena empresa, eu diria que é sua responsabilidade garantir que a parte da codificação esteja em conformidade com as recomendações ágeis.

Estas são algumas etapas que você absolutamente precisa executar e provavelmente precisará executá-las:

  • você deve ter um sistema de controle de versão (leva um dia para configurá-lo para uma equipe pequena)
  • você deve ter scripts de construção para garantir que você possa fazer lançamentos com frequência (também muito rápido de configurar)
  • você deve usar testes de unidade automatizados (essa é uma maneira de codificar e dita radicalmente todo o seu design, por isso pode ser difícil adicioná-los no meio de um projeto fortemente acoplado)
  • você também pode configurar um sistema de integração contínua para garantir compilações e testes automatizados, bem como testes funcionais e de GUI (que são um pouco mais difíceis de escrever)

Lembre-se de que você pode ter um repositório SVN localmente em sua própria máquina. Uma lista TODO simples pode servir como um sistema de rastreamento de bugs de pessoas pobres (um pouco extremo, mas ei). E não há desculpa para não ter scripts de construção.

Além disso, antes de fazer qualquer declaração sobre comprometimentos de escopo / prazo, alguém também precisa fazer previsões sobre quanto tempo um determinado recurso levará. Isso geralmente é feito em "dias ideais" no mundo ágil, o que significa que você deve fazer o possível para prever o esforço relativo de cada recurso e, em seguida, usar sua velocidade de codificação real para ver o quão bem você previu (e dimensionar a "curva" de acordo) )


Para "vantagem competitiva do cliente" é a chave. Ainda hoje, perguntei a ele por que ele faz isso, diz, para impressionar o cliente. : |
Caçador de Selva

Eu tenho o git / mercurial para mim. Mas eu faço o teste manualmente agora. Eu deveria olhar para testes de unidade automatizados.
Jungle Hunter

1

Acho que faltam camadas de responsabilidade em sua equipe. Deve haver um gerente de projeto, analista de sistemas, analista de negócios e desenvolvedores. A função de gerente de projeto é responsável por definir e aplicar a estratégia de comunicação do projeto do cliente (entre outras tarefas).

Os gerentes não são obrigados a entender código ou complexidades. A necessidade de entender, recursos, custo e risco.

As versões do código fonte, a qualidade do código, a complexidade, etc. são de responsabilidade do gerente ou do desenvolvedor sênior.

A solução é:

1-Definir a estrutura da equipe do projeto e suas responsabilidades

2-Educar o gerente em casos de falhas de software causadas por mau gerenciamento - Fique longe de detalhes técnicos. Você pode encontrar alguns exemplos pesquisando no Google.


"Fique longe de detalhes técnicos." Vou tentar resistir. ;) Obrigado por apontar isso.
Jungle Hunter

0

Especialmente em relação a não haver ninguém que apontasse melhorias no meu código.

Não foi possível tentar configurar revisões de código para que haja pessoas visualizando o código? Existem convenções e padrões que ajudariam a dar alguma estrutura ao código? Presume-se que você não seja o único desenvolvedor lá, é claro.

Enquanto você provavelmente está em um lugar não muito bom, parece que está funcionando no final? Os projetos estão sendo realizados e as coisas estão avançando? As coisas estão sendo feitas? O programador de fita adesiva seria o artigo de Joel que você pode querer ler.


Estou pensando em mudar minha equipe para uma que possua pessoas que possam ver meu código. Ou tente entrar em contato com o pessoal para revisar meu código. Como eu disse nas perguntas, agora não há ninguém que possa fazer isso.
Jungle Hunter

0

Opção 1 - diga a eles 'com todas as alterações que você está fazendo neste projeto, quando o implementarmos, o sistema funcionará muito lentamente' ou 'o cliente não conseguirá descobrir'. Seus gerentes não se preocupam com o código de espaguete, mas se preocupam com o cliente. Lance o problema para eles em termos do que compreendem, não em termos de escrita de código.

Opção 2 - dê o que eles querem. Quando eles reclamam de algo que você diz "mas foi o que você pediu"


Antes de "correr", vou fazer exatamente isso. Se eles querem mudar, eu os informarei que não é uma mudança menor aqui e ali, por isso levará muito mais tempo. Quando o cliente não parece feliz, eles não têm o que reclamar, porque eu dei o que eles queriam.
Jungle Hunter

Caçador da selva @ - Nem todo mundo tem a opção de deixar o emprego, às vezes você tem que transcender a situação. Descobri que a melhor maneira de lidar com a loucura é devolvê-la às pessoas loucas. Somente os muito loucos podem argumentar contra sua própria loucura. boa sorte.
JQA
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.