Responsabilidade sem autoridade é sem sentido - uma solução técnica baseada?

Question

Meu pai sempre diz: "Responsabilidade sem autoridade é sem sentido".

No entanto, acho que, como desenvolvedores, ficamos presos em situações de todo o tempo em que estamos:

• Responsável por garantir o software é "bug free", mas não têm a autoridade para implementar um sistema de rastreamento de bugs
• Responsável por bater os prazos do projeto, mas não pode influenciar requisitos, qualidade, ou recursos da equipe (as três partes do gerenciamento de projetos)
• etc.

Claro que existem toneladas de coisas que você poderia dizer para contornar este problema - encontrar um novo emprego, luta com o chefe, etc ....

Mas o que dizer de uma solução técnica para este problema? Isto é, que tipo de codificação de coisas que você pode fazer em seu próprio , sem ter que convencer uma equipe para corrigir alguns destes problemas - ou que tipo de ferramentas você pode usar para demonstrar por que erros untracked estão prejudicando você , que os prazos estão sendo perdidas devido a problemas de qualidade, e como você pode usar essas ferramentas para ganhar mais "autoridade" sem ter que ser o chefe?

---

*** Um exemplo - o chefe vem até você e diz: "Por que há tantos erros !!?!?" - a maioria de nós diria "Não temos um bom sistema para rastreá-los!", Mas isso geralmente é visto como uma desculpa na minha experiência. Assim que se você poderia apontar para algum relatório (gestores amo relatórios) e dizer: "Veja, é por isso"?

Answer 1

Tudo o que você pode fazer é o seu melhor, não me sinto como se a chave para o software de sucesso é apenas em suas mãos, a sua parte de uma equipe e não tem que ser responsável por tudo.

Obviamente você estiver em um ambiente que afeta negativamente o seu software, mas não pode mudar todo o seu comportamento, então eu recomendo que você comece com o seu, começar a trabalhar como uma equipe de um com seus próprios erros, prazos, requisitos, qualidade e recursos não se incomodam para o resto da bagunça, mas tentar ser o melhor no seu trabalho.

trabalhando como uma equipe auto-dirigida de um mostrando o seu patrão seus planos e relatórios de seu progresso, pedindo mais recursos quando você precisar dele e mostrando-lhe como seus planos ficar afectado quando ele lhes dar a você ou não.

Você pode encontrar mais aconselhar sobre isso no PSP e TSP artigos de wikipedia

Depois de mostrar o seu chefe um bom trabalho e atender seus próprios prazos, com certeza ele vai confiar mais em você e deixar algumas de suas idéias fluem para toda a equipe.

Answer 2

Você não precisa de um sistema de rastreamento de bugs, você precisa de testes automatizados: testes de unidade ou de outra forma. Você pode definir-up testes automatizados com um Makefile. Você pode sempre encontrar caminhos que são bloqueados pela administração, mas isso não significa que não há coisas que você pode fazer dentro das limitações de seu trabalho. Claro, a resposta poderia ser "encontrar outro emprego". Se você não consegue encontrar outro emprego agora, aprender algumas habilidades de modo que você pode.

Answer 3

A resposta é simples -. Você pode começar a usar as ferramentas-se

Melhorar a sua própria trabalho. Se as pessoas querem que você corrigir o código, dizer-lhes para registrar um bug. Mostre-lhes como. Certifique-se que pode fazê-lo sem instalar nada. Eles querem uma atualização de status? Diga-lhes para verificar o bug. Eles pedem abou uma alteração de código que você fez? mostrar-lhes como fazer uma consulta história de controle de origem. ou apenas mostrar-lhes em sua caixa. Comece mostrando-lhes essas coisas funciona .

E quando você precisar os mesmos resultados a partir deles, exigem que eles fazem o trabalho braçal. Quando você não consegue encontrar as mudanças em seu controle de origem, pedir-lhes para começar diffing suas revisões manualmente a partir das fitas de backup. Não faça seu trabalho, ou o trabalho de controle de origem e de acompanhamento de bugs, para eles.

E o mais importante, ao aplicar esta pressão dos pares, ser bom nisso . Moscas e mel e tudo.

Se eles não fizer isso, você pode continuar a ser o único desenvolvedor profissional na sua empresa ou grupo. Ou pelo menos ele vai ajudar pad seu currículo:. 'experiência configurar e instruir outros na CVS e FogBugs para melhorar a qualidade do produto' e similares

Answer 4

Quanto às ferramentas específicas para mostrar que os erros não monitoradas estão prejudicando a capacidade da equipe para código de qualidade de produtos, você tem um catch-22 aqui, pois você precisa de algo para rastrear bugs antes que você possa mostrar o seu efeito. Você não pode medir o que você não pode controlar. Então o que fazer?

Como um exemplo análogo, recentemente tivemos um cara se juntar à nossa equipa, que sentiu a maneira que nós fizemos revisões de código via e-mail foi absurdo. Então, ele encontrou uma ferramenta de código aberto, instalado em sua caixa, tem alguns dos nossos membros da equipe de mente aberta para testá-lo por um tempo, então demoed-lo à nossa equipe de chumbo. Dentro de algumas semanas, ele teve a oportunidade de demonstrar a todos os nossos equipes. A nova cara estava influenciando toda a empresa. Eu já ouvi muitas histórias deste adoção de ferramentas de estilo de guerrilha.

O truque é identificar quem tem a autoridade para tomar a decisão, descobrir o que eles valorizam, e reunindo provas suficientes de que o que você deseja implementar vai dar o que eles valor.

Para um olhar mais amplo para a forma de conduzir a partir do meio ou na parte inferior, de uma organização, confira John Maxwell O Grau Líder 360 .

Answer 5

Se você quer um relatório sobre a qualidade e do impacto sobre a produtividade - aqui está a melhor: http://itprojectguide.blogspot.com/2008/ 11 / alcaparra-jones-2008-software-quality.html Caper Jones tem alguns livros fora e ainda está aparecendo em conferências. Fora de uma boa IDE um desenvolvedor / IT grupo precisa de controle de código fonte (VSS, Subversion, etc) e acompanhamento de problemas

Answer 6

Se um contador é solicitado a produzir um conjunto de conta sem usar a entrada de casal e não equilibrar, ninguém esperaria que o contador para fazê-lo.

No entanto dupla entrada tem estado em uso padrão por contadores desde o século 13.

Ele vai levar um longo tempo antes de nós, como uma profissão tem uma prática padrão que são tão arraigado que em-um irá funcionar sem eles.

Então, desculpe eu espero que vamos ter de enfrentar esse tipo de problema para muitos ano que vem.

Answer 7

Desculpe por não responder a sua pergunta diretamente, mas ...

Eu sinto fortemente que a falha que você se refere é de uma comunicação, e da compete-nos como profissionais para desenvolver nossas habilidades de comunicação para o ponto onde somos respeitados suficiente e confiável o suficiente para alavancar a autoridade que precisamos melhorar o nosso trabalho ambientes e processos da maneira que você sugere.

Em suma, eu não acho que há uma solução técnica que pode resolver todos os problemas criados pela má comunicação no local de trabalho.

Se qualquer coisa, a tecnologia fez com que o atrito da comunicação directa face-a-face.

Desculpe, eu estou fora pela tangente novamente -. Sente livre downmod

Answer 8

Codificação só você só pode manter seus próprios arquivos de origem arrumado, bem comentado, mantenha a baixa contagem de bug com os testes. Mas você vai precisar de ferramentas externas para o progresso de rastreamento e insetos (Bugzilla, yoxel, trac, ferramentas de diagrama de Gantt, Mylyn para Eclipse, um blog, qualquer que seja). Nestes casos, as pessoas e a disciplina e os bons hábitos e a liderança são a força esmagadora, há ferramentas de software e nenhum offert do indivíduo pode ganhar sozinho.