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

PMP -  Project Management Professional (PMP - Profissional de Gerência de Projetos , em português) é um documento emitido pelo Project Management Institute (PMI) que atesta profundos conhecimentos nas boas práticas de gerenciamento de projetos, responsabilidade social e ética, baseados na norma PMI-ANSI denominada PMBOK.

PMI - Project Management Institute – ou seja quem dá o certificado de PMP

PMO - Project Management Office ou Escritório de Projetos. É uma unidade organizacional com o objetivo de conduzir, planejar, organizar, controlar e finalizar as atividades

PMBOK -  Project Management Body of Knowledge, é um conjunto de práticas em gerência de projetos levantado pelo Project Management Institute (PMI) e constituem a base da metodologia de gerência de projetos do PMI. Estas práticas são compiladas na forma de um guia, chamado de Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, ou Guia PMBOK®.

Resolvi esclarecer porque já vi muito profissional dizendo que é PMO! Fiquei imaginando o sujeito com cadeira e mesa grudada no corpo, já que PMO é uma unidade organizacional !

Outro me disse que tinha muita experiencia em PMI! Perguntei o que ele achou da Filadelfia – ele não entendeu! Porque imaginei, se o “ser” tem experiência no Instituto que emite os certificados de Gestão de Projetos é porque conhece a edificação como ninguém!

E essa é a melhor : (…)” estudei muito o PMBOOK(!!) , é um livro muito bom, que me ensinou todas as técnicas de controle de projeto” –  Meus sais…

Querido profissional de projetos – PMBOK  não é Livro de gerência de projeto em Inglês!

Acho realmente que esse negócio de ser gerente de projeto esta super valorizado.

Todo mundo que ser, quase ninguem é!

Todo mundo quer contratar, mas poucos conseguem.

Todo mundo que acha que é, não é sombra do que deveria ser.

Os PMP’s são muito mal humorados, ninguém nas empresas gosta deles!

São muito rígidos – não saem do lugar se não for feito um EAP ( Estrutura Analítica de Processo ).

Não estou criticando, pois, já fui gerente de projetos e acho realmente que até pra fritar ovo é preciso ter metodologia. Mas meus amigos PMP’s precisam de um pouco de flexibilidade não acham?

Abaixo apresento minha equipe vencedora de projetos:

• Skypper : Gerente de Projeto PMP
• Kowalsky: Analista de Processos/Coordenador de Projeto
• Rico – Cronograma man
• Private – o estagiario

Divirtam-se!

Fonte: http://ecommercegirl.com/?p=192

Buscando na web, encontrei um artigo bacana escrito por José Carlos Macoratti no qual estarei abaixo compartilhando com vocês com o consentimento do próprio autor.

Se você é um desenvolvedor de software , quer como consultor independente quer trabalhando em uma empresa de desenvolvimento de software , com certeza já ouviu muitas vezes as seguintes indagações:

Quanto custa o desenvolvimento deste sistema? ou Quanto você cobra para desenvolver este sistema?

Qual o prazo de entrega do sistema? ou Quanto tempo você leva para desenvolver este sistema?

Isto é perfeitamente normal e previsível , afinal um cliente tem o direito de saber quanto vai custar e em quanto tempo vai ficar pronto o produto que ele deseja receber.

O que não é normal é o fato de que mesmo convivendo com estas indagações no seu dia dia a tanto tempo , você , quer como gerente de projeto ou desenvolvedor , não ter condições de responder com segurança a nenhuma delas.

Quando você contrata o serviço de um pedreiro , ele , após saber exatamente o que tem que fazer faz alguns cálculos e lhe da o preço final do seu trabalho. O mesmo ocorre nas áreas de engenharia civil , mecânica , etc.

Por que é tão difícil estimar o valor de um projeto de software ? Por que é tão complexo fazer estimativas nesta área ?

Seria porque software não têm peso , nem cheiro ? ou seria o fato de que não vemos e nem sentimos um software ?

Creio que as respostas a estas indagações seriam feitas se você soubesse responder a seguinte pergunta:

Qual o tamanho do sistema?

Para saber o tamanho do sistema é necessário realizar medições ou medidas. Certo ?

Certo, pois, “não se consegue controlar o que não se consegue medir”. (Tom DeMarco)

A métrica é o número que você vincula a uma idéia. Para o projeto de software comum , os aspectos quantitativos onde mais precisamos usar a métrica são: escopo, tamanho, custo, risco e tempo empregado.[1]

Para que a métrica usada seja útil ela deve possuir as seguintes características: ser mensurável , ser independente, ser explicável e precisa.

Creio que agora você concorda em que há fortes motivos para medir o seu sistema , dentre estes motivos temos:

• Fornecer subsídios para determinar o esforço, os recursos, a duração e os custos de desenvolvimento
• Avaliar a produtividade do processo de desenvolvimento adotado
• Formar uma base histórica para embasar estimativas futuras

• Indicar a qualidade do produto

Então qual a medida que você deve usar para determinar o tamanho do seu sistema ?

Tipos de medidas de tamanho de software

1- SLOC – linhas de código

Medir software contando as linhas de código (SLOC) é uma das medidas mais antigas para determinar o tamanho, esforço e produtividade no desenvolvimento de software.

È muito fácil de usar e aplicar; basta contar a quantidade do número de linhas de código de um programa.

A medida de SLOC é considerada uma medida física do tamanho de software por medir o volume de código-fonte de um programa.

Ela tem no entanto as seguintes desvantagens :

• Depende da linguagem de programação usada (o número de linhas de um programa Cobol é totalmente diferente de um em Java)
• Ausência de padrões de contagem. (Cada linguagem possui suas características de sintaxe e semântica)

• Não pode ser aplicada nas fases iniciais de desenvolvimento (No início o programa ainda não esta escrito)

Nota: No site http://sunset.usc.edu/research/COCOMOII/ você pode fazer o download de um aplicativo demo da Softstar para realizar estimativas de tamanho usando SLOC.

2- APF – Análise de Pontos por função

Podemos dizer que atualmente á a técnica mais usada para medir o tamanho de projetos de software. Foi criada por Alan Albrecht na IBM na década de 70 e consiste em determinar o tamanho funcional (o que é entregue) do sistema através da visão do usuário.

Ela possui as seguintes vantagens:

• Independe da tecnologia utilizada
• É simples de usar e ser entendida pelo usuário e desenvolvedores
• é consistente e intercambiável
• Pode ser utilizada desde o início do sistema.

A APF (Análise de Pontos por Função) pode ser vista como um técnica que permite dimensionar o tamanho de um software a ser desenvolvido , melhorado ou adquirido; e também um técnica para realizar estimativas de custo e recursos para o desenvolvimento e manutenção de software.

A utilização da APF esta normalizada em um manual de contagem de pontos de função da IFPUG (International Function Point Users Group) constituída em 1996.

Obs: O chapter do IFPUG no Brasil é o BFPUG – Brazilian Function Point Users Group. (Constituído em 1998)

O esquema do processo de contagem de pontos por função é dado na figura abaixo:

Para que você tenha uma idéia dos PF como medida de volume de software abaixo é apresentada uma tabela que mostra o tamanho aproximado de algumas aplicações tipos em pontos por função.[2]

Eu não vou dar detalhes sobre como usar o manual de contagem mas vou dar um exemplo de como você pode usar o resultado obtido usando a APF para estimar esforço , prazo e custo de um software.

Vamos supor que você foi consultado sobre o desenvolvimento de um sistema cadastro de clientes onde é possível realizar as seguintes tarefas:

• Listagem por ordem alfabética
• exportar o cadastro para outro sistema via arquivo texto

Usando o manual de contagem da APF teríamos:

ALI – 01 ( o arquivo de clientes )
AIE – 0
EE – 01 ( inclusão de cliente )
SE – 01 ( listagem por ordem alfabética )
CE – 01 ( exportar arquivo texto)

Se considerarmos todos os tipos de função como de complexidade Baixa teremos:

Pontos de função Brutos não ajustados :

PFB = ALI x 7 + AIE x 5 + EE x 3 + SE x 4 + CE x 3 = 1 x 7 + 0 x 5 + 1 x 3 + 1 x 4 + 1 x 3 = 17

Contando os fatores de ajustes teremos um total igual a 45.

Valor de fator de ajuste :

VFA = 0,65 + (0,001 x 45 ) = 1.1

Valor dos pontos de função Ajustados:

PFA = VFA x PFB = 1,1 x 17 = 18,7

Pronto!

Usando APF chegamos ao tamanho do sistema.

O seu tamanho é 18,7 pontos por função.

E agora ?

Nota: Dizer que o tamanho de um projeto é de 1000 PF nada significa. Quando podemos comparar medidas feitas em APF é que as coisas começam a fazer sentido. Assim se temos dois projetos , um com 1000 PF e outro com 2000 PF, podemos concluir que o segundo temo o dobro do tamanho do primeiro.

Assim como dizer que uma construção possui 400 metros quadrados de área construída não nos permite estimar , apenas levando em conta esta medida , valor da mesma; dizer que um projeto possui 3000 PF também não nos dá a idéia do custo do projeto.

Agora podemos estimar esforço , prazo e custo. Para isto iremos usar as seguintes considerações:

1- Considerando que uma produtividade média de 10 hs / PF.

2- Considerando que a média de jornada de trabalho é de 6 horas.

3- Considerando que o valor de uma hora de trabalho é de R$ 25,00.

Concluímos que :

Esforço = 10hs / PF = 10 x 18,7 = 187 horas
Prazo = 187 h / ( 4 x 6 ) = 7,8 dias
Custo = 187 h x R$ 25,00 = R$ 4.675,00

Foram usadas as seguintes fórmulas:

Produtividade no desenvolvimento = Horas por PF
Esforço de desenvolvimento = Produtividade(H/PF) * Tamanho(PF)
Custo de software = Tamanho (PF) * Custo(R$/PF)

Neste artigo procurei abordar de forma simples e objetiva a importância da utilização de métricas no desenvolvimento de projetos software com a finalidade de realizar estimativas.

A métrica de software e suas implicações é um assunto muito vasto que você poderá pesquisar nos links dos sites indicados e também em:

NESMA – http://www.nesma.nl/english/nesma&ifpug.htm
COCOMO – http://www1.jsc.nasa.gov/bu2/COCOMO.html
FATHO – http://www.fattocs.com.br/
Aplicativo para auxiliar na contagem APF – http://www.bsb.netium.com.br/mecenas/apf.htm

Por enquanto lembre-se sempre que :

“Se você não sabe para onde deseja ir , um mapa não vai lhe ajudar.”

Referências

[1] – DeMarco, Tom – Controle de projetos de Software – Editora Campus, 1991.
[2] – Jones, Capers – Estimating Sofware Costs – McGraw-Hill, 1998. Veja também www.spr.com site da empresa do autor.