Quando confrontar um bom líder ou chefe de projeto

Nosso chefe de projeto é um arquiteto de software genial, uma pessoa gentil e atenciosa em geral, um geek por natureza e delicado por voz. Mas, às vezes, nós (meus colegas de equipe e eu) diferimos em opiniões - principalmente sobre problemas de arquitetura de software, problemas de design de sistema, problemas de interface do usuário etc. com nosso líder.

Quando e como (se alguma vez) devemos expressar a diferença de opiniões?

Suponha que você pense que seu chefe está errado. Você tem três opções

• faça o que ele diz e acabe frustrado pensando que você faz algo estúpido - não muito bom a longo prazo
• diga a ele que ele é um idiota - ele o ignorará ou você terá problemas de comunicação - não recebe nada ou magoa.
• diga a ele que você tem preocupações específicas sobre as idéias que ele propõe e explique essas preocupações - qualquer bom chefe explicará sua posição e você poderá tomar uma decisão que seja boa para os negócios. É bem provável que você veja que a ideia dele é melhor que a sua e você ignorou algo muito importante.

Sempre pense no resultado. Na maioria dos casos, você não quer estar certo apenas por ter razão, basta fazer um bom trabalho. A terceira opção ajuda a conseguir isso.

Trate-o da mesma maneira - gentil e respeitosamente ao expressar oposição.

Ser profissional implica respeitar os colegas e os superiores, não significa que você não possa discordar, apenas significa que deve ser educado e respeitoso por natureza.

Quando minha equipe tem uma dúvida ou opinião divergente sobre minhas orientações, eu a considero uma oportunidade de educação, tanto para mim quanto para os membros da minha equipe.

Não é este um exemplo da antiga falácia agressiva ou passiva?

A terceira opção clássica é a assertividade, que permite críticas construtivas e discordâncias educadas .

Igualmente importante - aceitar críticas construtivas (sem necessariamente concordar com elas) e aceitar discordâncias razoáveis ​​(não ficar obcecado com uma disputa entre quem está certo e quem está errado).

http://en.wikipedia.org/wiki/Assertiveness

E, no final das contas, sempre será necessário um tipo de passividade - adiando para o seu superior. Ele é o único responsável pela decisão - capacidade, autoridade e responsabilidade não são a mesma coisa, mas pelo menos devem andar juntas.

BTW - "People Skills", de Robert Bolton, é um livro bom (e bastante barato) para coisas como essa - habilidades de escuta, assertividade e muito mais.

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

Já que você parece respeitá-lo e ele parece ser um cara esperto, por que não perguntar a ele da seguinte maneira:

"Como o seu método / maneira / arquitetura lida com o problema x?" Caso contrário, diga algo como: "Bem, que tal fazer assim, para que o problema x seja tratado?"

Dessa forma, você pode aprender se ele já pensou no "problema x" e se ele aprendeu alguma coisa. Ou, se ele não tiver, ele pensará sobre isso e talvez use sua solução ou pense em outra (talvez você resolva isso juntos).

Eu gostaria de poder apresentar um exemplo mais concreto, mas acho que você deve ter a ideia.

Eu não acho que você chegará a lugar algum com seu chefe primeiro, especialmente se ele não for um programador ou algo assim.

E não há necessidade de dizer que seu caminho é ruim, mas perguntando como ele lida com determinadas situações, ele pode perceber um problema ou ser capaz de lhe dizer por que não é um problema.

Eu espero que isso ajude.

Usando a palavra CONFRONT, você está mostrando que não está abordando o problema com a mentalidade correta.

Não é um confronto. Não é hostil. Não é beligerante ou zangado. É uma discussão de diferentes abordagens, custos e benefícios.

Não entre com seis armas em punho. Apenas diga a ele algo que você pensou. "E se fizéssemos assim?" Quem sabe, você pode convencê-lo.

E se você não sabe - e às vezes não sabe - lembre-se de que ele pode muito bem saber coisas sobre você, sobre orçamentos, cronogramas, requisitos, outras prioridades e assim por diante. Ele não é necessariamente um idiota só porque discorda de você.

Não é errado duvidar de nenhuma decisão ou de uma determinada arquitetura de design / software. A menos que você tenha acabado de iniciar seu primeiro emprego, nesse caso, você estará errado 99% das vezes, porque faltam algumas partes do quadro geral .

Quando você (e / ou a equipe) divergir de opiniões, pergunte ao líder do projeto se ele tem algum tempo para discuti-lo ou talvez até planeje uma pequena reunião (15 a 30 minutos). Desabafar sua própria opinião de forma respeitosa e ouvir por que ele tomou sua decisão de outra forma. Se eu ver como você o descreveu, ele ficará feliz em discutir e compartilhar suas idéias sobre o problema. Ele não diz "porque eu disse" (essas pessoas existem tristemente). Nesse caso, ignore sua própria opinião se quiser manter seu emprego ou desabafar e sair para outro emprego, porque ficará infeliz.

Uma boa discussão pode terminar de várias maneiras:

• O líder do projeto aceitará sua solução como uma maneira melhor de resolver o problema (e ele talvez tenha aprendido uma nova tecnologia, padrão, ... com o qual ainda não tinha muita experiência).
• Você e a equipe podem ver uma parte maior da imagem ou obter uma boa explicação sobre por que você deve fazê-lo dessa e daquela maneira. Você aprenderá algo novo e entenderá que a solução inicial foi a correta, ou talvez até encontre uma maneira de aprimorá-la com as novas informações (embora em algum momento você precise concordar).
• A discussão não ajuda e você ainda discorda. Suga e implementa sua solução (porque ele provavelmente terá mais experiência) ou sai.

De qualquer forma, você deve vê-lo como uma oportunidade de aprender e, desde que seja civilizado e respeitoso, você terá ótimas experiências com essas discussões.

Apenas traga isso à tona!

Da maneira mais civil e mais inteligente possível, normalmente digo "Estou preocupado com esse aspecto, quais são seus pensamentos sobre esse problema em potencial?"

Vou colocar a bola na quadra dele para me educar.

O sinal número 1 de um desenvolvedor e gerente maduro é que eles são capazes de admitir que estão errados. Demonstre ao seu chefe primeiro que todos estão perfeitamente dispostos a admitir que está errado quando está, e deixe claro para o seu chefe que espera a mesma cortesia deles.

Se você tem um bom chefe (e diz que sim), isso geralmente não será um problema! Você verá que pode ter uma discussão construtiva e chegar à melhor solução para todos.

Uma coisa sobre a qual você precisa ter cuidado: verifique se na maioria das vezes você tem motivos técnicos e bem fundamentados para duvidar do design proposto. "Parece errado" geralmente não é suficiente e não contribuirá para uma discussão construtiva. Se isso acontecer com muita frequência, seu chefe não terá escolha a não ser dar um curto-circuito na "discussão" (que é um fato claro, portanto não é realmente uma discussão) e dizer "desculpe pessoal, mas você fará o que eu sugeri até que você possa". demonstrar com fatos por que alguma outra idéia é claramente melhor ".

É por isso que seu chefe é o chefe - para tomar as decisões que os desenvolvedores podem achar difíceis de tomar.

Na minha opinião e como geralmente me comporto com meu chefe:

Sempre dê sua opinião e faça-o o mais rápido possível, enquanto o assunto é quente. Idealmente, quando você está tendo uma discussão sobre um novo problema ou projeto, em vez de fazê-lo mais tarde, quando reuniu sua coragem e as decisões já foram definidas.

Você deve sugerir suas opiniões, preocupações, questões abertamente e garantir que elas sejam apresentadas como sugestões ou preocupações, em vez de impor que isso seja feito dessa maneira.

Crie um hábito e torne-se um melhor comunicador, membro da equipe e, por sua vez, uma equipe melhor. Uma boa equipe fala abertamente sobre as coisas negativas e positivas. Um bom líder de equipe escutará sua equipe e tomará uma decisão considerando as informações fornecidas.

Boa sorte.

Se ele é tão bom arquiteto quanto você descreve, basta abordá-lo de maneira educada, com razões lógicas e específicas para suas preocupações.

Se você tiver tempo / recursos, tente fazer alguns testes dos cenários que provariam que você está certo, ter alguns dados do seu lado é uma grande vantagem.

Depois de falar com ele, ele pode apenas:

a) Concordo com você: problema resolvido!

b) Rejeite-os e explique-lhe o porquê: talvez, afinal, seja você quem está errado.

c) Rejeite-os sem razão: se ele estiver sendo irracional e você tiver total certeza, expresse sua preocupação ao responsável pelo projeto; nesse caso, você realmente precisa de dados frios e, se puder, do apoio dos outros membros da equipe. Isso não deixará o arquiteto muito feliz, mas é a coisa ética a se fazer (imagine que você estava projetando um edifício e viu uma falha na estrutura ...)

Minha pergunta é: quando e como (se?) Expressar as diferenças de opinião.

Absolutamente Sim é a resposta. A menos que você tenha uma situação rara fora de controle , onde até o potencial de turbulência ou perda do emprego por causa disso é tão grande, você deve confrontar outras pessoas quando tiver opiniões diferentes.

A chave real aqui é quando e como.

1º o 'Quando': Todo ambiente é diferente, mas alguns lugares têm reuniões semanais ou discussões em mesas redondas / abertas, onde abordar determinados tópicos é a arena apropriada para isso. A principal coisa que você não quer fazer é fazer com que você menospreze ou torne público algum argumento de design pessoal que esteja entre você e apenas 1 ou 2 outras pessoas. As pessoas que você desafia não gostarão de ser desafiadas e talvez até envergonhadas em público. Nessas situações, tente agendar uma reunião 1 a 1 com a (s) pessoa (s) em questão para detalhar seus pensamentos.

Segundo o 'Como': Se você estiver indo para uma pessoa idosa, certifique-se de ter todos os seus patos em uma fila para apoiar seus pensamentos. Você não pode simplesmente entrar no escritório de pessoas de nível sênior dizendo "Todos os formulários da Web devem ser interrompidos e precisamos fazer o MVC!". Quando perguntado "Por quê?" e você diz: "Bem, é isso que todo mundo está fazendo e está em todas as revistas", não vai longe. Esteja preparado para discussões repetidas e seja questionado sobre a justificativa de seus pensamentos sobre arquitetura, codificação, design, práticas recomendadas, etc. ajuda também. O importante aqui é não entrar em uma batalha do ego ou permitir que as emoções se elevem.

No final, se você tiver sugestões sólidas, justificáveis ​​e lógicas, elas deverão ser levadas em consideração. No entanto, esteja preparado também para que haja apenas pessoas irracionais neste mundo que não querem ouvir ninguém além de si mesmas. Espero que você não esteja apoiado em um canto com esse tipo de personalidade.

Boa sorte!

Não tenho certeza de como você pode se tornar um arquiteto de software brilhante sem cometer erros e ser questionado sobre eles. Eu acho que é seguro assumir que ele já esteve nessa situação antes.

Pessoas inteligentes, maduras e profissionais não podem resistir por muito tempo à atração de melhores idéias. Mesmo se ele estiver chateado no começo por ter suas idéias questionadas, no final, ele deve aparecer e você ganhará respeito por isso. Se ele não é maduro nem profissional, você tem um problema maior, e talvez isso acenda uma luz sobre ele.

Se ele é um arquiteto profissional, ele respeitará e aceitará uma segunda opinião. No entanto, em qualquer caso, você precisa preparar bem a alternativa com base em fatos / conhecimentos e também apresentá-la bem. Lembre-se também de que, em relação à arquitetura, existem basicamente duas possibilidades diferentes para esses problemas:

1. Uma abordagem / design pode ser simplesmente certa ou errada, como na matemática 2 + 2 = 4 e não cinco. Caso esteja errado, você precisará encontrar a solução certa o mais rápido possível, com base em objeções de fato.
2. De longe, a maioria dos tópicos no design de sistemas são abordagens possíveis que não são exclusivas. Também existem outras alternativas de trabalho, que escolher depende da experiência, sabor, tendência, quadro geral etc. Para não supervisionar uma abordagem possivelmente melhor, geralmente há apresentações e discussões, quando os desenvolvedores são incentivados a falar e compartilhar suas opiniões. Mas lembre-se, existem períodos para discussões e períodos para implementação. Na programação ágil, esses estágios são bem definidos.