Os testes não iniciam apenas após o desenvolvimento, deve-se começar a estruturar os testes logo no início do projeto no  levantamento de requisitos. Neste momento o planejamento e definição apropriada do que será testado e como será testado é fundamental para o sucesso do projeto e os seguintes tipos de testes podem lhe ajudar:

Teste unitário

Também conhecido como “teste do programador”, é o tipo de testes mais comum. Deve-se testar a menor unidade do software desenvolvida como uma  funcionalidade, pedaço de código ou componente. Pode ser feita de forma manual ou com a ajuda de uma ferramenta como por exemplo o JUnit ou NUnit.

Teste integrado

Neste tipo de testes testa-se a integração entre os diversos produtos e componentes desenvolvidos. Deve-se verificar se os componentes funcionam perfeitamente quando integrados, com componentes externos, com bases de dados, com serviços e outros. Este tipo de testes é executado normalmente pela equipe de desenvolvimento.

Teste de aceitação

Este é o tipo de testes realizado pelo usuário para atestar que o sistema atende aos requisitos definidos (e contratados). É executado normalmente pelo usuário com apoio do analista ou arquiteto do projeto.

Teste de interface

Deve-se verificar se a navegação no sistema está de acordo com o previsto. Se os botões acionam as funções esperadas e a usabilidade atende às necessidades do usuário.

Teste de performance

Neste tipo de teste, verifica-se se o tempo de resposta da aplicação está condizente com o planejado, se o sistema suporta um determinado número de conexões ao mesmo tempo e se determinadas situações de alta carga não “travam” o sistema.

Teste de segurança

Deve-se verificar se o sistema está preparado para as principais vulnerabilidades de segurança. Uma boa dica é seguir as recomendações do OWASP que discute as principais vulnerabilidades e apresenta meios para proteger os sistemas contra as mesmas.

Teste de regressão

Estes é um dos tipos mais complexos de se fazer manualmente pois implica em testar toda aplicação sempre que algo for mudado. Com este procedimento pode-se garantir que as mudanças não trarão impacto ao restante do sistema. Há diversas ferramentas que executam scripts para testes de regressão tornando esta atividade bem mais fácil.

Teste de caixa branca

Testa-se o código propriamente dito, seu comportamento e se há partes do mesmo que não são acessadas.

Teste de configuração

É o tipo de testes onde se verifica se a aplicação funciona em diferentes tipos de ambientes, hardware e software. No desenvolvimento web utiliza-se muito para verificar o comportamento em diferentes navegadores ou ambientes servidores.

Teste de caixa preta

Neste momento verifica-se se o comportamento das entradas e saídas está de acordo com o esperado. Os casos de saídas com resultados inesperados é classificado como erro. Não se verifica o código dos componentes.

Teste funcional

Deve-se testar todas as funcionalidades para verificar se as mesmas atendem aos requisitos e regras de negócio definidos no levantamento de dados ou especificação funcional. Uma boa prática é realizar esta validação contra a documentação e se houver alguma divergência, está deve ser tratada.

Teste de volume

O objetivo deste teste é verificar como o sistema se comporta com grandes volumes de dados .

Teste de instalação

Este tipo de testes é bem pragmático. Verifica-se se a instalação ocorreu conforme previsto.

Teste de Sistema

Verifica a boa execução dos componentes do aplicativo inteiro, incluindo as interfaces com outras aplicações.

Deve-se buscar o melhor índice de estabilidade e confiabilidade possível, todavia a partir de um determinado ponto como 97% por exemplo, o custo começa a aumentar exponencialmente.

2. Estude. Lembre-se que o século XXI é o século do conhecimento e da Inteligência. Vencerão somente os melhores;

3. Procure ouvir a experiência dos mais velhos. Às vezes pode ser chato, mas antes de descartar bons conselhos, pense neles;

4. Cuide de sua saúde. Pratique esportes. Não fume;

5. Encha o seu tempo. Não fique desocupado. Faça alguma coisa boa – cursos rápidos além da escola são uma boa opção;

6. Aprenda inglês e espanhol. Lembre-se que inglês será o idioma universal. Mais da metade da população mundial estará falando inglês nos próximos anos. Espanhol é importante porque será a segunda língua mundial;

7. Aprenda computação. Seja amigável com um computador. O mundo será a cada dia mais digital. Navegue na Internet buscando informações úteis para o seu futuro;

8. Divirta-se. Seja uma pessoa alegre. Sorria!

9. Seja polido e educado. Saiba dizer “com licença”, “por favor”, “obrigado”, “desculpe”. Pessoas educadas têm mais sucesso na vida e no trabalho;

10. Resista a tentação às drogas e maneiras fáceis (e falsas) de ser feliz. Lembre-se que a felicidade e o sucesso são construídos no dia-a-dia por nossas atitudes e comportamentos. Acredite em você! Você merece ser feliz! Cuide-se! E não se esqueça de sua espiritualidade. Professe uma religião para sempre se lembrar das coisas permanentes e não só das coisas transitórias da vida.

Só assim você será realmente feliz!

Pense nisso. Sucesso!

[Professor Luiz Almeida Martins Filho]

Este gráfico pode mostrar a taxa com que a equipe completa os requisitos ao longo do tempo e se esta taxa está de de acordo com o planejado. Este tipo de gráfico é bem similar ao EVM – Earned Value Management.

Podemos utilizar gráficos de Burn-up para compreender coisas como:

• Qual a produtividade da equipe
• Qual a tendência de desempenho do projeto
• Quando uma release será entregue
• Qual a conclusão contra o planejamento

Com elementos assim fica mais fácil comunicar os stakeholders.

O vídeo abaixo demonstra de uma forma muito fácil o que são gráficos de burn-up e como podemos utilizá-los.

1. Relacionamento entre gerenciamento de projetos, gerenciamento das operações e estratégia operacional: A descrição da relação entre estes componentes foi expandida;

2. Valor do negócio: Este conceito foi incluído na nova versão e descreve o papel do gerenciamento de portfólio, programa e projeto na obtenção de maior valor do negócio através dos investimentos em projetos;

3. Habilidades do gerente de projetos: A nova versão destaca a importância do equilíbrio entre habilidades conceituais, éticas e interpessoais para um efetivo gerente de projetos. Além disto, volta a destacar em seu primeiro capítulo algumas das habilidades interpessoais consideradas importantes para um gerente de projetos (liderança, trabalho em equipe, motivação, comunicação, influência, tomada de decisão, consciência política e cultural, e negociação), sendo que estas habilidades são apresentadas em detalhes em um dos apêndices da 5ª Edição;

4. Influências organizacionais no gerenciamento dos projetos: Este tema foi expandido, incluindo a discussão sobre a grande influência do estilo de comunicação da organização no sucesso do gerenciamento dos projetos;

5. Governança do projeto: O capítulo 2 agora inclui uma descrição da definição, composição e aplicação de uma estrutura de governança para os projetos;

6. Equipe do projeto: Foi incluída uma seção que trata das características e estrutura de uma equipe de projeto;

7. Ciclos de vida e relacionamento entre fases nos ciclos de vida dos projetos: Neste aspecto reside, na minha opinião, uma das importantes melhorias na nova versão do Guia PMBOK, que expande e esclarece as diferentes possibilidades de ciclo de vida e relacionamento entre as fases de um projeto. Assim como na 4ª Edição, a nova versão documenta dois relacionamentos básicos entre fases: sequencial e sobreposto. Já no que tange a possíveis ciclos de vida, documenta: ciclo de vida preditivo, ciclo de vida incremental e iterativo e, por fim, ciclo de vida adaptativo (também conhecido como método ágil ou orientado a mudança). Esta explicitação de diferentes ciclos de vida que podem ser utilizados nos projetos ajuda a desmistificar o conceito incorreto de que o Guia PMBOK orientaria a condução dos projetos através de fases sequenciais ou em cascata (waterfall);

8. Processos de gerenciamento de projetos para um projeto: O capítulo 3, que trata deste tema, foi totalmente reformulado. O antigo conteúdo do capítulo 3 passa a ser um anexo, que serve como um padrão para o gerenciamento de projetos de um projeto (padrão ANSI). O novo conteúdo do capítulo 3 serve como uma ligação entre as duas primeiras seções do Guia PMBOK e as seções seguintes que tratam das áreas de conhecimento do gerenciamento de projetos, descrevendo os grupos de processos, sem, no entanto, detalhar cada um dos processos contidos nestes grupos;

9. Áreas de conhecimento: A 5ª Edição do Guia PMBOK ganhou uma nova e importante área de conhecimento – Gerenciamento das Partes Interessadas do Projeto. Na 4ª Edição o gerenciamento das partes interessadas estava considerado em 2 processos da área de conhecimento de gerenciamento das comunicações (Identificar as Partes Interessadas e Gerenciar a Expectativa das Partes Interessadas). Com esta nova área de conhecimento, há uma demonstração inequívoca da importância do engajamento das partes interessadas nas principais decisões e nas atividades associadas com o projeto. Agora são documentados 4 processos para o gerenciamento das partes interessadas: Identificar as Partes Interessadas, Planejar o Gerenciamento das Partes Interessadas, Gerenciar o Engajamento das Partes Interessadas e Controlar o Engajamento das Partes Interessadas;

10. Gerenciamento das Comunicações: Com a saída dos processos relacionados ao gerenciamento das partes interessadas, esta seção do Guia PMBOK foi reformulada e o foco está mais no processo de comunicação do que no resultado desejado da mensagem. Esta seção conta agora com os seguintes processos: Planejar o Gerenciamento das Comunicações, Gerenciar as Comunicações e, por fim, Controlar as Comunicações;

11. Planejamento do Gerenciamento de Escopo, Tempo e Custos do Projeto: Foram criados processos que explicitam a necessidade e importância do desenvolvimento destes planos de gerenciamento. Os novos processos são: Planejar o Gerenciamento do Escopo, Planejar o Gerenciamento do Tempo e Planejar o Gerenciamento dos Custos;

12. Processos descritos no Guia PMBOK: Com as alterações realizadas em sua estrutura, o guia passa a documentar 47 processos aplicados ao gerenciamento dos projetos. Na versão atual, são documentados 42 processos.

Baguete

2. Nunca faça algo que você não possa assumir perante sua equipe, seus superiores, seus subordinados ou o público

3. Seja humilde, tolerante, flexível e disposto a ouvir críticas e sugestões.

4. Críticas e repreensões devem ser feitos primeiro à pessoa a quem se referem, cara a cara. Se houver o dever de levá-los a mais alguém, que não seja pelas costas.

5. A privacidade do colega, do cliente e de todos os demais é inviolável. Independentemente de questões de propriedade corporativa, mexer na mesa, gaveta, informações ou documentos alheios exige autorização (de norma ou da pessoa envolvida) em qualquer circunstância.

6. Em ações e discussões internas, assuma sempre seus valores e princípios e as consequências dos atos a que eles conduzirem, mesmo que isso signifique ficar contra a maioria – mas jamais procure obstruir o direito de expressão e voto no posicionamento alheio.

7. Fique longe de fofocas e comentários maldosos, mesmo que pareçam fazer parte da cultura do grupo. Muitas vezes, o simples fato de dar ouvido a elas pode ser suficiente para identificá-lo com o rótulo de fofoqueiro.

8. A relação hierárquica e de equipe não deve considerar amizades nem antipatias. O subordinado amigo deve ao seu chefe o mesmo tratamento que os demais, e o chefe amigo precisa cuidar para jamais privilegiar o subordinado que lhe é próximo. Da mesma forma, antipatias pessoais não têm espaço no ambiente profissional. Reserve-as para seu íntimo e procure oportunidades para superá-la. No trabalho, trate o colega com o respeito comum, mantenha distância se possível, e não comente com outros a antipatia que sente.

9. Sempre dê crédito a quem merece, sem jamais aceitar elogios ou recompensas pelo mérito alheio

10. Ao errar, reconheça, sem exageros. A atitude esperada é “não foi um erro intencional, vou providenciar para que não ocorra de novo e vou remediar o acontecido”.

Efetividade.net

Veja como os EUA vêem o Brasil.

Apple

AZB Centre

Comvert

Corus Quay

Disqus

Dream Host

Ebay

Facebook

Google

HBO

Horizon Media

Living Social

Mercado Libre

Microsoft

MSN

Norton

Pallota Teamworks

Pouns Houts

Rabobank

Red Bull

Rovio

Samsung

Selgas Cano

Square

Twitter

Valve

Zynga

O checklist abaixo visa ajudar as pessoas à encontrar oportunidades de melhoria na gestão de seu tempo.

1. Dentro das atividades que você deve fazer há uma classificação de prioridade?

2. Você normalmente termina suas tarefas no último minuto?

3. Você dedica um tempo para planejar o que deve fazer tanto na visa profissional quanto na pessoal?

4. Você define antecipadamente um determinado tempo para cada tarefa?

5. Com que frequência seu trabalho é interrompido? O que você faz para compensar as interrupções?

6. As tarefas ou trabalhos que você executa estão alinhados com seus objetivos e metas?

7. Você planeja seu dia contemplando às 8h ou dedica tempo para imprevistos?

8. Em sua organização de prioridades há a diferença entre o importante e o urgente?

9. Quando de um novo trabalho, você analisa sua importância e prioridade antes de começá-la?

10. Conversas, e-mail ou internet conseguem afetar o cumprimento de suas metas?

11. Você leva trabalho pra casa?

12. Quando algo “da” errado você busca compensar na mesma semana ou em um curto espaço de tempo?

13. Você define planos de ação para questões críticas?

14. Seu superior concorda com a prioridade que você definiu para seus trabalhos?

15. Após o término de uma tarefa ou trabalho, você avalia seu resultado e seu desempenho?

Enfim… Este checklist lhe ajudará a refletir sobre o tema e quem sabe melhorar a gestão do seu tempo.

É um muito comum ver algumas pessoas questionando a eficácia dos frameworks e métodos ágeis, por não cobrirem a totalidade de áreas e aspectos de um projeto. Assim acontece com os custos.

E fica a dúvida: os métodos ágeis fazem a gestão de custos? A resposta é NÃO.

Por estes e outros motivos, já adiantando a conclusão deste post, é que eu afirmo com propriedade que a mescla de abordagens é o melhor caminho a ser seguido.

Mas vamos aos fatos: não temos como fugir muito do Scrum já que é sem dúvida o framework mais difundido (e talvez mais completo) da agilidade, então vamos utilizá-lo como exemplo.

Para começar, a última versão do Scrum Guide de julho de 2011, não cita nenhuma vez a palavra “custo”. Ou seja, não só inexistem ferramentas e técnicas de gestão de custos, mas o aspecto não é nem considerado como parte integrante do cenário.

Já ouvi alguns argumentos (que até tem alguma coerência) dizendo que o Scrum tem sim gestão de custos, já que propicia a gestão descentralizada, e o próprio time toma decisões referentes aos custos do projeto e etc.

Ok, legal, mas quem de fato sabe se o projeto está dentro do custo esperado ou não? E se sabe, baseado em que? Como o planejamento é realizado? Existe uma técnica de estimativa? Utiliza-se de alguma estrutura para gestão de contas de controle? Fluxo de caixa? Não, não! Não tem nada disso!

Se alguém faz gestão de custos em uma organização 100% Scrum (e nada mais), não é o Scrum Master, nem o Product Owner, muito menos o time. Então, quem é? Alguém fora das fronteiras do projeto, talvez o departamento financeiro com base nas receitas e despesas do centro de custo de um projeto.

Mas é claro, o framework em sí não possui gestão de custos, em nenhum momento.
Passando por outros métodos e frameworks, como Kanban, XP, TDD, o caso é o mesmo: nem cheiro de custos.

De qualquer forma, o fato é que os frameworks ágeis são muito incompletos neste sentido, e provavelmente nem tem a intenção de mudar.

Por outro lado se atrelarmos ferramentas de planejamento e gestão de custos eficazes à filosofia da agilidade, criamos um ecossistema onde todos os envolvidos tem consciência de todos os aspectos do projeto (incluindo custos), se preocupam com ele, e naturalmente tomam decisões considerando estes fatores. Com números reais e confiáveis na mão, é possível por exemplo envolver o time durante uma reunião de planejamento de uma sprint quanto à decisão de incrementar recursos no projeto ou não.

Também funcionam bem algumas adaptações de algumas ferramentas já conhecidas pelos agilistas. Já ví casos práticos onde cada cartão em um Kanban Board possuía o valor do item de trabalho referente, e um burndown chart foi adaptado gerando uma espécie de Curva S de custos. Eram todos os benefícios do Kanban atrelados à uma gestão de valor agregado! Não é demais? Sim, é disso que estou falando.

Digo e repito, sempre: utilize o que cada abordagem tem de melhor.

Podemos ver que mesmo com a crise mundial, as empresas de TI continuaram investindo em melhoria de processos e o número de avaliações CMMI por ano se estabilizou na faixa de 1350 avaliações.

Deste número temos a seguinte distribuição que mostra uma nítida mudança no quadro onde há mais empresas indo para o CMMI nível 3 do que o CMMI nível 2, com isso podemos ver que o nível de maturidade no desenvolvimento de software no mundo esta melhorando. Outro ponto interessante é que nos últimos 3 anos houveram quase 100 empresas avaliadas no CMMI-SVC (CMMI para Serviços).

Destas avaliações, mais de 80% foram realizadas por empresas privadas.

Em relação à quantidade de pessoas da organização, é interessante notar que quase metade das organizações tem até 50 pessoas. O número de empresas com mais de 200 pessoas também aumento, estando agora em mais de 18%.

O investimento em melhoria de processos está de vento em popa na Ásia, chegando ao número de 3.130 avaliações nos últimos três anos, ou seja, práticamente metade das avaliações CMMI do mundo estão na Ásia. Na América do Sul houveram apenas 326 avaliações onde quase metade foram com empresas brasileiras.

Os países que mais reportaram avaliações SCAMPI estão mostrados abaixo. Um ponto de atenção é que a China passou os Estados Unidos. Segundo o SEI os países com maior crescimento em avaliações são: China, Espanha, Korea, Índia e Japão.

Em relação ao CMMI para Serviços podemos dizer que o cenário é simular nas empresas até 50 pessoas (que totaliza 50%) e bem diferente nas empresas com mais de 200 pessoas que chega à 29%.

Ainda existem poucas empresas aderentes ao CMMI para serviços e metade delas está na América do Norte.

Em relação ao tempo para implementação do CMMI as mudanças foram mínimas:

• CMMI 2: 3 à 20 meses
• CMMI 3: 4 à 25 meses
• CMMI 5: 5 à 26 meses

Em resumo, a maturidade em desenvolvimento de software no mundo está evoluindo muito bem.

Mas… vamos à lista:

Top 10 riscos de segurança em aplicativos Web

1. Injection
Injection flaw como SQL, ocorrem quando os dados não seguros são enviados a um intérprete como parte do comando ou consulta. Tenta-se enganar o interpretador que executará comandos suspeitos com o objetivo de burlar a segurança e coletar dados.

2. Cross-Site Scripting (XSS)
Está vulnerabilidade ocorre sempre que um aplicativo obtém dados não seguros e envia ao navegador web sem validação. A falha XSS permite executar scripts no navegador da vítima e pode-se roubar sessões do usuário ou redirecionar à sites fake ou mal intencionados.

3. Broken Authentication and Session Management (Quebra de Autenticação e Gerenciamento de Sessão)
Busca-se quebrar os mecanismos de autenticação e gerenciamento de sessão que por muitas vezes são implementadas de modo falho, permitindo assim o roubo de senhas, chaves, tokens de sessão ou falhas de execução que permitam assumir a identidade de outros usuários.

4. Insecure Direct Object References
Acontece quando o programador expõe uma referência a um objeto de implementação interna como um arquivo, diretório ou chave de banco de dados. Sem um mecanismo de segurança os invasores podem manipular estas referências para acessar dados não autorizados.

5. Cross-Site Request Forgery (CSRF)
Neste tipo de ataque o navegador da vítima envia uma requisição à uma aplicação web vulnerável como se fosse a vítima executando tal ação.

6. Security Misconfiguration
Toda aplicação deve ter seu ambiente muito bem configurado e seguro. Deve-se ter cuidado com o framework, servidor de aplicação, servidor de serviços, servidor de dados, de componentes e outros. Todos estes devem ser configurados seguindo as boas práticas de segurança. Não se pode esquecer de manter os servidores atualizados com as últimas versões recomendadas pelo fabricante.

7. Insecure Cryptographic Storage
Diversas aplicações web não protegem ou criptografam dados sensíveis tais como cartão de crédito, conta bancária, CPF, CNPJ e outros. Os atacantes buscam roubar estes dados ou manipula-los de acordo com suas ações mal intencionadas.

8. Failure to Restrict URL Access (Falha de Restrição de Acesso à URL)
Ocorre quando se pode acessar uma página apenas pelo seu endereço sem o devido controle de acesso. Um usuário autenticado pode acessar a página de administração de usuários se apenas conhecer seu endereço (e o sistema não controlar isto).

9. Insufficient Transport Layer Protection
Ocorrem quando as aplicações falham em proteger os dados trefedados na rede. Muito disto ocorre por algorítimos fracos, certificados inválidos, certificados expirados ou até mesmo o uso incorreto das normas de segurança.

10. Unvalidated Redirects and Forwards (Invalidar Redirecionamentos e Encaminhamentos)
O constante redirecionamento para outras páginas ou sites sem a devida validação pode facilitar a entrada de pessoas mal intencionadas à redirecionar as vítimas à sites de phishing, malware, ou acessar páginas não autorizadas.

Para “ganhar tempo” não se faz um levantamento detalhado, não se documenta os requisitos, não se obtém aprovações e os testes são mal feitos entre diversas outras “más práticas”. O mesmo acontece quando o objetivo é a redução de custos onde profissionais com pouco preparo recebem tarefas que vão além da sua capacidade.

Há um equilíbrio entre qualidade, custo e prazo e quando isto não é respeitado, um destes elementos é sacrificado.

Quando da implementação de uma nova funcionalidade em um sistema pensamos em duas formas de atender: A primeira é mais rápida, você desenvolve apenas o código e pronto, já atendeu seu cliente. O problema é que as coisas saem meio bagunçadas, sem planejamento e sem pensamento no futuro além da quantidade de “cheio de gambiarras”. O débito técnico será pago no futuro.

A outra é mais elegante e organizada pois planeja-se o que será feito, documenta-se o que será feito e os códigos são gerados e testados de acordo com cenários pré-definidos para atender o negócio. Nestes casos o débito técnico é mínimo.

Ambos os cenários acontecem o tempo todo no desenvolvimento de software e quando seguimos a linha das gambiarras, estamos jogando fora todo o conhecimento em engenharia de software, recomendações, boas práticas e principalmente as lições que a comunidade de engenharia de software aprendeu nos últimos 30 anos. Um programador pode se vangloriar de ter entregue um sistema em metade do tempo e cinco dias depois se decepcionar ao perceber que uma tela demora 5 minutos para ser mostrada em decorrência da falta de estruturação, arquitetura, planejamento e principalmente testes. Alguém vai ter que corrigir isto e haverá um custo ou também podemos chamar de “débito técnico”. Quem vai pagar isso?

Um bom sinal de débito técnico é quando ouvimos aquela frase “estava tão ruim que tive que refazer”.

Com o tempo o volume de débitos técnicos em um sistema vão inviabilizando a implementação de novas melhorias devido ao volume de trabalho adicional necessário, nestes casos os juros é ainda maior pois pode ser necessário reconstruir todo o sistema para atender à uma nova necessidade.

Então… quer dizer que não há como fazer um projeto em pouco tempo com qualidade?

A resposta é: claro que é possível, só que não há mágica nem bala de prata, para isso é preciso investimento em processos, padrões e gestão. A palavra chave para conseguir baixo custo, qualidade e agilidade no atendimento ao prazo é basicamente maturidade.

Apenas para exemplificar que é possível ter qualidade, baixo custo e agilidade, vejam um exemplo claro disto aqui.

1. Demonstre interesse: O corpo fala. Assim, é importante demonstrar ao interlocutor que está envolvido na questão, inclusive com a postura corporal e respostas que denotem preocupação e empenho. Frases curtas, tais como “sim”, “ok” ou “entendo” são sinais claros de que o ouvinte não está prestando atenção no que é dito.

2. Parafraseie. Em outras palavras, dê a entender que está acompanhando a mensagem com breves confirmações e até repetições do que foi dito.

3. Defina as emoções do outro: Ou seja, tente atribuir ao que é dito certa emoção. Além de, novamente, demonstrar que está prestando atenção de corpo e alma, atitudes assim mostram que há empatia por sua parte e ajudam a definir quais as motivações que embasam atitudes e ações.

4. Reflita sobre o que é dito: Repetir as últimas palavras é um indicativo de interesse na questão. Alguém diz, por exemplo, “estou cansado de ser pressionado o tempo todo”, ao que você responde: “a pressão está grande, é? Sei.” Essa resposta é especialmente eficaz em estágios iniciais de negociação, quando o negociador procura estabelecer uma presença livre de confronto, coletar informações, e precisa ter uma perspectiva da situação.

5. Incentive o outro a falar: Como? Com perguntas que não sejam do tipo “por quê”. Usar questões desse tipo confere à negociação um ar de interrogatório. Se você falar mais que o outro, diminui a oportunidade de conhecer seu oponente. Use recursos como “fale-me mais sobre isso” ou “não compreendo, você poderia ser mais específico?” e “Pode me contar mais sobre o que aconteceu com você hoje?”

6. Seja “Você”. Negociadores devem evitar a todo custo parecer provocativos ao expressar como se sentem a respeito do que é dito. A dica é a de usar a palavrinha “eu” nas frases e respostas, deixando de lado a imagem institucional que paira sobre sua cabeça e atribuir um tom pessoal à conversa.

7. Silêncio ajuda: Qualquer bom entrevistador sabe do poder que uma boa e duradoura pausa tem em uma situação de negociação. As pessoas têm tendência a preencher os espaços, e, para tal, falam. Fique atento a isso e crie situações propositalmente, em que o outro é tentado a falar e acaba por fornecer informações valiosas.

[Cio.com]

Em um projeto, todos, incluindo o usuário tem responsabilidades e o não cumprimento de suas responsabilidades traz impacto ao projeto. As empresas tem sido complacente com as falhas nas responsabilidades dos usuários, mas isto com certeza tem afetado o desempenho de seus projetos.

Quando falamos de usuário podemos dizer área usuária ou até mesmo cliente e suas falhas mais comuns nos projetos são:

Definir pessoas que não conhecem o negócio ou os objetivos do sistema
Há vários casos onde a empresa define uma pessoa que pouco conhece do negócio ou “está aprendendo”, nestes casos pela falta de conhecimento no negócio, constantemente procuram-se outras pessoas para esclarecer o que deve ser feito. O projeto não segue no ritmo esperado e gera um custo adicional à equipe de desenvolvimento.

Não ter tempo para o projeto
Quando se reserva um período no cronograma para o levantamento de dados espera-se utilizar aquele período da melhor forma nas atividades de levantamento, todavia em vários casos o usuário só tem disponibilidade na parte da manhã, duas horas por dia ou apareceu um outro compromisso. Isto novamente traz impacto ao projeto e novamente custo adicional ao mesmo.

Não fornecer dados exemplo para os testes
Em vários sistemas mais complexos são necessários dados mais elaborados para um teste mais confiável. Como a equipe de desenvolvimento não tem uma base de dados exemplo, ela cria seus dados e testa o sistema com estes dados justamente “para ganhar tempo” já que o usuário não forneceu os dados corretos. O que acontece é que durante a validação, começam a aparecer os bugs e o usuário joga a culpa no desenvolvimento. Novamente, advinha de quem é o impacto?

Nestes três exemplos bem comuns podemos ver que houve falha por parte do usuário e isto seria corrigido facilmente com um pouco mais de zelo e foco no projeto.

Eventos como estes ocorrem normalmente por oportunismo do cliente ou omissão do gerente do projeto. Oportunismo porque como o usuário está “pagando”, ele esquece que tem responsabilidades, e Omissão do gerente do projetos porque ele normalmente não quer “chamar atenção” do usuário dizendo que ele não cumpriu algumas de suas responsabilidades.

O gerente do projeto poderia eliminar ou reduzir o impacto em cada um dos casos com atuações como:

Definir pessoas que não conhecem o negócio ou os objetivos do sistema: O gerente do projetos pode acionar o patrocinador do projeto e explanar sobre o impacto ao mesmo. Em casos onde a situação não seja revertida o impacto pode ser transferido ao cliente.

Não ter tempo para o projeto: Novamente o patrocinador do projeto deve ser acionado e isto deve ser feito no primeiro evento. I impacto deve ser transferido ao usuário.

Não fornecer dados exemplo para os testes: O impacto neste caso é mais alto pois pode envolver todo o trabalho da equipe de desenvolvimento. A sugestão aqui é não iniciar o desenvolvimento sem os dados exemplo. Se parar o projeto não for possível, transferir o impacto sempre resolve.

Quando falamos de “trasnferir o impacto” significa transferir o impacto em custos visto que no primeiro caso foi necessário mais trabalho do que o previsto, no segundo caso foi necessário mais dias e o terceiro pode gerar alto retrabalho em decorrência da falta de dados reais.

Como usuário, é importante lembrar que você tem responsabilidades e há uma equipe de desenvolvimento trabalhado para fazer o melhor projetos para você. Dê a devida atenção.

Em uma das últimas entrevistas com Jobs para finalizar o livro, Walter Isaacson perguntou qual teria sido a criação mais importante dele, imaginando que o falecido cofundador e ex-CEO da Apple responderia algo como iPad ou Mac. Só que em vez disso, Jobs respondeu: “a Apple”. Construir uma empresa duradoura é mais difícil e mais importante do que fazer qualquer grande produto.

Por essas e outras, diversas pessoas se interessaram na biografia de Steve Jobs, a fim de entender melhor como funcionava a cabeça do gênio por trás da Apple. Ninguém sabe ao certo as respostas, contudo, em um artigo intitulado The Real Leadership Lessons of Steve Jobs (As Reais Lições de Liderança de Steve Jobs), Isaacson explana o que ele considera as chaves para o sucesso — baseado nas experiências de Jobs:

Foco

Ao retornar à Apple em 1997, a empresa tinha diversos produtos. Uma das primeiras atitudes de Jobs foi dividir o mercado atuante da Maçã da seguinte forma: doméstico/profissional e desktop/portátil. A empresa teria quatro ótimos produtos, um para cada “quadrante”.

Simplicidade

Ao criar o iPod, Steve sugeriu que o botão de ligar/desligar fosse retirado. Depois de analisar, os designers realmente chegaram a conclusão que não era necessário um botão para a função. Por ser totalmente intuitivo, qualquer criança de três anos ou mais “consegue usar um iPad”. O nome disso é simplicidade.

Assuma a responsabilidade, do início ao fim

A Apple é uma das poucas empresas que oferece uma experiência de usuário completa, do início ao fim.

Quando não for o primeiro, inove

Quando o iMac foi lançado, a experiência era focada em fotos e vídeos. Contudo, o mercado começou a caminhar para o download/gerenciamento de músicas. Foi aí que Jobs inovou, lançando o ecossistema musical da Apple (iTunes, iTunes Store e o iPod).

Produto antes dos lucros

Quando for desenvolver um produto, não pense em quanto ele vai gerar de lucro. Tente “apenas” criar um ótimo produto — o resto é consequência.

Não se prenda a pesquisas de mercado

É aquela velha história: se Henry Ford perguntasse para um consumidor o que ele queria, a resposta seria “cavalos mais rápidos.” A resposta para uma quebra de paradigma não está em pesquisas — ninguém precisava de um iPad antes dele ser lançado.

Dobre a realidade

Essa é bem complicada, pois precisa ser praticamente um jedi para conseguir realizar a tarefa com êxito. Todavia, Steve Jobs era praticamente um Yoda, e conseguia convencer qualquer um de que algo era possível, como por exemplo realizar um trabalho que duraria meses, em semanas.

Atribua

Enquanto estavam desenvolvendo o primeiro iMac, Jobs e Ive desenharam uma espécie de alça para carregar o computador pra lá e pra cá. Mas por que, se ninguém ficava levando um computador de um lado para o outro? Quando uma pessoa segurava o iMac daquela forma, a ele se tornava mais próximo, mais amigável, quebrando uma barreira entre máquina e homem. O mesmo acontece com as embalagens de iProducts, que fazem o consumidor ter uma relação mais íntima com o produto.

Busque a perfeição

Em uma história envolvendo Ron Johnson, ex vice-presidente de varejo da Apple, e Steve Jobs, a qual bem próximo ao lançamento da primeira Apple Retail Store, Johnson alertou Jobs que a experiência da loja estava errada — elas deveriam ser organizadas levando em consideração a ideia de hub digital, e não em torno de produtos. Jobs parou e recomeçou a desenhar a estratégia das lojas; o mesmo aconteceu com a tela do iPhone, a qual foi modificada para vidro pouco antes de seu lançamento.

Tolere apenas “os melhores”

Para Jobs, existiam pessoas estúpidas e gênios. Obviamente ele preferia se rodear de “gênios” — basta ver o atual quadro de executivos da Apple para entender isso. Para Jobs (e Al Gore), qualquer um deles poderia assumir uma cargo de CEO em outras empresas — como Ron Johnson fez.

Encontros cara-a-cara

Nada substitui uma conversa franca, cara-a-cara. Para Jobs, uma grande ideia nunca poderia ser discutida por email ou mensageiros, afinal, muita coisa boa surge de encontros espontâneos e conversas aleatórias.

Conheça o todo e o detalhe

Jobs era capaz de definir tanto a estratégia da Apple para um determinado mercado, como também se preocupava com o detalhe do amarelo do logo do Google no web clip na Home Screen do iPhone.

Combine o humano com a ciência

O ex-CEO da Apple sempre tocava nesse ponto em suas apresentações. Ele não era o melhor artista ou designer, tão pouco o melhor engenheiro, cientista. Contudo, se posicionava na interseção dessas áreas — o resultado está aí ao nosso redor, com o logo da Maçã estampado.

Continue faminto, continue bobo

Essa nem precisa de explicação, basta assistir ao discurso de Jobs para uma turma de Stanford para entender perfeitamente o que ele quer dizer com isso.

.  .  .

Em uma nota relacionada, vale conferir também um vídeo (em inglês), de Walter Isaacson no qual ele fala bastante a respeito de suas experiências com Steve Jobs, enquanto escrevia seu livro — a conversa aconteceu em Amsterdã, no John Adams Institute — Isaacson começa a falar a partir dos 10’30”

[Eduardo Marques do Mac Magazine]