- Zona de conforto;
- Recalque;
- Tensão, conflito, ameaça;
- Comportamento ajustado;
- Aproximação-afastamento;
- Reações à situações ameaçadoras.

"O mesmo servidor de última geração que sua empresa comprou também foi comprado pelo seu concorrente. O que faz a diferença hoje nas empresas são as pessoas. Pessoas com talento e dispostas a assumir riscos com espírito empreendedor em busca da inovação".

"... eles sabem que os avanços dependem de questionar pressupostos e quebrar paradigmas e não simplesmente fazer alguma coisa apenas porque alguém disse para fazer. Questionar é o imperativo do inovador. Quando funcionários altamente motivados e capacitados compartilham a mesma visão, eles não precisam ser supervisionados meticulosamente."

"A única resposta que os verdadeiros líderes devem se negar a receber de seus colaboradores é o silêncio, não a divergência". (Warren Bennis)

"Obediência não. Disciplina sempre".

"Gerente de Projeto é diferente de Líder Técnico ou Analista com conhecimentos de gerenciamento. Gerente/Coordenador/Líder são coisas diferentes e que exigem competências complementares".

O texto abaixo foi retirado do site de Guilherme Chapiewski. Inicialmente eu iria colocar somente algumas partes que achei interessante, mas o texto como um todo é interessante, sendo assim, transcrevo o texto na integra, colocando em fonte vermelha algumas passagens que me chamaram mais a atenção.

O artigo original pode ser encontrado no link http://gc.blog.br/2009/12/04/2-anos-de-scrum-e-agile-na-globo-com-e-algumas-coisas-que-eu-aprendi/

As palavras que Guilherme escreve podem ser usadas em muitas situações da vida, basta substituir as palavras Scrum e Agile por qualquer outra que faça parte da sua realidade que verá como o texto se adapta perfeitamente.

Já se passaram pouco mais de 2 anos desde que começamos a trabalhar oficialmente com Scrum e Agile na Globo.com e um pouco mais de 2 anos e meio desde que a coisa toda começou de fato.

Depois de trabalhar diariamente com processos ágeis e uma porção de times diferentes na Globo.com, minha sensação é a daquele dito popular que diz que quanto mais você sabe de alguma coisa, mais você descobre que tem que aprender. De tempos em tempos surgem idéias novas excelentes e as vezes são coisas tão simples que eu me pergunto porque nunca tinha pensado nelas. Ou então algumas idéias que não deram certo no passado voltam à tona, são colocadas em prática e passam a funcionar muito bem. Sempre que eu acho que já aprendi como alguma coisa funciona alguém aparece com uma ideia melhor e me prova que eu estava errado em achar isso.

Me lembro quando perguntei lá no início para o Boris Gloger sobre o tempo que levaria para as coisas acontecerem. Na época ele falou que para uma empresa do tamanho da Globo.com certamente levaria de 2 a 4 anos para as coisas mudarem de fato. Eu achei um exagero e que ele estava louco, mas era eu que não tinha noção do tamanho da coisa toda. Ele estava certo.

Infelizmente eu não tenho uma história romântica para contar e estaria mentindo se dissesse que as coisas são maravilhosas depois que você adota Agile, Scrum ou o que quer que seja. Muito pelo contrário, os problemas começam a aparecer e tudo fica caótico. As vezes a quantidade de problemas chega a ser enlouquecedora e minha insônia aumentou consideravelmente depois disso. Mas eu não tenho nenhuma dúvida de que os processos ágeis são os que mais se adaptam às características de projetos de desenvolvimento de software, mais do que qualquer outra coisa que eu já tenha usado. Tivemos muito mais sucesso do que em qualquer outra iniciativa na história da empresa e as coisas acontecem muito mais e muito melhor do que aconteciam antes, mas mesmo assim ainda temos um caminho muito longo pela frente.

Hoje eu consigo entender com mais clareza o real sentido do empirismo que tanto se fala. Mesmo com pilhas de livros sobre desenvolvimento ágil na minha prateleira, eu olho para trás e vejo que o processo de “tentativa e erro” foi muito mais importante para o meu aprendizado do que qualquer teoria. Várias coisas escritas nos livros deram certo para alguns times e não deram para outros, e no fim das contas o que ficou foi uma mistura de todas essa experiências. Fomos fazendo as coisas, vendo o que dava certo ou errado, mudando, adaptando e seguindo em frente. Hoje não dá pra dizer que a Globo.com usa Scrum, XP, Lean ou Kanban. Você pode encontrar todos os seus sabores preferidos de Agile por aqui, às vezes misturados e até mesmo bem customizados e diferentes do tradicional.

Nesse tempo todo vivenciei muitos problemas, muitos sucessos, muitas derrotas, muitas falhas e muita mudança. Eu queria poder dizer que encontrei o Santo Graal do desenvolvimento ágil, mas dificilmente isso existe. E se existir, provavelmente o da minha empresa será diferente da sua e por ai vai. Porém, eu posso falar de algumas coisas que eu aprendi e que talvez possam ser úteis para outras pessoas e empresas:

Você sempre estará em transição.

Basicamente eu não acredito mais em transição ágil como eu já li por ai, que parece uma coisa que tem inicio, meio e fim. Hoje eu percebo que sempre se está em transição. Sempre surgirão projetos novos com características diferentes e sempre será necessário ajustar e se adaptar. Isso tudo fora que as pessoas e os times também mudam, e ai começa tudo de novo. É um trabalho que nunca acaba.

É muito fácil começar a fazer Scrum, o difícil é vencer a resistência das pessoas.

Grande parte do meu tempo nesses anos foi investido em quebrar barreiras e a resistência das pessoas. E não estou falando de diretores ou gerentes, às vezes os piores problemas estão dentro dos times. Os mais diversos tipos de problemas acontecem: tem gente que tem medo de trabalhar em par e expor suas fraquezas para os outros, tem gente insatisfeita na empresa que envenena iniciativas, enfim, acontece de tudo. É muito importante trabalhar com pessoas bem intencionadas, comprometidas e que acreditam no que estão fazendo e que acreditam que as coisas sempre podem (e devem) ser melhoradas.

As pessoas precisam estar felizes.

É importantíssimo que a empresa reconheça seus talentos, que eles ganhem o que merecem e que eles trabalhem num ambiente agradável. Ninguém trabalha direito e dá 100% do seu potencial se não estiver feliz e satisfeito com a empresa. Pessoas infelizes e insatisfeitas podem acabar com um time inteiro, por isso a empresa tem que dar o primeiro passo e dar todas as condições para que isso não aconteça e, quando acontecer, resolver o problema o mais rápido possível.

Se o foco das pessoas for em “fazer telas”, “testar” ou “escrever software”, você está perdido. O foco das pessoas deve ser o produto, e não a sua função.

Muito desenvolvedor não gosta de fazer teste exploratório “porque isso é função do cara de QA”. Muito designer não gosta de fazer CSS e HTML porque isso é coisa de “desenvolvedor de front-end”. Bullshit! Imagine se um zagueiro está com a bola na linha do gol e diz que não vai fazer o gol porque não é atacante? Não tem essa, o foco é ganhar o jogo, entregar o produto, deixar o cliente feliz, não importa fazendo o que. Com o tempo você descobre a receita do time (quantidade de pessoas de cada especialidade) para que as pessoas passem a maior parte do tempo fazendo sua especialidade, mas isso não significa que elas não devem fazer ou entender de outras coisas.

Escalar não é fácil. Aliás, se for possível, não escale nunca.

Times ágeis funcionam melhor quando são pequenos, porque o universo de pessoas é menor e a comunicação é melhor, as pessoas confiam mais no resto do time e por aí vai. Quando o número de pessoas e de times aumenta, a comunicação fica problemática e isso gera uma porção de problemas, desde coisas triviais como conflitos de merge até coisas mais complexas de resolver como falta de confiança, dificuldade em mudar de direção, dificuldade de passar a visão do produto, pessoas querendo aparecer mais do que outras e por aí vai. Faça um teste: reúna 30 amigos seus e tentem combinar um lugar para almoçar em no máximo 2 minutos. Repita o teste com 3 amigos e compare os resultados. Foi possível combinar um único lugar de forma unânime? Quanto tempo levou? Quais foram os conflitos de interesse? Qual foi o nível de barulho, stress e insatisfação das pessoas? Ter mais pessoas ajudou a fazer com que a decisão fosse mais rápida ou mais demorada? Talvez esse não seja o melhor exemplo do mundo mas vai ser bem fácil de perceber como times grandes se organizam com muito mais dificuldade.

Boas práticas de engenharia e desenvolvimento ágil como automatização, testes, refatoração, programação em par, integração contínua e TDD são fundamentais, imprescindíveis, inevitáveis, totalmente obrigatórias.

Todos os grandes saltos de qualidade e produtividade que demos na história da evolução da Globo.com foram porque essas práticas foram intensificadas e usadas com mais disciplina, e todas as vezes que elas não recebem a devida importância a velocidade diminui, a produtividade baixa e o time entrega menos (e com mais defeitos).

Um dos “problemas” com o Scrum é que ele não fala nada sobre usar essas práticas. Isso é proposital porque o intuito era que ele fosse bastante genérico e simples, mas como muitas pessoas gostam de seguir o livro cegamente sem pensar, elas acabam achando que não é necessário fazer o que não está escrito, e daí a probabilidade de fracasso é gigantesca. Você pode usar Scrum para produzir um marca-passo, por exemplo, mas você seria louco de não testá-lo exaustivamente só porque não está escrito? Você tem que fazer, porque é uma necessidade imposta pelo tipo de projeto. Com software não é muito diferente: se você não faz TDD, seu código fica pouco testável, e consequentemente você refatora menos ou tem dificuldade para fazê-lo. Consequentemente o tempo para implementar novas funcionalidades aumenta cada vez mais e como o cliente está sempre cobrando mais e mais coisas, você passa a testar menos para dar tempo de fazer mais funcionalidades. E por aí vai (para o buraco).

As regras são excelentes quando você não sabe o que está fazendo. Depois que aprender, quebre-as.

Geralmente quando as pessoas começam com Agile o que se recomenda é que você siga as regras à risca por algumas iterações até que você aprenda e que o processo esteja “no sangue”, e só depois que possíveis customizações devem ser feitas. Muita gente confunde isso com “sempre siga as regras à risca”. Por exemplo, hoje alguém me convenceu numa conversa que o Sprint Planning 2 do jeito que um determinado time estava fazendo estava bem inútil, uma grande perda de tempo. A sugestão foi fazer uma coisa mais “just-in-time”, ou seja, na hora que a história começar a ser desenvolvida. Muita gente pode falar que “ah, mas não é assim que o Scrum funciona” ou o clássico “aqui na empresa nós não fazemos desse jeito”. Se você tem um bom motivo para mudar as regras do jogo, discuta o assunto com o time e implemente as melhorias. Não existe essa coisa de “as regras do Scrum”, existem times produtivos com alta capacidade de adaptação e em constante evolução ou times que passam 50% do tempo discutindo o processo e não deixam o cliente feliz.

Trabalhar num ambiente ágil é muito muito muito mais divertido.

Acabei de passar quase 40 dias de férias e em conferências. Muita gente estaria odiando voltar para o trabalho depois disso, mas eu gostei. Quando eu cheguei hoje na empresa depois de mais de 1 mês a minha mesa já não era mais minha e eu não achava meu computador. O escritório mudou totalmente e o time que eu estava está todo misturado. Quando eu entrei na sala as pessoas estavam em pé discutindo, rabiscando no quadro e o barulho estava alto pra caramba. Depois de contar as novidades, de almoçar e de alguns updates, passei o resto da tarde programando em par numa tarefa que nem eu e nem o meu par fazíamos idéia de como resolver, mas juntos descobrimos como fazer e resolvemos o problema. Foi um dia caótico porém muito produtivo e muito divertido, como a maioria dos que eu tenho. Tudo muda muito e está em constante evolução, e cada dia é um novo desafio. Se você gosta de ficar escondido atrás da “baia” e tem dificuldades em dividir o seu teclado com um amigo, recomendo fortemente que você não use Agile.

Agile não é o Santo Graal.

Nenhum processo de desenvolvimento (ágil ou não) é perfeito. Muita gente gosta, muita gente não gosta, alguns não se adaptam, outros se motivam a cada dia com os novos desafios e é assim que as coisas funcionam. “Agile é tão perfeito” que quando as coisas dão errado é muito mais fácil culpar o seu processo e reclamar que ele não funciona. Bullshit! Como o Jeff Patton fala, as pessoas fazem isso porque o processo não vai se defender de você e porque é muito mais difícil assumir e enxergar os problemas de verdade. Uma das chaves de ser bem sucedido nesses processos é entender que eles são apenas ferramentas muito simples e que se não estão funcionando é porque você precisa encontrar e resolver algum problema da sua empresa, do seu time, das pessoas ou do que quer que seja. Não bote a culpa no processo.

As pessoas são mais importantes que o processo. Foco nas pessoas.

São elas que fazem tudo acontecer. Quanto mais agentes de mudança sua empresa puder ter, melhor. A empresa tem que reconhecer essas pessoas e motivá-las para que elas motivem ainda mais seus pares e assim por diante. É preciso dar liberdade para elas criarem, tentarem coisas novas e errarem sem medo de serem repreendidas. Faça de tudo para que todos estejam felizes e motivados. Resolva os conflitos. Coloque tudo em pratos limpos. Trate todos com respeito e como amigos. Faça as pessoas crescerem e deixe (e ajude) que elas tenham visibilidade dentro da empresa. De todas as coisas que eu vi até hoje, nada é mais eficaz do que ter as pessoas certas do seu lado.

Nada disso é definitivo e eu posso mudar de opinião a qualquer momento sobre qualquer uma dessas coisas. Aliás, hoje numa conversa aprendi que é ótimo mudar de opinião, porque significa que você aprendeu alguma coisa nova/diferente que te fez pensar de uma forma nova/diferente e, portanto, você evoluiu. Fica então a última:

Crie sua opinião, aprenda mais e mude sua opinião. Esteja em constante evolução.

Compre o livro Gestão da Qualidade.

Excelente publicação. Aborda a evolução do processo da qualidade, como inspeção, controle estatístico, garantia da qualidade, gestão estratégica da qualidade e como a qualidade é vista nos dias de hoje.

Parte dos conceitos básicos, como fundamentos da qualidade e as principais linhas de pensamento, contemplando o Prêmio Nacional da Qualidade (PNQ), as Normas ISO (certificação e sistemas integrados de gestão), a padronização e melhoria, com a Trilogia Juran, o Ciclo PDCA e o gerenciamento da melhoria.

Aborda algumas ferramentas de gerenciamento, como Brainstorm, cartas de controle, diagrama de causa e efeito, diagrama de dispersão, estratificação, fluxograma, folha de verificação, gráfico de Pareto, histograma, matriz GUT, 5W2H, dentre outras ferramentas.

Como um bom livro sobre qualidade, aborda métodos específicos de gestão, como 5S, Seis Sigma, DMAIC, desdobramento da função qualidade, benchmarking, reengenharia, análise de valor e outros métodos.

Finalizando, contempla o que é qualidade em projetos (planejamento, garantia e controle da qualidade).

Excelente livro para se ter uma noção de tudo que envolve o assunto qualidade. Ótimo ponto de partida para quem quer conhecer o assunto e ter um norte para futuros aperfeiçoamentos.

Recomendo.

Compre o livro Gestão da Qualidade.

Francis Bacon (1561-1626) é considerado o pai da filosofia moderna. Sua principal obra filosófica é o Novum Organum.

Em Novum Organum, Bacon analisou as falsas noções - denominadas por ele de ídolos - que se revelam responsáveis pelos erros cometidos pela ciência ou pelos homens que dizem fazer ciência, categorizando-as em quatro, a saber:

Ídolos do Foro: Influência do meio na maneira como interpretamos a realidade. Preconceitos de linguagem decorrentes de palavras mal definidas, significando coisas diferentes.

Ídolos do Teatro: Preconceitos dos sistemas filosóficos que abraçamos, tradições que os compõem, e passam a justificar a legitimar a exclusão de novas ideias.

Ídolos da Tribo: Preconceitos inerentes à própria natureza humana. Como saber se o que se vê não é condicionado pelo que se é, pelas percepções pessoais.

Ídolos da Caverna: Influência da história de vida de cada um impactando a interpretação da realidade. São os preconceitos da própria experiência pessoal.

Em uma negociação, seja ela de qual tipo for, é essencial identificar os ídolos presentes, a fim de controlá-los de maneira eficiente. Essa variação interpessoal da presença dos ídolos exige do negociador uma atenção draconiana.

Compre o livro Negociação e administração de conflitos.

A parte introdutória do livro apresenta os conceitos associados aos processos de negociação e de administração de conflitos, abordando os tipos, causas e formas de se intervir em conflitos, as abordagens de negociação, aspectos relacionais e substantivos, estratégias e táticas nas negociações e comportamento ético, comunicação e maximização de resultados em relacionamentos.

Os aspectos relacionais apresentam os critérios e procedimentos objetivos, descrevendo sobre as características do bom negociador, inclusive listando as principais características praticadas pelos negociadores brasileiros. A diversidade nas negociações, precauções associadas ao relacionamento e desafios relacionais no desenvolvimento do projeto também são abordados.

Já nos aspectos substantivos, é enfatizada a importância do escopo, MACNA (Melhor Alternativa em Caso de Não Acordo), a negociação de qualidade, prazo, preço e aquisição.

O livro finaliza com os aspectos práticos que favorecem as negociações e a administração de conflitos, envolvendo o planejamento e preparação, a execução e o controle das condições e avaliação.

Compre o livro Negociação e administração de conflitos.

Compre o livro Gerenciamento de aquisições em projetos

Mais um livro da série Management da FGV, trata dos assuntos relativos ao processo de contratação/aquisição em projetos.

Inicialmente o livro apresenta os conceitos e contextualiza o processo de aquisição em projetos, apresentando as três etapas (pré-contratação, contratação e pós-contratação) do gerenciamento de aquisições.

Questiona o que deve ser adquirido em projeto, se o objeto em questão deve necessariamente ser contratado ou se pode ser feito pela equipe do projeto (decisão make or buy) e quão detalhada deve ser a especificação de um objeto que irá ser contratado.

Aborda o processo de solicitação de proposta, juntamente com os documentos necessários e os critérios de avaliação de tais propostas. Em seguida trata da divulgação das propostas, obtenção e classificação das mesmas, aplicando critérios de avaliação e utilizando estratégias para eliminação de concorrentes e negociação de tais propostas.

Na área de administração de contratos, o livro aborda as políticas de administração, o processo de gerenciamento aplicado à administração, o próprio processo de administração e as melhores práticas na administração de contratos.

O livro conceitua o encerramento de contratos descrevendo também o processo de encerramento. Disserta sobre os riscos no gerenciamento de aquisições, os riscos associados aos tipos de contratos, a importância do planejamento das aquisições, informações necessárias para o planejamento das aquisições, como planejar e onde representar tal planejamento.

O livro fornece uma visão ampla do que envolve o gerenciamento de aquisição em projeto, lista os principais conceitos e mostra o caminho para quem quer se aprofundar mais no assunto.

Compre o livro Gerenciamento de aquisições em projetos

1. Profecia auto-realizável: O responsável geral pela distribuição de água no país diz na TV que vai faltar água no dia seguinte. Todos vão querer estocar água um dia antes e no outro dia VAI faltar água!
2. Não existe pessoa querendo fazer carreira dentro de um call center. Ninguém é atendente junior e sonha ser atendente pleno!
3. Não se mede benefício levando em conta barato e caro, mas sim Taxa Interna de Retorno (TIR).
4. A única variável que nos falta para gerenciar o projeto Vida é o prazo!
5. Diferenciação do século XXI: Inovação.
6. Curva do ciclo de vida do projeto, que quando integrada gera a Curva S.
7. Os EUA desaprenderam como mandar um homem para a lua. Não tem documentação sobre o que já foi feito. Vão ter que aprender tudo novamente.
8. Imperativo da qualidade: Qualidade é fundamental. Não é diferenciação, é obrigação. Ou você tem ou você não entra no jogo.
9. "Como você vai inovar se você trabalha igual uma mula?!"
10. 3M oferece 12 horas por semana para as pessoas pensarem/criar.
11. Empresa é um lugar para gerar recursos, gerar lucro e apagar incêndio, não para gerar ideias.
12. Gerente de projeto não é especialista, é generalista.
13. Gerente de projeto é antes de tudo um gerente, tem que ter características de gerente.
14. "Conheço gerente de projeto que a única relação que tem com outra pessoa é o coice!"
15. O sistema é ótimo para por a culpa, não fala, não reclama, ... A culpa é de quem fez!
16. A maioria das empresas implanta a tecnologia e só depois vai ver pra que serve. Poucas empresas sabem o que precisam.
17. Política que não preza a inovação: Quem inovar e dar errado vai ser punido. Professor comentou que era a avaliação de desempenho, feita pelo RH de uma empresa, que inibia a inovação (através da punição).
18. O erro é a principal ferramenta educativa.
19. Declaração de escopo: Escopo textual.
    WBS: Escopo gráfico.
20. Tudo o que é eletrônico um dia vai te deixar na mão.
21. "A direção não suja as mãos, terceiriza para o pessoal do RH".
22. RH é igual a TI, lidam com intangível, difícil de calcular TIR.
23. Não há nenhuma empresa que ofereça duas opções de crescimento, uma técnica e outra gerencial. Só existe crescimento gerencial, nunca técnico.
24. Petrobrás: quem não é engenheiro não sobe de cargo.
25. "Tem que dar o martelo e dizer pra que serve. Se eu der um martelo e não dizer pra que serve, qualquer coisa que aparecer vira prego".
26. "Há um movimento que prega que o PMBOK não é uma boa metodologia para gerenciar projetos de TI. Esse movimento está criando o SCRUM, Agile, ..."
27. Workflow é a representação gráfica de um processo.
28. Processo é horizontal, se preocupa mais com a função do que com o cargo. Não se preocupa com a hierarquia.
29. Paradoxo de Solow: Vejo computadores em todos os lados, só não vejo os indicadores de produtividade.
30. Não adianta alocar TI em cima de um processo idiota. O que você vai conseguir é um processo digitalmente idiota!
31. O processo de despacho de mala em um aeroporto é um ato de fé, não tem controle nenhum. O processo de controle de mala é falho, não adianta automatizar (TI) esse processo.
32. KPI: Key Performance Indicator.
33. SWOT
    Forças e Fraquezas (Empresa)
    Oportunidades e Ameaças (Mercado)
34. Descobre-se que celular gera radiação maléfica (ameaça para o mercado). Nokia descobre como neutralizar o efeito da radiação (força da empresa).
35. Gestão Estratégica da Informação é uma abordagem gerencial que prega o questionamento e inovação de processos produtivos, usando a tecnologia da informação como meio e se apoiando fortemente no gerenciamento de mudanças, para melhoria substancial de performance da empresa, buscando alcançar vantagem competitiva sustentável.
36. Processos: Conjunto de tarefas interligadas entre si, dependentes do tempo, espaço e pessoas, que recebendo inputs, geram outcomes de valor agregado, seja para o cliente interno ou externo.
37. Processo é a movimentação de documentos. O que anda em um processo é o documento.
38. Em qualquer curso de TI o ator principal tem que ser processo e não TI.
39. VRIO: Valioso, Raro, Ilimitável/Insubstituível, Organizável.
40. VCS: Vantagem Competitiva Sustentável.
    VCT: Vantagem Competitiva Temporária.
    PC: Paridade Competitiva.
    DC: Desvantagem Competitiva.
41. TI não é estratégia. Estratégia são os processos e as pessoas que você contrata.
42. "TI puro sangue": a pessoa de TI que só vê TI na sua frente, não tem conhecimento sobre pessoas ou estratégias.
43. Quando se trabalha para uma empresa tem que vestir a camisa, mas nunca pode se esquecer de ter uma camiseta por baixo, porque a empresa pode tirar tua camisa, e se não tiver uma por baixo, você vai pegar uma pneumonia!
44. Output de um Planejamento Estratégico: Projetos. Não se pode fazer todos os projetos ($), ai que entra o gerenciamento de portfólio.
45. Cada processo tem uma forma específica para ser medido. Call center, por exemplo, usa TMA (Tempo Médio de Atendimento).
46. Projeto
    1º: Concepção
    2º: Gerenciamento
47. Não cabe ao gerenciamento de projeto uma concepção do projeto.
48. Gerente de projeto gerencia, e não necessariamente concebe o projeto.
49. Nós (MBA) estamos sendo preparados para gerenciar e não obrigatoriamente conceber.
50. Termo de Abertura: Um leigo tem que ler e entender o que se quer.
51. Estádio João Havelange: Faltando um mês para a entrega do projeto, descobriu-se que só tinham 4 banheiros. O estádio era para 45 mil pessoas. Resultado, faltando uma semana a marreta estava comento solta para fazer mais banheiros.
52. Principais doenças/patologias de um processo:
    
    • Fragmentação ("deixa que eu deixo"). O documento do projeto simplesmente para porque ninguém faz nada.
    • Redundância ("vão duas pessoas chutar a bola"). Mais de uma pessoa fazendo a mesma coisa.
    • Gargalo. Joga uma série de atividades em cima de uma pessoa que não consegue dar vazão a tudo.
53. "Definição de casal feliz hoje em dia: vão juntos ao shopping e voltam sem ter brigado!"
54. Ações: se você entrar em um taxi e o motorista começar a conversar sobre ações, ordinária, preferencial, ... corre vender tudo o que você tem, porque se até um motorista sabe, tem muita gente sabendo (bolsa em alta, muita notícia sendo divulgada).
55. Projetos por engenharia simultânea tendem a terminar antes e serem mais baratos que engenharia serial.
56. Se eu como duas bananas e você não come nenhuma, em média nós comemos uma banana. O fato de você estar com fome é explicado pelo desvio padrão.
57. QSMS: Qualidade, Segurança, Meio Ambiente e Segurança Ocupacional.
58. MBA é um curso informativo, o importante é a resposta
59. Mestrado, o importante é a pergunta.
60. Quem tem SWOT é a empresa e não o projeto.
61. "A empresa está tão preocupada em pensar no futuro que não dá tempo de controlar o passado (processos já criados)".
62. "O diabo mora nos detalhes".
63. "Quando você faz um mestrado/MBA você tem uma dificuldade tremenda em voltar a trabalhar na sua empresa devido a imbecilidade que tem lá dentro!"

Um funcionário novo na sala de correspondência da empresa, observou um homem mais velho sentado num canto, classificando correspondências, pesando pacotes, colocando selos e fazendo outros trabalhos simples, e perguntou a seu supervisor quem era aquele homem.

"Aquele é José." disse o supervisor. "Ele trabalha para a empresa há 35 anos e está próximo da aposentadoria."

"Verdade?" respondeu o funcionário. "Ele sempre esteve na sala de correspondência?"

"Não, disse o supervisor, ele saiu há muitos anos atrás, e após ter trabalhado durante vários anos como gerente de projetos - pediu transferência para aqui novamente."

Superficialmente, a função de um gerente de projetos deveria ser fácil de descrever. Na verdade, sob a perspectiva de um livro texto, provavelmente é. Mas, o desafio de entender as funções e as responsabilidades do gerenciamento de projetos é diferente de empresa para empresa.

Fonte: Função de um gerente de projetos (TenStep)

João e Maria, irmãos, encontram-se na cozinha de casa discutindo sobre a posse de uma laranja. O pai chega em casa, observa a discussão e resolve mediar a situação. Se ele tiver passado por um dia difícil chegando estressado do trabalho, muito provavelmente ficará aborrecido com uma briga aparentemente inútil e pode tomar uma decisão precipitada chegando até os dois, que não conseguem entrar num acordo, dizendo:
– Vocês têm cinco minutos para resolverem quem vai ficar com a laranja porque do contrário eu vou usá-la para mim!

João e Maria olham entre si e notam que se não entrarem em acordo, será gerada uma situação em que nada levarão para si. Raciocinam que devem dividir a laranja pois, tal divisão poderá proporcionar, pelo menos alguma satisfação. Um novo problema surge: quem vai dividir a laranja? Nova confusão!

João e Maria são irmãos, jovens, ainda conviverão por muito tempo. Inicialmente tendem a discordar quanto à divisão. Quatro minutos se passam e nenhuma solução é encontrada. Encontram-se pressionados pelo tempo. João, furioso, sobe na mesa para amedrontar Maria e conseguir, por pressão psicológica ser o agente da partilha. Neste momento, vendo o mundo por outro ângulo, uma idéia vem à sua mente: Por que não pedir a um terceiro que faça a partilha? Maria concorda. Pedem ao pai que divida a laranja.

O pai, agora mais calmo, pois teve o mérito de neutralizar uma discussão em família, adota a posição de um mediador Salomônico e ele diz para os filhos: – Ok, os dois querem a laranja, está ótimo, façamos uma divisão com equidade: João você divide a laranja; Maria, você pega o primeiro pedaço.

Essa é uma belíssima decisão porque João vai partir a laranja o mais próximo da metade possível se ele quer satisfazer o máximo do seu interesse, porque sabe que Maria terá a oportunidade de pegar o primeiro pedaço. Se partir pedaços diferentes Maria provavelmente tomará para si o maior porque Maria também quer maximizar o seu prazer. Essa é uma solução elegante. João corta a laranja, Maria pega o primeiro pedaço, João o segundo, cada um vai para o seu lado feliz e satisfeito. O pai feliz e satisfeito porque conseguiu fazer uma partilha igualitária e resolver um conflito entre seus filhos. A família fica feliz e os três saem satisfeitos!

Entretanto, curioso, o pai segue João e observa que ele toma sua metade da laranja, espreme, e obtém para si o suco. João adora suco de laranja!

Seguindo Maria observa que ela toma sua metade da laranja, vai para a cozinha, tira o miolo e joga fora, e pega a casca da laranja coloca numa panela para fazer um doce para sua avó. Maria está feliz da vida porque, pelo menos, conseguiu metade da laranja para fazer um doce. João está feliz da vida porque, pelo menos, conseguiu metade da laranja para fazer seu suco. Aquela posição de cada um querer a laranja inteira para si, escondia interesses complementares, perfeitamente conciliáveis. Maria tinha interesse na casca da laranja e João tinha interesse no miolo da laranja para fazer suco de laranja. Se o pai no momento da decisão salomônica tivesse investigado um pouco mais a situação para tentar entender quais seriam os interesses de cada um, poderia conciliar os interesses, maximizando o prazer de cada um propondo uma solução mais elegante, mais perfeita, que seria tirar a casca da laranja e dar para a Maria entregando o miolo para João. Geraria, assim, uma proposta irrecusável abrindo a laranja e conciliando os interesses dos atores da negociação.

1. Quer negociar bem? Aprenda a olhar o assunto com os olhos da outra pessoa.
2. Todos são ignorantes. Eu sou ignorante. Isso me deixa menos preconceituoso e mais predisposto a entender as coisas com os olhos das outras pessoas.
3. ZOPA (Zona de Possível Acordo). Qualquer acordo dentro desta zona melhora o estado de satisfação da pessoa. Fora disto, piora o estado de satisfação.
4. Sempre que surgir uma oportunidade de negócio, o negociador deve primeiro se preparar (pedir um tempo) e depois continuar a negociação.
5. MACNA (Melhor Alternativa em Caso de Não Acordo).
   
   • Não deve ser dita para a outra parte da negociação.
   • É o que melhor pode ser feito caso a negociação principal não dê certo.
   • Vale tanto para vendedor quanto comprador.
   • É a primeira pergunta que o negociador deve fazer antes de iniciar a negociação.
6. Quando um vendedor se mostrar irredutível em uma negociação, dizer a ele que eu (comprador) tenho alternativas melhores (MACNA).
7. Negociador que oferta por R$ 13.000 e pula para R$ 7.000 é uma "lebre", pula muito o valor!
8. Deve-se oferecer para o comprador uma legitimidade (esse carro na tabela vale X, mas o meu carro vale mais, pois não tem risco, a quilometragem está baixa, etc.).
9. Opções: o que eu disponho, as propostas que eu tenho.
   Alternativas: O que me resta caso nenhuma opção seja atingida.