Assim, as novas regras são:

• O Content Outline and Learning Objectives – a base para a estrutura e conteúdo do novo exame de CSM – está disponível para download no site da Scrum Alliance.
• Todos os candidatos que prestarem o exame até o dia 31 de Março de 2012 serão automaticamente aprovados.
• A partir de 1º de Abril de 2012, os candidatos serão aprovados ou não de acordo com o seu desempenho no exame.
• A partir de 1º de Abril de 2012, os candidatos terão 60 dias para duas (2) tentativas gratuitas de aprovação. Após este período de 60 dias, o candidato deve pagar US$25 por tentativa. Após três (3) tentativas sem aprovação, é recomendado que o candidato faça um outro treinamento de CSM antes que sejam permitidas novas tentativas.
• O novo exame terá 35 questões, sem limite de tempo. Os candidatos poderão marcar questões, mudar as respostas das questões e até mesmo interromper o exame, retornando a ele posteriormente dentro do prazo de 60 dias.
• Ao final do exame, o candidato verá as questões respondidas incorretamente. A lista de opções não será exibida. Isto para encorajar os candidatos que não passarem na primeira tentativa revejam o conteúdo do curso antes de uma nova tentativa.
• Candidatos que não sejam aprovados na primeira tentativa podem refazer o teste imediatamente (não é necessário um período mínimo) ou a qualquer momento dentro do período de 60 dias.
• Depois de aprovado, o candidato pode renovar sua credencial a cada dois anos. A Scrum Alliance criará até Janeiro de 2013 o programa de Professional Development Units (PDUs). Os CSMs deverão obter estes PDUs para manter suas certificações.

Maiores detalhes sobre o programa de PDUs serão informados em breve.

Informações por adaptworks.com.br

Então, o que fazer?

A solução estaria então em adotar um Processo de Software bem definido. Muitos são os tipos de processos e muitas são as necessidades de equipes e das empresas em ter e utilizar um bom Processo de Software a fim de adquirir organização e qualidade em seus produtos, respeitando prazos de cronograma, administrando esforços de equipe, obtendo mais produtividade e padronização de desenvolvimento.

Porém, não acredito que exista um único processo perfeito para o desenvolvimento de software, ou seja, para adquirir um bom processo, deve ser levado em consideração fatores como:

• Tipo de software que está desenvolvendo;
• Tamanho de equipe (desenvolvedor único, dois desenvolvedores, equipe pequena, equipe com mais de 100 membros);
• Infraestrutura;
• Capital investido;
• Entre outros.

Entre diversos tipos de Processos de Softwares, destacam-se os modelos em Cascata (CMMI), Espiral, Iterativos (PU – Processo Unificado) e os modelos Ágeis (XP, Scrum).

Mas por que utilizar um Processo de Software?

Dentre alguns fatores, podemos definir que o Processo de Software visa à qualidade do produto como um todo, onde é estabelecida a lógica do domínio da aplicação para o projeto decidindo seu scopo e comprometimento do Patrocinador, levantamento dos requisitos, riscos de projeto, padronização de desenvolvimento, construção do modelo e prototipagem, implementação sistemática de testes, feedback do cliente, revisões técnicas, gerência de configuração, etc. Porém, todo este conjunto (o Processo) não basta apenas ser implementado, ou seja, deve-se ter o gerenciamento do processo como um todo a fim de garantir que ele esteja sendo executado corretamente por seus envolvidos.

Em outras palavras, o Processo de Software não é uma tarefa simples de implementar numa organização. Ele “afeta” diretamente seus envolvidos, no qual em alguns casos, são obrigados a saírem de suas zonas de conforto. O processo também confronta a cultura de uma empresa, e todo este conjunto gera uma certa resistência dos envolvidos em colaborar para o sucesso do mesmo.

Meu artigo não é de forma alguma induzir o leitor a optar para um processo X ou Y, mas sim avaliar o nível caótico de não se utilizar um processo e os benefícios conquistados com sua aplicação.

Particularmente, um dos modelos que mais me apego são os modelos Ágeis, devido a suas práticas, valores e por serem iterativos.

Os modelos iterativo e evolutivo envolvem a imediata programação e teste de um sistema e considera que o desenvolvimento começa antes que os requisitos tenham sido definidos em detalhes. Evitando assim grandes desgastes e desmotivação na fase inicial.

Nesta abordagem de ciclo de vida, o desenvolvimento é organizado em uma série de mini projetos curtos, de duração fixa chamadas de iterações. O produto de cada um é um sistema parcial, executável, testável e integrável. Cada iteração inclui suas próprias atividades de análise de requisitos, projeto, implementação e teste. No modelo Ágil, os detalhes de requisitos são acrescentados no decorrer do processo, utilizando assim, a modelagem na perspectiva de principalmente entender o que foi pedido e não documentar.

Ao contrário, nos modelos em cascatas (ou sequencial), há uma tentativa de definir em detalhes todos ou a maioria dos requisitos antes da programação e também de criar um projeto abrangente, antes da programação. Igualmente, há uma tentativa de definir um plano ou cronograma confiável logo no início. Outro ponto a ser avaliado, é que neste modelo, modificações tardias de requisitos não são bem vindas. Deve levar-se em conta que custos de operações aqui são bem mais altos e é um modelo muito burocrático.

Apesar do meu apego ao modelo Ágil, o ideal é que as equipes criem seu próprio Processo de Software, olhando na perspectiva de não diminuir o valor de outros métodos e sim, agregando as boas práticas mais comuns que atendam as suas necessidades dentro da sua realidade, não se esquecendo de manter um contínuo amadurecimento do processo como um todo.

Fonte: Blog Rafael Amaral
Twitter: @rafaelamaralll

Certamente o fator principal está no envolvimento com o consumidor, na comunicação efetiva da marca com o cliente final. Essa comunicação que estou me referindo não é apenas a comunicação verbal, estou falando em uma comunicação sensorial também. Como assim?

Todos sabem que eu sou um tanto fora da caixa (risos), para alguns isso é um grande problema e para outros uma grande benção, mas longe de querer encontrar a resposta para isso – se é ou não uma coisa extraordinária, pretendo fazer com que entendam o meu ponto de vista de uma forma simples dentro desse assunto.

Quando digo comunicação sensorial me refiro ao se comunicar por todos os meios e sentidos. Vamos exemplificar com uma loja virtual qualquer… O cliente entra no site lê, vê e ouve inúmeras e coerentes informações sobre um determinado produto – logo, faz a compra. Após comprar recebe e-mails automáticos para verificar o Status do pedido, comunica-se por e-mail,redes sociais, chats e telefone, afim de tirar pequenas dúvidas. No prazo informado o produto chega, o cliente recebe uma linda caixa que o impacta de forma positiva, tem o primeiro contato visual com o produto em mãos e no final de tudo ele faz uma crítica sobre todo o processo da loja, positiva ou não depende da competência da gestão de cada etapa dessa loja virtual.

Esse processo que usei como exemplo permite que seja observado uma comunicação além do básico, ou seja, o envolvimento de quase todos os sentidos humanos no processo de construção da experiência de compra – novamente eu aproveito e afirmo que Humanizar processos em e-commerce é o caminho certo para crescer.

Explorando um pouco mais o exemplo podemos observar os sentidos:

Visão:

Cliente entra na loja virtual, fotos do produto, vídeo demonstrativo, cliente recebe um produto bem embalado, cliente recebe o produto que comprou em perfeitas condições com todas as documentações necessárias.

Audição:

Cliente assiste o vídeo e ouve sobre a tecnologia do produto (por exemplo), recebe atendimento via telefone, recebe contato telefônico para pesquisa de qualidade…

Tato:

Cliente recebe o produto bem embalado (nada de papel pardo ou papelão não tratado), cliente manuseia o produto que está em perfeitas condições…

Olfato:

Cliente recebe produto bem embalado e higienizado (sim, eu mesmo já recebi produtos eletrônicos embalados em papelão não tratado e com um odor insuportável)… Sabe aquele cheirinho de novo que todos comentam quando compram um carro? Então, lembre-se disso, é a experiência de compra. Obs.: Já vi loja enviando papel perfumado, quando recebi não tive dúvidas ,fui para as Redes Sociais falar bem pra caramba dessa loja. Só não falo aqui pra não ser considerado jabá

Agora não é difícil perceber que ter um e-commerce que diferencie-se dos demais exige um certo pensamento fora da caixa, não é mesmo? Entender que diferenciar-se da concorrência é fazer e pensar além do que eles fazem ou pesam, agir de forma diferenciada e eficiente é o que fará você conquistar mercado. Não preciso comentar que tais vantagens estão ligadas as principais métricas de uma loja virtual – a recompra e a permanência do cliente em atividade e visibilidade.

Um grande abraço, sucesso a todos.

Luiz Castro Jr.
Alpisconsultoria.com

Assim como grande parte de meus amigos que trabalham com TI (por isso estou publicando este artigo no PTI) estou cheio de idéias e nem sempre consigo organizá-las adequadamente, e pensei que o BMG poderia me ajudar – Hoje tenho certeza disso e quero que você também possa usufruir as benesses deste modelo.

Mas então vamos falar sobre o Business Model Generation

O BMG é um modelo de plano de negócios visual, simples assim.

Falar é mais difícil do que visualizar (como o método prega) assim, segue a visualização do Canvas (mais a frente falarei mais sobre o Canvas):

Como eu sei que você vai gostar de usar o BMG aproveite e faça o download do PDF em boa resolução para impressão. Recomendo que faças a impressão num birô de impressão em tamanho A3.

E pra facilitar ainda mais o entendimento, este vídeo abaixo é matador:

Quase 500 (co)autores participaram da criação da ferramenta, que foi uma publicação própria, sem auxilio de editoras. Note que a própria criação do método é feita de uma forma inovadora: estas pessoas PAGARAM para participar da construção do método.

Sério, eles pagaram para escrever e você provavelmente não entendeu o por quê eles fizeram isso, certo?
Dá uma olhada nesse vídeo aqui que tem algumas ‘pistas’.

O livro é um dos mais procurados em diversas categorias no Amazon.com:

1. Systems & Planning
2. Small Business & Entrepreneurship
3. Business Management

Não à toa empresas como 3M, PwC, Deloitte, IBM entre outras gigantes estão usando o BMG.

O livro (que pode ser adquirido na Amazon.com por um preço mais barato do que a impressão do preview em birô) é fantástico, e feito num formato totalmente visual – Para quem, assim como eu, precisa ‘ver as coisas’ o livro é um tapa na cara. Ele começa te fazendo algumas perguntas:

• Você tem um espírito empreendedor?
• Você fica pensando emcomo criar valor e gerar novos negócios e transformar sua empresa?
• Você está buscando formas inovadoras de fazer negócios para acabar com os velhos modos? Se sim, então aqui tem uma boa quantidade de informação sobre como fazer isso.

Sobre o Business Model Canvas

O BMC, é uma ferramenta de gestão estratégica e empreendedora. Ele permite que você para descrever, design, desafio, inventar, e pivô seu modelo de negócio e está dividida em 9 importantes partes que eu descrevo na sequência e devem ser preenchidas e pesquisadas para que o BMC seja completo (para ser mais fiel à publicação manterei os títulos em inglês).

Customer Segments

Este bloco de informações define quais são os diferentes grupos de pessoas (ou empresas) que um organização se propõem a atingir. Este bloco deve responder:

• Para quem nós criamos valor?
• Quais são nossos clientes mais importantes?

Value Propositions

Este bloco se propõem a descrever o conjunto de produtos e/ou serviços que criam valor para um determinado segmento de clientes. Deve responder:

• Para quem nós criamos valor?
• Quais problemas de nossos clientes estamos ajudando a resolver?
• Quais necessidades estamos atendendo?
• Quais os conjuntos de produtos/serviços que estamos oferecendo para cada segmento de clientes?

Channels

De que formas sua empresa/negócio se comunica e atinge os diferentes segmentos? Como é entregue cada uma das proposições de valor?
Além disso:

• Por quais canais nossos diferentes segmentos de clientes desejam ser ouvidos?
• Quais nós usamos?
• Como estes canais estão integrados?
• Quais funcionam melhor para cada segmento de clientes?
• Quais os mais eficientes (sob a visão de custos)?

Customer Relationships

Qual a relação que sua empresa estabelece com cada um dos segmentos de clientes?
Saiba também:

• Qual o tipo de relação cada um dos segmentos de clientes esperam que mantenhamos com eles?
• Quais nós já temos?
• Quanto custa cada um?
• Qual a integração com o restante do modelo de negócios?

Revenue Streams

Este bloco representa a(s) forma(s) que o negócio gera receita a partir de cada um dos segmentos de clientes.
Descubra :

• Por que valor nossos clientes estão dispostos a pagar?
• Pelo que eles atualmente estão pagando?
• Como eles estão pagando?
• Como eles gostariam de pagar?
• Como cada receita contribui para o resultado geral?

Key Resources

Este bloco de informações descreve quais são os principais recursos para que o modelo de negócios opere.
Entenda:

• Quais recursos nossas proposições de valor exigem?
• Quais recursos são exigidos pelos nossos canais de distribuição?
• E quais recursos são exigidos para manter o relacionamento com nossos clientes?

Key Activities

Neste conjunto é evidenciado quais as principais atividades precisam ser realizadas para que o modelo de negócios funcionar.
As principais perguntas a serem respondidas são:

• Quais as principais atividades que precisamos realizar para entregar nossa proposta de valor?
• E por nossos Canais?
• E por nosso tipo de relacionamento com clientes?

Key Partnerships

Este bloco descreve como a rede de fornecedores e parceiros é composta para que o negócio rode.
Você deverá saber:

• Quem são os principais parceiros?
• Quem são nossos fornecedores principais?
• Quais recursos estamos adquirindo de nossos parceiros?
• Quais as principais atividades são executadas pelos parceiros?

Cost Structure

Quanto custa operar todo o negócio.
Procure:

• Quais são os custos mais importantes no modelo de negócios?
• Quais os principais recursos mais caros?
• Quais as principais atividades mais onerosas?

Os resultados

Podem ser surpreendentes ao preencher o Canvas:

Por fim: use o BMG da forma que você achar mais interessante, incluindo como o pessoal da da BizRevolution.

E nunca é demais lembrar que ao preencher você pode:

1. Use os “Sticky Notes” (mais conhecidos como Post-It) para construir os blocos de ideias: as idéias precisam de mobilidade assim ficará fácil movê-las de lugar
2. Escreva mas PRINCIPALMENTE desenhe. Lembra daquela expressão “Entendeu ou quer que eu desenhe?”. A minha resposta sempre é DESENHE.
3. Use cores nos Sticky Notes agrupando por temas (segmento de clientes, por exemplo).
4. Crie alternativas. Não se apaixone pela primeira idéia.
5. Crie uma estória com seu plano de negócios.
6. Mapeie com o Canvas todos os negócios que você julgar como relevantes e importantes. Você aprenderá pelo exemplo dos melhores.

O Scrum foi desenvolvido pela primeira vez a mais ou menos 15 anos atrás, e vem evoluindo e sofrendo adaptações desde então. Suas regras, artefatos e eventos estão descritas no Guia Scrum.

O anúncio marca uma nova era na evolução Scrum, tornando disponível um mecanismo para que o público possa  fornecer feedback sobre o Guia Scrum, além de fornecer um modelo para propor extensões para a sua estrutura básica.

O processo formal para propor alterações que possam vir a integrar o Guia Scrum está disponível online no site scrum.org.

Para saber mais sobre Scrum, ou propor a sua própria contribuição, você pode usar os seguintes links:

Ler – http://www.scrum.org/scrumguides/
Alterar – http://www.scrum.org/scrum-guide-proposal/
Estendê-lo – http://www.scrum.org/scrum-extensions /

Esta é uma tradução livre do post original, disponível em http://agiletips.blogspot.com/2011/10/scrum-is-open-for-extension-and.html

Figura 1: Ciclo de um release em SCRUM (Mountain Goat 2011)

Existem três papéis principais que o compõem: a Equipe, Product Owner e Scrum Master.

• Equipe: Responsável por entregar soluções. Geralmente é formada por um grupo pequeno (entre 5 a 9 pessoas) multifuncional e que trabalha de forma autogerenciada e auto-organizada.

• Product Owner: Responsável pela visão de negócios do projeto. Cabe a este papel definir e priorizar o Product Backlog. Geralmente é o papel desempenhado pelo cliente ou por um gerente de produtos da empresa que desenvolve o software.

• Scrum Master: é uma mistura de gerente, facilitador e mediador. Seu papel é remover obstáculos da equipe e assegurar que as práticas de Scrum estejam sendo executadas com eficiência.

Como o SCRUM funciona ?

Definição do Product Backlog: Todas as funcionalidades ou mudanças no produto são definidas pelo Product Owner no Product Backlog. Esta lista é priorizada para refletir a necessidade dos clientes ou demandas do mercado. Os itens do topo possuem prioridade maior do que itens no final da lista.

Planejamento do Sprint: Ocorre em duas partes, cada uma delas com time-box[1] de quatro horas. Na primeira parte do planejamento, o Scrum Master reúne-se com o Product Owner para verificar qual é oProduct Backlog. Na segunda parte, o Scrum Master reúne-se com a Equipe para estimar o esforço necessário para os itens do Product Backlog (usando estimativa ágil como Planning Poker) e para planejar o Sprint.

Andamento do Sprint: Durante o Sprint, os itens do Product Backlog que devem ser entregues são tratados em um artefato conhecido como Sprint Backlog, que contém os itens do Product Backlogsubdivididos em tarefas menores. As tarefas são responsabilidade da Equipe, que tem autonomia para decidir como elas devem ser executadas.

Reuniões Diárias: O Scrum Master se reúne diariamente com a Equipe sempre em um mesmo horário. Nesta reunião, cada membro da equipe responde três perguntas básicas:

• O que foi feito ontem?
• O que se pretende fazer hoje?
• Quais são os impedimentos que estão atrapalhando a execução das tarefas?

Revisões: No final do Sprint a Equipe demonstra os resultados para o Product Owner e demais interessados em uma reunião chamada Sprint Review, de forma que os itens do Backlog sejam considerados prontos e então possa se iniciar um novo Sprint. A equipe também faz uma reunião de auto avaliação no final do Sprint chamada Sprint Restrospective. Nela discute-se o que aconteceu durante a iteração finalizada, identificando o que funcionou bem e o que pode ser melhorado.

Monitoramento do Projeto: Para reportar o andamento do projeto usa-se um Burndown Chart, que é um gráfico onde o eixo x é a linha de tempo do projeto e o eixo y é o número de pontos a serem vencidos, que representam os pesos das funcionalidades potencialmente implantáveis do Product Backlog.

1) Em treinamentos sobre Scrum, o próprio Boris Gloger costuma compará-lo ao jogo de Rugby. É muito comum este jogo ser citado quando explica-se o funcionamento do Scrum. Você poderia avaliar esta comparação, na prática, do método com o esporte?

Resp.: Como devemos pensar em um jogo, seja de Rugby ou algo mais brasileiro? _ é sábio se preparar para cada partida. A comparação é que devemos entender cada partida de um esporte como um SPRINT. Em outras palavras, não podemos proceder de  forma igual, robótica, sem inovação em cada SPRINT. E é justamente este o ponto do SCRUM com os times de esporte. É uma inversão da pirâmide, ou seja, os programadores são muito importantes para o projeto como os jogadores para o time naquela  partida. Não adianta o gerente do projeto trazer controles que mais parecem uma auditoria e “burocratizam” o desenvolvimento. No fim, quem faz a diferença no projeto são os desenvolvedores (ou jogadores do time).

2) Há ainda um medo muito grande dos gestores em mudar radicalmente o formato de gerenciamento de projetos. O que falta para que eles confiem nas metodologias ágeis? Como convencê-los a investir no Scrum?

Resp. 1: Primeiro devemos rever o termo “mudar radicalmente”. Sugiro pensarmos em aplicar novos métodos como uma proposta de atingir resultados diferentes dos atuais obtidos. O principal motivador de uma mudança é a vontade. Não adianta o melhor consultor de SCRUM se a organização contratante não tem vontade de mudanças. Em minha leitura não é uma questão de confiança, pois é normal desconfiar de qualquer coisa nova que não se conhece com responsabilidade. É uma questão da organização estar descontente com os seus atuais e próprios resultados, assim criando uma vontade de mudanças.

Resp. 2: Para investir em qualquer coisa, deve-se compreender com transparência quais os benefícios, quais os resultados práticos, deste investimento. Podemos também nos utilizar da comparação financeira entre propostas de SCRUM, tipicamente baratas e rápidas (entre 3 a 6 meses para implantar) e outras metodologias que normalmente são caras e levam mais tempo para serem implantadas.

3) O Scrum atalha caminhos, diminui custos, tempo e barreiras através de um processo iterativo, que promete entregar funcionalidades de negócios a cada trinta dias. É realmente fácil fazer isto acontecer? Ao apresentar o método a uma empresa, pode-se ter certeza de que o investimento para que seja aplicado o Scrum será bem sucedido?

Resp.: O SCRUM não faz mágicas, até porque mágicas em projetos de software não são funcionais. Se praticado corretamente, o SCRUM proporciona melhores resultados no gerenciamento de escopo e gestão de mudanças, além de promover a interação com o cliente de forma constante. Esta interação trará resultados benéficos na gestão da expectativa do cliente. Também a iteração praticada pelo time pode proporcionar resultados como produtividade, desde que pratique-se com cuidado não esquecendo a qualidade. Então, de maneira objetiva a sua pergunta, é de complexidade média implantar SCRUM e o investimento será bem sucedido se o protagonista da implantação for o contratante, e não o consultor.

4) O Scrum é adaptável a qualquer projeto, grande ou pequeno. Há uma grande diferença na gestão através desta metodologia em relação ao tamanho do projeto?

Resp.: Penso que respondo melhor sua questão com uma analogia metafórica. Você se prepara, se controla da mesma forma durante a competição quando vai correr 400 metros e quando vai correr uma maratona? Certamente não. Assim também são os projetos, independente da metodologia que se vai usar. Em minhas consultorias recomendo formalizarmos uma proposta de processos para projetos rápidos (até 320 horas), para projetos de médio prazo (até 960 horas), para projetos longos (acima de 1000 horas) e ciclos de manutenção corretiva – evolutiva. É um grande equívoco tratar estes projetos de tempos e complexidades diferentes de uma forma única, genérica.

5) No contexto do Scrum, o time deve ser autônomo. Quais as vantagens e desvantagens desta auto-organização, de forma que eles resolvam todos os problemas entre si, sem recorrer a membros mais experientes? Causa uma certa estagnação na equipe?

Resp.: Na minha leitura isso é maravilhoso, apesar de reconhecer o quanto é difícil a aplicação na prática. Um indivíduo colaborador de um time pode ser muito mais efetivo se for interdisciplinar do que sendo especialista somente. O problema é que o modelo tradicional de gestão criam os especialistas, nutrem os especialistas, engessam os especialistas. Quando se monta uma distribuição de atividades, denomina-se aquele tipo de atividade sempre para o mesmo recurso. Ou seja, a própria gestão do projeto vicia o código, vicia o conhecimento do projeto, especializando em poucos. A auto-organização é eliminar o pensamento de indivíduo e pensar no time como um único corpo; desta forma, todos podem trabalhar em todas as partes do projeto. Se todos conseguem ser produtivos no projeto, não há estagnação, há crescimento contínuo.

6) O Scrum foca na liderança e não na gestão. Qual o diferencial de um Scrum Master para um gestor de projetos?

Resp.: Esta é uma pergunta que dificilmente encontrará uma resposta inquestionável. Na minha opinião, o SM está comprometido com o projeto e com o time. O gestor tradicional está comprometido com os controles, com a administração, com os números e com o cliente. Não podemos desconsiderar nenhum dos comprometimentos expostos. O ideal é que o líder do projeto tenha um conhecimento interdisciplinar e possa aplicar o melhor método conforme a situação. A hierarquia de atitude do projeto deve ser: Satisfação do cliente, crescimento do time (como conhecimento, postura, resultado) e satisfação com o projeto. Esta hierarquia não é exatamente SCRUM ou gestão de projetos clássica, é minha posição conforme minhas realizações históricas.

7) Nas reuniões diárias, no começo de cada iteração, três perguntas são propostas (O que fiz ontem? O que farei hoje? Quais são os impedimentos?). Há também os Sprints semanais, mensais e trimestrais. Qual o objetivo de cada uma destas reuniões?

Resp.: Um dos maiores desafios na liderança de um projeto é obter um “feedback” real, uma informação binária de como está de fato aquela atividade no projeto. Se você como líder, ir todos os dias até determinado integrante do time para questionar o estado (status) da atividade – certamente criará problemas de relacionamento com o time. As reuniões diárias e todas as outras proporcionam métodos para obter o feedback sem os melindres de outras formas de obter esta informação. Por outro lado, estas reuniões também proporcionam um maior comprometimento do time com o projeto. É o conceito de inversão da pirâmide, ou seja, os integrantes operacionais do projeto são muito mais importantes e ativos que os stakeholders, e eles se sentem desta forma devido aos métodos proporcionados pela reunião.

Fonte: Marketing FCamara

Com um time estruturado, a empresa irá, aos poucos, observar as necessidades a serem complementadas aos clientes. Um ponto de atenção imprescindível está no atendimento dos clientes ativos. Muitas companhias pecam em pensar que o principal trabalho está em conseguir novos clientes e acabam por esquecer ou desnivelar a qualidade dos serviços da carteira ativa.

Para manter e aumentar a capacidade de retenção de clientes, em longo prazo, é necessário que as empresas abram um espaço para um time de relacionamento. É  necessário não só resolver problemas, mas ter alguém com capacidade para mapear e rediscutir processos já implementados, algo que resultará na alavancagem de novas oportunidades de negócios.

A fidelização de um cliente representa a satisfação, segurança, valorização e visibilidade do trabalho prestado. Mas para isso, ele ( cliente ) precisa enxergar valor nos serviços prestados e comprometimento por parte da empresa contratada nos atendimentos dos níveis de serviços.  Esta lógica pode e deve ser inserida em empresas de todos os portes e setores, sendo uma estratégia essencial para sobrevivência no mercado moderno. Um atendimento profissional deve ser de qualidade, rápido, seguro e preciso. Um erro neste estágio representa maior abertura aos concorrentes, que estarão sempre prospectando dentro da sua base de clientes.

Os profissionais de Relacionamento devem pautar o seu trabalho em visitas constantes aos clientes. O motivo? Simples. É lá, dentro do cliente, conversando com as pessoas que você consegue medir a temperatura em relação à qualidade dos serviços prestados. Sejam em reuniões previamente agendadas ou em um encontro informal, as informações irão chegar a esse profissional.  Nesse momento, o ideal é que exista um bem elaborado Plano de Contas que dever ser composto pela análise dos seus pontos fortes e fracos, assim como a identificação de ameaças e possíveis oportunidades de novos negócios.

Além disso, entender quem são as influências compradoras e os seus respectivos comportamentos em relação à empresa contratada torna-se fundamental para você aumentar a sua participação dentro dessa conta. Há diversas influências dentro dos clientes: a do usuário, preocupado com a resolução dos problemas, a técnica, cujo foco é o aumento de produtividade e melhorias em processos e a econômica mirando na redução de custos.

Com a metodologia implantada, o próximo desafio é convencer o profissional da área de Relacionamento a ter uma disciplina para atualização dessas informações em algum sistema de CRM (Customer Relationship Management) e mostrar a ele que essa atividade pode ajudar na tão desejada visibilidade do trabalho.

*Edgar Ferretti é líder da equipe comercial e relacionamento da Acesso Digital

Seu diretor liga para você e diz: “Esqueci os contratos em minha mesa e já estou no aeroporto de Congonhas, você poderia trazê-los para mim? Ficarei aguardando por você no saguão do aeroporto!”. Você está na região da Av. Paulista e precisa chegar o quanto antes no aeroporto. Decide então pegar um táxi e chama o Seu Manuel, taxista conhecido da empresa: “Seu Manuel, daqui para o Aeroporto de Congonhas quanto tempo levaria e qual seria o valor aproximado da corrida?”. Seu Manuel, de acordo com sua experiência, lhe dá uma estimava: “Olha, nesse horário creio que em 30 minutos estejamos por lá e sairá em torno de R$35″. Você acha a estimativa satisfatória e decide ir com seu Manuel até o aeroporto. Ao entrar na 9 de Julho você percebe que o trânsito está completamente parado até mesmo para ir pelo corredor de ônibus. Seu Manuel lhe sugere um atalho que corta sentido a Av. Tiradentes e que economizaria tempo. Como se trata de uma situação urgente você decide ir pelo atalho sugerido.

Algum tempo após ir pelo atalho sugerido começa a chover muito em São Paulo e além de o trânsito ficar complicado há alguns metros é possível ver que uma árvore caiu na pista, impossibilitando a passagem de qualquer veículo. Preocupado, você pergunta novamente a Seu Manuel se há alguma maneira de contornar este caminho e encontrar outra saída. Seu Manuel diz que se voltarem um pouco o caminho feito e tentarem ir por dentro do Centro é possível que não se atrasem tanto. Você aceita novamente a proposta de Seu Manuel, pois vocês realmente tiveram problemas durante todo o percurso.

Finalmente vocês conseguem chegar ao aeroporto, porém, você percebe que o táxi levou 90 minutos para chegar até o destino, e ao invés de custar R$ 35 (como previsto), custou R$ 130. O que você faria? Ficaria irritado? Nunca mais utilizaria os serviços prestados por Seu Manuel? Mas veja, você estava dentro do táxi o tempo todo e percebeu que ele fez o possível para chegar a tempo, e realmente se esforçou lhe oferecendo diversas opções, as quais você aceitou, pois percebeu que realmente eram situações de dificuldade. Você viu que o trânsito estava ruim, que a chuva complicou ainda mais e que um grave acidente no meio do caminho piorou as coisas. Você viu que quando isso aconteceu Seu Manuel tentou pegar outro caminho para fugir do trânsito e, por mais que a estratégia tenha sido boa, não foi suficiente para chegar a tempo. O que você fará? Há uma probabilidade muito grande de você, mesmo chateado, pagar o taxista e entender o lado dele, afinal você viu o quanto ele se esforçou.

Agora, no mesmo cenário, imagine que, ao invés de ir no táxi, você apenas contrata o Seu Manuel para levar os documentos para o aeroporto. Ele lhe deu a mesma estimativa de tempo e custo. No entanto, 90 minutos depois ele lhe liga e diz: “Olha, o trânsito estava muito complicado e só cheguei agora, o custo foi R$ 130 ao invés de R$ 35″. Qual será sua reação agora? O que você pensará?

Provavelmente você pensaria que Seu Manuel estava te enrolando, abusando de sua confiança, pois você não estava presente em cada uma das mesmas situações que iriam ocorrer se você estivesse com ele no táxi.

Uma situação como essa nos mostra a grande diferença entre “estar dentro do táxi” e “estar fora dele”, e esse é um dos grandes diferenciais que o Scrum pode agregar ao seu time tendo o P.O (Product Owner) presente em cada uma das evoluções do projeto, sentindo na pele as dificuldades junto com seu time e decidindo sobre o que deverá ser feito, pois o ele é o dono do projeto e o mais interessado em sua realização.

Devemos não apenas nos colocar no lugar do cliente, mas devemos colocá-los dentro do táxi! Fazer com que ele realmente sinta que estamos comprometidos e que realmente estamos juntos para que haja sucesso em seu projeto.

Clique nas imagens para ampliá-las.

Diagrama de Caso de Uso

Representa o conjunto de comportamentos de alto nível que o sistema deve executar para um determinado ator. É o diagrama mais simples, e não há necessidade de grandes detalhamentos.

A figura acima ilustra um caso de uso geral, mas é recomendado que eles sejam desenvolvidos para cada cenário. As setas de includes e extends, indicam, respectivamente, obrigatoriedade e opção de se realizar determinada ação.

Diagrama de Classes

Representa uma coleção de classes e seus inter-relacionamentos.

Diagrama de objetos

Representa um retrato, em tempo de execução, dos objetos do software e seus inter-relacionamentos.

Diagrama de Colaboração

Representa uma coleção de objetos que trabalham em conjunto para atender algum comportamento do sistema.

Diagrama de Sequência

Representa uma perspectiva, orientada por tempo, da colaboração entre os objetos.

Diagrama de Atividades

Representa o fluxo de tarefas que podem ser executadas pelo sistema ou por um ator.

Diagrama de Estados

Representa um conjunto de estados que um objeto pode estar e os “gatilhos” que estimulam a transição do objeto de um estado para outro.

Diagrama de Componentes

Representa uma coleção de componentes de software e seus inter-relacionamentos.

Diagrama de Depuração

Representa uma coleção de componentes e mostra como esses são distribuídos em um ou vários nós de hardware.

Diagrama de Pacotes

Representa uma coleção de outros elementos de modelagem e diagramas.

Artigo postado originalmente em Eu Faço Programas