Métricas de processo e projeto de software

Transcrição

1 Métricas de processo e projeto de software Métrica é um conjunto de medidas. Medição existe em qualquer processo de construção de qualquer coisa. A medição é realizada não apenas na Engenharia de Software. É fundamental para qualquer atividade, principalmente de engenharia. Seu propósito é avaliar alguma coisa. A partir dela, podemos ter o entendimento da eficácia de algumas situações, como do processo de software. Por exemplo, para avaliar se o processo pelo qual uma empresa produz software é bom ou ruim, como se faz? O CMM é um modelo para avaliar a qualidade do processo. Ele se baseia em medidas como tempo, número de erros, de linhas de código, de manutenções, etc., para saber se o processo está funcionando bem. Não é possível avaliar algo sem alguma medição. Os processos que estão no nível máximo do CMM têm um melhoramento contínuo, o que significa que eles são constantemente medidos. As métricas são aqui quantitativas (números). Medidas de qualidade e medidas de produtividade são extraídas do processo de software. A medição, além de ajudar na avaliação do processo de software, ajuda ainda nas estimativas, por exemplo, para estimar quanto tempo é necessário para a produção de um sistema. Atualmente erra-se muito nessas estimativas por não se ter muito conhecimento ou medição do processo. Com a medição, aperfeiçoamentos reais podem ser conseguidos ao longo do tempo. Então, as razões para medir processos, produtos e recursos de software podem ser:

2 para caracterizar; para avaliar; para prever; para aperfeiçoar. Um engenheiro de software realiza medidas e desenvolve métricas de modo a obter indicadores. Medida é um valor real, quantidade, dimensão, capacidade ou tamanho de algum atributo. Ex. número de erros encontrados. Métrica é um conjunto de medidas tentando obter algum sentido. Ex. erros encontrados por pessoa-hora empregada. Traz alguma informação que pode ser útil. Indicador é uma métrica, ou conjunto de métricas, que fornece compreensão de um processo de software, de um projeto de software ou do produto propriamente dito. Ex. comparando duas métricas, chega-se a uma conclusão que permite embasar uma tomada de decisão. Exemplos 1. O que é medida, métrica e indicador? Vide acima. 2. Defina duas medidas, uma métrica e um indicador para avaliar um carro. Medidas: potência, peso bruto; Métrica: potência por peso bruto; Indicador: comparando-se a potência por peso bruto de dois carros, pode-se concluir qual é mais veloz. 3. O que são métricas do processo? E do projeto? Qual a principal diferença entre elas? Métricas do processo e do projeto de software são medidas

3 quantitativas que permitem ao pessoal de software ter idéia da eficácia do processo de software. Indicadores de projeto permitem à organização de engenharia de software ter idéia da eficácia de um determinado processo existente, enquanto os indicadores de processo tentam identificar problemas que atingem a produção de todos os projetos na empresa. Métricas de Processo e Projeto de Software A medição é fundamental para qualquer atividade de engenharia. A medição nos permite obter entendimento nos dando um mecanismo para avaliação objetiva. A medição pode ser aplicada ao processo de software, com o objetivo de melhorá-lo continuamente. Métricas do processo e do projeto de software são medidas quantitativasque permite ao pessoal de software ter idéia da eficácia do processo de software. Dados básicos de qualidade e de produtividade são coletados. Com medições, as tendências (boas ou más) podem ser detectadas, melhores estimativas podem ser feitas e aperfeiçoamentos reais podem ser conseguidos ao longo do tempo. Há quatro razões para medir processos, produtos e recursos de software: para caracterizar, para avaliar, para prever ou para aperfeiçoar. Medidas, Métricas e Indicadores Uma medida fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto, ou de um processo. A IEEE define métricas como medida quantitativa de grau em que um sistema, componente ou processo possui um determinado atributo.

4 Quando dados de um único ponto são coletados (por exemplo, quantidade de erros descobertos na revisão de um único módulo, pessoas-horas gastas na revisão de um único módulo, etc ), uma medida é estabelecida. Um medição ocorre como resultado da coleta de um ou mais pontos. Uma métrica de software relaciona as medidas individuais de alguma forma (por exemplo, um número médio de erros encontrados por revisão ou um número médio de erros encontrados por pessoahora, emprega nas revisões). Um engenheiro de software realiza medidas e desenvolve métricas de modo a obter indicadores. Um indicador é uma métrica, ou combinação de métricas, que fornece compreensão de um processo de software, de um projeto de software, ou do produto propriamente dito. Exemplo: Quatro equipes de software estão trabalhando em um grande projeto de software. Cada equipe precisa conduzir revisões de projeto, mas pode selecionar o tipo de revisão que irá usar. Pelo exame da métrica, erros encontrados por pessoa-hora empregada, o gerente de projeto nota que duas equipes que estão usando métodos de revisão mais formais, exibem um valor para os erros encontrados por pessoa-hora empregada, que é 40% maior do que o valor das outras equipes. Considerando todos os outros parâmetros iguais, isso, para o gerente de projeto, é um indicador de que os métodos de revisões formais podem fornecer um retorno maior do investimento em tempo que outra abordagem de revisão menos formal. Este pode, então, decidir sugerir que todas as equipes usem a abordagem menos formal. A métrica pode fornecer compreensão ao gerente de um projeto. E compreensão leva a uma tomada de decisão mais

5 precisa. A medição é comum no mundo da engenharia. Medimos consumo de energia, peso, dimensões físicas, temperatura, voltagem, relação entre sinal e ruído.. Na engenharia de software a medição é muito menos comum temos dificuldade em concordar quanto ao que medir e dificuldade em avaliar as medidas que são coletadas. Métricas devem ser coletadas de modo que os indicadores de processo e de produto possam ser determinados. Métricas de Processo Indicadores de processo permitem à organização de engenharia de software ter idéia da eficácia de um processo existente. Elas permitem aos gerentes e profissionais avaliarem o que funciona e o que não funciona. Métricas de processo são coletadas ao longo de todos os projetos e durante longos períodos. Seu objetivo é fornecer indicadores que levem ao aperfeiçoamento do processo de software a longo prazo. Métricas de Projeto Indicadores de Projeto permitem ao gerente de projeto de software: 1. Avaliar o status de um projeto em andamento; 2. Acompanhar riscos potenciais; 3. Descobrir áreas-problemas antes que elas se tornem críticas; 4. Ajustar o fluxo de trabalho ou tarefas; 5. Avaliar a capacidade da equipe de projeto e controlar a qualidade dos produtos do trabalho de software. Em alguns casos, as mesmas métricas de software podem ser usadas para determinar indicadores de projeto e de

6 processo de software. Métricas de Processo e aperfeiçoamento do processo de software Medimos a eficácia de um processo de software indiretamente originamos um conjunto de métricas, baseadas nas saídas que podem ser derivadas do processo. As saídas incluem medidas de erros descobertos antes da entrega do software, defeitos entregues aos usuários finais e por ele relatados, produtividade dos produtos de trabalho entregues, esforço humano despendido, tempo gasto, cumprimento de cronograma e outras medidas. Algumas dessas medidas, tais como defeitos entregues aos usuários finais, só podem ser utilizadas para avaliar o processo, enquanto que outras, tais como erros descobertos antes da entrega do software, podem ser utilizados para avaliar tanto o processo quanto um projeto em específico. As métricas de processo de software podem fornecer benefícios significativos, à medida que a organização trabalha para aperfeiçoar seu nível gerencial de maturidade de processo. Todavia, essas métricas podem ser mal utilizadas, criando mais problemas do que conseguem resolver. Grady (1992) sugere uma etiqueta de métricas de software, que é apropriada tanto para os gerentes quanto para os profissionais, quando eles instituem um programa de métricas de processo: Use bom senso e sensibilidade empresarial quando interpretar dados de métricas. Forneça regularmente realimentação aos indivíduos e equipes

7 que coletam medidas e métricas. Não use métricas para avaliar indivíduos. Trabalhe com profissionais e equipes para estabelecer metas claras e métricas que devem ser usadas para alcançá-las. Nunca use métricas para ameaçar indivíduos ou equipes. Dados de métricas que indicam uma área problemática não devem ser considerados negativos. Esses dados são meramente um indicador para melhoria do processo. Não fique obcecado com uma única métrica em detrimento de outras métricas importantes. À medida que uma organização sente-se mais confortável, coletando e usando métricas de processo, a derivação de indicadores simples dá lugar a uma abordagem mais rigorosa, chamada melhoria estatística de processo de software statistical software process improvement (SSPI). A SSPI usa a análise de falhas de software para coletar informação sobre todos os erros e defeitos encontrados à medida em que uma aplicação, sistema ou produto é desenvolvido e usado. Erro falha num produto de trabalho de engenharia de software, ou resultado a ser produzido, que é encontrado por engenheiros de software antes do software ser entregue ao usuário final. Defeito falha encontrada depois da entrega ao usuário final. A análise de falhas funciona da seguinte maneira: 1. Todos os erros e defeitos são categorizados por origem (por exemplo: falha na especificação, falha de lógica, não atendimento à padrões) 2. O custo para corrigir cada erro e defeito é registrado. 3. A quantidade de erros e defeitos de cada categoria é contada e ordenada de forma decrescente. 4. O custo total de erros e defeitos de cada categoria é

8 calculado. 5. Os dados resultantes são analisados, para descobrir as categorias que produzem um maior custo para a organização. 6. São desenvolvidos planos para modificar o processo, com o objetivo de eliminar (ou reduzir a frequência das) classes de erros e defeitos que são mais dispendiosas. Métricas de Projeto Métricas de processo de software são usadas com finalidade estratégica. Medidas de projeto de software são táticas métricas de projeto e indicadores derivados delas são usados por um gerente de projeto e por uma equipe de software, para adaptar o fluxo de trabalho e as atividades técnicas do projeto. A primeira aplicação das métricas de projeto, na maioria dos projetos de software, ocorre durante as estimativas. Métricas coletadas de projetos anteriores são usadas como base, a partir da qual as estimativas de esforço e de tempo são feitas para o trabalho atual de software. À medida que o projeto prossegue, medidas de esforço e de tempo despendidos são comparadas com as estimativas originais o gerente de projeto usa esses dados para monitorar e controlar o progresso. À medida que o trabalho técnico se inicia, outras métricas de projeto começam a ter importância, como: Taxa de produção representada em termos de páginas de documentação, horas de revisão, pontos-por-função e linhas de código fonte entregue. O objetivo das métricas de projeto é duplo: Primeiro essas métricas são usadas para minimizar o

9 cronograma de desenvolvimento, fazendo os ajustes necessários para evitar atrasos e problemas, e riscos em potencial. Métricas de projeto são usadas para avaliar a qualidade do produto durante sua evolução e, quando necessário modificar a abordagem técnica para aperfeiçoar a qualidade. À medida que a qualidade é aperfeiçoada, os defeitos são minimizados, e, à medida que a contagem de defeitos decresce, a quantidade de retrabalho durante o projeto é também reduzida. Isto leva à diminuição do custo total do projeto. Métricas Orientadas ao Tamanho Métricas orientadas ao tamanho são originadas pela normalização das medidas de qualidade e/ou produtividade, considerando o tamanho do software que foi produzido. Se uma organização de software mantém registros simples, uma tabela de medidas orientadas ao tamanho, pode ser criada. A tabela lista cada projeto de software desenvolvido e as correspondentes medidas daqueles projetos. Deve-se notar que o esforço e o custo registrados na tabela referem-se a todas as atividades de engenharia de software

10 (análise, projeto, codificação e teste), não apenas à codificação. Para o desenvolvimento de métricas foi escolhida uma medida base da tabela anterior LOC (Linhas de Código-Fonte) A partir dos dados rudimentares, contidos na tabela anterior, um conjunto de métricas simples orientadas a tamanho pode ser desenvolvido para cada projeto. Erros por KLOC (milhares de Linhas de Código Fonte); Defeitos por KLOC; R$ por LOC (estimado ); Páginas de documentação por KLOC; Adicionalmente, outras métricas interessantes podem ser calculadas: Erros por pessoa-mês; LOC por pessoa-mês; $ por página de documentação (estimado ); Métricas orientadas a tamanho não são universalmente aceitas como o melhor modo de medir o processo de desenvolvimento de software. A maior parte da controvérsia gira em torno do uso de linhas de código fonte como medidas-chave. Adeptos da medida de linhas de código fonte alegam que LOC é um artefato de todos os projetos de desenvolvimento de software, que pode ser facilmente contado e que muitos modelos de estimativa usam tal artefato. Por outro lado, os oponentes argumentam que as medidas de LOC: São dependentes da linguagem de programação. Penalizam programas curtos, mas bem projetados. Não podem acomodar facilmente linguagens não procedimentais e que seu uso na estimativa requer um

11 nível de detalhes que pode ser difícil de alcançar, ou seja, significa que o planejador deve estimar o LOC a ser produzido, muito antes que a análise e o projeto tenham sido completados. Métricas Orientadas a Função Métricas de software orientadas a função usam uma medida da funcionalidade entregue pela aplicação como valor da normalização. Como funcionalidade não pode ser medida diretamente, deve ser originada indiretamente usando outras medidas diretas. Métricas orientadas a função foram inicialmente propostas por Albrecht em 1979 que sugeriu uma medida chamada pontos-porfunção. Pontos-por-função derivadas a partir da contagem (direta) do domínio da informação do software e avaliação da complexidade do software. São calculados completando a tabela apresentada a seguir. Cinco características do domínio da informação são determinadas e as contagens são registradas nos lugares próprios da tabela.

12 Quantidades de entradas do usuário cada entrada do usuário, que fornece dados distintos orientados à aplicação do software, é contada. Entradas devem ser distinguidas de consultas, que são contadas separadamente. Quantidade de saídas do usuário cada saída do usuário, que fornece informação orientada à aplicação para o usuário, é contada. Nesse contexto, saída refere-se a relatórios, telas, mensagens de erro, etc. Itens de dados individuais dentro de um relatório não são contados separadamente. Novas consultas do usuário uma consulta é definida como uma entrada on- line, que resulta na geração de alguma resposta imediata do software sob forma de saída on-line. Cada consulta distinta é contada. Quantidade de arquivos cada arquivo lógico (isto é, grupo de dados lógicos que pode ser parte de uma base de dados maior ou um arquivo separado) é contado. Quantidade de interfaces externas todas as interfaces que são usadas para transmitir informação a outro sistema, são contadas.

13 Uma vez coletados esses dados, um valor de complexidade é associado com cada contagem. Organizações que usam os métodos de pontos por função desenvolvem critérios para determinar se uma instância particular é simples, média ou complexa. No entanto, esta determinação é um tanto subjetiva. Para determinar os pontos por função é usada a seguinte relação: FP = contagem total X [0,65 + 0,01 X? (Fi)] Os Fi (i=1 a 14) são valores de ajuste de complexidade, baseados nas respostas às seguintes perguntas: O sistema requer salvamento (backup) e recuperação (recovery) Comunicações de dados são necessárias? Há funções de processamento distribuídas? O desempenho é crítico? O sistema vai ser executado em um ambiente operacional existente, intensivamente utilizado? O sistema requer entrada de dados on-line? A entrada de dados on-line, exige que a transação de entrada seja construída através de várias telas ou operações? Os arquivos mestre são atualizados on-line? As entradas, saídas, arquivos ou consultas são complexas? O processamento interno é complexo? O código é projetado para se reusado? A conversão e a instalação estão incluídas? O sistema está projetado para instalações múltiplas em diferentes organizações? A aplicação está projetada para facilitar modificações e para facilidade de uso pelo usuário? Cada uma destas questões é respondida usando uma escala que

14 varia entre: 0 não importante e não aplicável 5 absolutamente essencial Os valores na equação e os fatores de peso da tabela, foram determinados empiricamente. Uma vez calculados, os pontos por função são usados de modo análogo à LOC, como forma de normalizar medidas de produtividade, qualidade e outros atributos de software. Tais como: Erros por FP Defeitos por FP $ por FP Páginas de documentação por FP FP por mês. Fonte: ii/04_metricas_de_processo_e_projeto_de_software.pdf Balanced Scorecard: Projetando o futuro através de indicadores de desempenho Em meados de 1990 diversas organizações perceberam que os atuais métodos de mensuração de resultados que utilizavam já não eram suficientes para acompanhar a grande mudança que se iniciara no mercado mundial. Os sistemas de gestão já não se mostravam capazes de acompanhar a intensa influência da globalização, que trouxe consigo a universalização da informação através da tecnologia. O Balanced Scorecard permite

15 que a empresa gerencie equilibradamente o desempenho de suas atividades através das quatro perspectivas básicas: financeira, do cliente, dos processos internos e do aprendizado e crescimento. As empresas estão a meio caminho de uma transformação revolucionária. A competição da era industrial está se transformando na competição da era da informação. (KAPLAN & NORTON, A Estratégia em Ação, 17ª Edição) Um novo ambiente operacional começou a ser propagado entre as unidades de negócio interessadas em adentrar essa nova era mercadológica, onde os pressupostos pregados anteriormente foram totalmente reformulados por estratégias competitivas de inovação, relacionamento e revisão de processos. O processo de implantação do BSC tem início e base na tradução das estratégias da empresa (visão e missão) em objetivos estratégicos que possam ser concretizados por todos os componentes. É um processo em top-down que tem por objetivo desmistificar a premissa de que as estratégias da unidade de negócios são incompreensíveis se divulgadas fora da alta cúpula de gestão. O Balanced Scorecard dispõe da possibilidade de se identificar os pontos críticos da unidade de negócios que necessitam de reformulação devido sua capacidade de atingir todos os níveis operacionais da organização. O ensejo dos gestores de unidades de negócio é receber um feedback quase instantâneo e preciso sobre as atividades realizadas e sobre as decisões tomadas, possibilidade esta encontrada na proposta do BSC, que permite que estes monitorem e efetuem mudanças em suas estratégias a qualquer momento. A perspectiva financeira do BSC não visa abolir os antigos métodos de mensuração do desempenho de uma unidade de negócios, como dito anteriormente, mas atribui a estes métodos a possibilidade e alinhamento dos mesmos à estratégia da empresa já desmistificada, possibilitando o planejamento mais conciso a longo prazo. Os vetores de análise da perspectiva

16 financeira são de tamanha importância que todos os vetores de outras perspectivas devem estar atrelados à primeira, pois somente esta permite a projeção palpável do retorno esperado por cada decisão estratégica. Assim sendo, esse atrelamento das demais perspectivas à financeira é essencial, pois todas as decisões tomadas através das perspectivas do cliente, dos processos internos e do aprendizado e crescimento culminarão nos resultados obtidos pelo desempenho financeiro da unidade de negócios. Na grande maioria das organizações, temas financeiros como aumento de receita, melhoria de custos e da produtividade, incremento da utilização dos ativos e redução dos riscos servem de base para integrar as quatro perspectivas do scorecard. (KAPLAN & NORTON, A Estratégia em Ação, 17ª Edição) As estratégias de perspectiva financeira do BSC atuarão na unidade de negócios proporcionando aos gestores a possibilidade de reformular seus métodos de aplicação da receita através de novas aplicações, busca de novos clientes e mercados, estreitamento dos relacionamentos, investimentos em um novo mix de produtos e serviços e nas estratégias de preços. Não somente no que tange a aumento e dinamização de recursos, a perspectiva financeira se mostra eficaz na redução de custos e despesas operacionais, porém, vale lembrar que o Balanced Scorecard não se trata de um sistema de gestão e sim uma eficaz ferramenta de controle e feedback para auxiliar não somente gestores, mas a organização como um todo a atingir os objetivos propostos em suas estratégias. A perspectiva dos clientes consiste na identificação dos segmentos de mercado nos quais a unidade de negócios deseja competir. Tem como preceitos básicos os investimentos em satisfação, fidelidade, retenção, captação e lucratividade. Outrora as empresas dedicavam seus esforços em dinamizar suas capacidades internas, o que ao longo do tempo se tornou uma estratégia de pouco aproveitamento, visto que seus

17 concorrentes já identificavam que o caminho mais correto era oferecer produtos e serviços alinhados às expectativas de seu mercado consumidor, ou seja, ao longo dos anos os produtos e serviços oferecidos têm sido cada vez mais individualizados de acordo com as necessidades de cada mercado-alvo. A proposta do BSC é a segmentação de mercado de forma a identificar os nichos potenciais de clientes nos quais a empresa deseja atuar, ou seja, mais uma vez traduzir a missão e a visão da unidade de negócios em alvos objetivos e focados. Em geral, os clientes atuais e potenciais não são homogêneos. Têm preferências diversas e valorizam os atributos dos produtos ou serviços de formas diferentes. O processo de formulação estratégica, utilizando a pesquisa de mercado em profundidade, pode revelar os diferentes segmentos de mercado ou clientes e suas preferências, juntamente com dimensões de preço, qualidade, funcionalidade, imagem, reputação, relacionamento e serviço. (KAPLAN & NORTON, A Estratégia em Ação, 17ª Edição) A perspectiva dos processos internos se resume em identificar dentro da unidade de negócios os processos mais críticos que carecem de reformulação e, geralmente tende a ser uma fase subseqüente às demais perspectivas apresentadas anteriormente. A principal diferença entre o scorecard e os demais sistemas de mensuração de desempenho é que os últimos em seu bojo visam o controle departamental, enquanto que o BSC se concentra diretamente nos processos. Durante a reformulação dos processos internos da unidade de negócios, cabe aos gestores devida atenção a três processos principais: inovação, operações e serviços de pós-vendas. Este três processos são interligados. Primeiramente a unidade de negócios pesquisa as necessidades expostas por seu mercado consumidor, criando assim os produtos ou serviços para atendêlos (processo de operação). Por fim tem-se o pós-vendas, que terá por objetivo avaliar a satisfação do cliente após o recebimento do produto ou serviço, fornecendo a ele todo

18 suporte necessário. Todo este processo consiste em buscar dentro da organização todos os processos críticos aos quais se deve atenção a fim de atender aos objetivos da alta administração e de segmentos específicos de mercado. Nesta perspectiva acoplam-se o controle operacional do tempo de atendimento e produção e a qualidade dos produtos ou serviços. Por fim tem-se a perspectiva do aprendizado e crescimento voltada para o ambiente interno da organização. Enquanto as demais perspectivas orientam os gestores no que deve ser feito para que a organização se destaque e seja excepcional em seu segmento de mercado, a perspectiva de aprendizado e crescimento preparará o ambiente interno da empresa para atender às demais perspectivas. O BSC preocupa-se em não somente alinhar as estratégias da unidade de negócios ao seu segmento de clientes e às tendências que o mercado impõe dia a dia. Ele também proporciona aos gestores uma análise profunda do ambiente interno da empresa, no que tange a pontos como capacidades dos funcionários, capacidades dos sistemas de informação e motivação. No tocante às capacidades dos funcionários, percebe-se aqui um grande marco de modificações ao longo das eras. O melhor exemplo dessa mudança pode ser visto na passagem da era industrial para a era da informação, onde os colaboradores passaram a ser considerados como peça determinante do sucesso da unidade de negócios, e não como meros coadjuvantes produtivos e braçais. O objetivo de satisfação dos funcionários reconhece que o ânimo dos funcionários e a satisfação com o emprego são hoje aspectos considerados altamente importantes pela maioria das empresas. Funcionários satisfeitos são uma precondição para o aumento da produtividade, da capacidade de resposta, da qualidade e da melhoria do serviço aos clientes. (KAPLAN & NORTON, A Estratégia em Ação, 17ª Edição) O scorecard busca transmitir aos gestores um feedback de sua

19 força de trabalho analisando pontos específicos como o nível de satisfação dos funcionários, o percentual de retenção dos mesmos e também através do nível de produtividade. Muito além de funcionários plenamente capacitados e motivados, a organização necessita fornecer a estes as informações necessárias para o desenvolvimento conciso das demais perspectivas. Neste ponto destacam-se as capacidades dos sistemas de informação, que em sua performance precisam ser plenamente eficazes e úteis, fornecendo um feedback rápido e correto aos funcionários da linha de frente. Tão relevante quanto aos dois vetores apresentados anteriormente, não basta funcionários capacitados e sistemas de informação eficazes. Para o correto desenrolar da perspectiva de aprendizado e crescimento é necessário também um clima organizacional favorável, ou seja, colaboradores motivados e envolvidos com todas as estratégias da unidade de negócios. É de suma importância que os funcionários sintam-se envolvidos nos processos que o scorecard propõe, para que os mesmos se sintam motivados em auxiliar a unidade de negócios a cumprir cada processo proposto pelas quatro perspectivas. A base de um scorecard é formada pelas quatro perspectivas apresentadas anteriormente. Por si só, não passam de pura teoria. O detalhe mais importante na eficácia do BSC está no comprometimento da unidade de negócios como um todo na concretização de cada processo proposto pelo sistema. A principal tônica do Balanced Scorecard consiste em traduzir a missão e a visão da unidade de negócios em pequenas estratégias realizáveis por cada departamento, traduzindo os objetivos futuros para todos os funcionários. O scorecard se cogita como a ponte que liga o desenvolvimento e a formulação da estratégia e a sua implementação. A grande dificuldade das empresas atualmente é transformar suas metas e estratégias em ações palpáveis e realizáveis. O Balanced Scorecard traz em seu bojo essa proposta. Mais do que somente controlar, o BSC também pode ser utilizado

20 para alavancar as atividades da unidade de negócios através do estabelecimento de metas de superação para cada individuo envolvido no processo. É necessário enfatizar também que toda ação gerada pelo scorecard deve ser acompanhada de um feedback completo que possa oferecer aos gestores a possibilidade de alterações durante o percurso de desenvolvimento das estratégias. Diante do exposto, percebe-se que o Balanced Scorecard traz em seu bojo a premissa de ser uma eficaz ferramenta de comunicação de estratégias, de tradução da missão e visão da empresa a todos os funcionários e de projeção de metas através de uma profunda mensuração de resultados. Assim sendo, chegase à seguinte questão: sendo uma ferramenta tão promissora, por que grande parte das organizações da era atual ainda não a adotaram? Fonte: Site Administradores