Aumenta a quantidade de software mal projetado no mercado mundial, criando uma série de riscos para as organizações, revela relatório global que analisou 745 aplicações. Esses produtos apresentam problemas de programação que violam as boas práticas de arquitetura e de codificação, contribuindo para elevar o chamado débito técnico, que vem ganhando ampla atenção no mundo corporativo.

O termo débito técnico está sendo utilizado pelo mercado para definir a dívida que as equipes de desenvolvimento assumem quando escolhem uma metodologia mais fácil e rápida para criação de aplicativos. Esse tipo de abordagem pode comprometer a qualidade do software e trazer impacto para as companhias no longo prazo.

Os especialistas dizem que assim como o saldo negativo em banco exige pagamento com cobrança de juros, a dívida técnica também pode ter custo alto para as corporações. Uma hora ela precisa ser quitada com a correção das linhas dos códigos escritos errados.

A pesquisa das 745 aplicações foi realizada pela Cast Software, desenvolvedora de ferramentas que avalia a solidez de engenharia da arquitetura e codificação de um aplicativo. A empresa analisou programas de 160 companhias de aproximadamente 12 segmentos da economia.

Uma das conclusões do estudo é que o desenvolvimento de programas com códigos de má qualidade é muitas vezes resutado das decisões de negócios de cortar custos. Para reduzir os investimentos dos projetos, as companhias acabam contratando programadores sem muita habilidade.

Outro fator é a pressão em cima da equipe para que as aplicações sejam desenvolvidas rapidamente para cumprir o cronograma dos projetos. O reflexo são programas que causam falhas de sistemas, diminuem o desempenho dos computadores e abrem brecha de segurança para ataques, entre outros problemas.

Reparar as linhas de código depois que o software está pronto, além de custar muito causa problemas técnicos. Um exemplo histórico de débito técnico foi o “Bug de 2000”, quando muitas aplicações estavam prontas para interpretar os dígitos “00” na virada daquele ano como 1900.

Organizações em todo o mundo gastaram somas incalculáveis de dinheiro para corrigir os dois dígitos. Muitas das aplicações foram destruídas porque desenvolvedores sabiam que o erro surgiria eventualmente.

Custo da correção

A análise da Cast encontrou 1,8 mil tipos de falhas de desenvolvimento em aplicações escritas em Java EE, Cobol, .Net, C, C + + e outras linguagens de programação. A companhia estima que o custo médio para eliminar os bugs por linha de código é de 3,61 dólares. Esse cálculo se baseia no preço hora de 75 dólares cobrado nos Estados Unidos para correção de erros de software.

Outra constatação da pesquisa da Cast é que corrigir falhas de aplicativos desenvolvidos em Java custa mais. O preço para eliminar bugs desta tecnologia é de 5,42 doláres por linha de código, enquanto o mesmo trabalho na plataforma Cobol sai por 1,26 dólares.

Bill Curtis, cientista-chefe da Cast, explica que corrigir linhas de código de Cobol custa menos porque a linguagem é mais antiga e os programadores são mais experientes. Por estarem atuando há mais de 30 anos com nessa tecnologia, eles conseguem corrigir falhas críticas mais rapidamente.

Sobre Java, Curtis constata que há muitos profissionais iniciando agora o desenvolvimento nesta linguagem sem formação científica em computação. “Tem uma enorme quantidade de pessoas escrevendo código sem ser guru em engenharia de software”, percebe o executivo.

Implicações do débito técnico

O estudo da Cast reforça a necessidade de as companhia entenderem as implicações do débito técnico, informa Carolyn Seaman, professora adjunta de sistemas de informação da Universidade de Maryland, em Baltimore (EUA), e coordenadora de um programa da National Science Foundation sobre esse tema. De acordo com ela, o tema gera preocupação devido ao risco que pode trazer para os negócios.

O instituto de pesquisas Gartner estima que o débito técnico no mercado mundial subirá de 500 bilhões de dólares em 2010 para um trilhão de dólares em poucos anos. Para Carolyn diminuir essa dívida não é tarefa fácil. Ela considera que o maior obstáculo é a incerteza sobre adoção de técnicas de desenvolvimento e abordagens que realmente resultam em maior qualidade de software.

O crescimento do débito técnico está estimulando a criação de um guia de riscos para os negócio informa John Heintz, consultor técnico da Cutter Consortium. Ele diz que esse problema já está sendo tratado como uma questão de due diligence em fusões e aquisições, aumentando a consciência de que o tema está influenciando as práticas de desenvolvimento de software.

Na opinião de Heintz colocar mais atenção sobre o débito técnico não significa que os desenvolvedores não tenham de diminuir gastos para acelerar o desenvolvimento. “Às vezes é apropriado e necessário cortar custos, mas esse fato não pode ser ignorado”, disse ele.

O Software Engineering Institute (SEI) da Universidade Carnegie Mellon, centro de pesquisa financiados pelo pelo Departamento de Defesa dos EUA, está trabalhando a questão do débito técnicos há cerca de dois anos. A instituiçao vem organizando workshops sobre o tema, de acordo com Ipek Ozkaya, membro sênior da equipe técnica.

“Existe interesse crescente neste assunto porque empresas e desenvolvedores querem entender seus fundamentos”, afirma Ozkaya. Ele observa a falta de orientação sobre como fazer o levantamento dessa dívida e como quitá-la para evitar implicações futuras.

[Patrick Thibedeau da CIO.com USA]

O diagrama abaixo apresenta a estrutura do modelos de melhoria contínua de processos CMMI.

É possível identificar as ações voltadas à institucionalização, áreas de processo comuns, áreas de processos dos modelos CMMI-ACQ, CMMI-DEV e CMMI-SVC e por fila as metas e representações. É interessante notar que com a implementação do CMMI-DEV (mais comum), a jornada para outro modelo como o SVC fica mais fácil pois pode-se aproveita-se muito.

Em TI provavelmente não exista ninguém que nunca ouviu alguém falar esta frase. É incrível mas, raramente você ouve alguém falar que o trabalho do outro estava bom, seja uma especificação, um programa, arquitetura, enfim, qualquer coisa em TI.

Está frase “Estava tão ruim que eu tive que refazer” traz prejuízos enormes para a empresa, e se o gerente do projeto não ficar atento e coibir fortemente este comportamento, muito dinheiro estará sendo jogado no lixo.

Tempos atrás um amigo comentou o seguinte caso:

A empresa dele foi contratada para fazer um projeto e o mesmo foi iniciado pela área A, o custo do projeto era de 1 milhão, e após seis meses o projeto mudou para a equipe B. A nova equipe, falou que nada poderia ser aproveitado e teria que refazer tudo do zero (porque estava muito ruim). Não se sabe como mas acreditaram neste julgamento e a equipe começou a refazer o projeto (praticamente jogou tudo fora). Porém, o budget não era suficiente então a equipe negociou mais 1 milhão com o cliente. Quase um ano se passou e com a rotatividade alta, uma outra área entrou para ajudar no desenvolvimento. Adivinha o que foi falado dos módulos que eles iriam ajudar? Que “estava tão ruim que teria que refazer” e novamente foram negociar mais budget com o cliente, só que nesta hora o cliente deu um basta falando: “A cada seis meses vocês vêm dobrando o orçamento. Ou entrega com o que foi combinado ou sinto muito, mas teremos que parar este projeto e vocês terão que nos devolver o que já pagamos”.

Quem ganha com uma situação assim? Ninguém. E o pior de tudo é que a empresa perderá o cliente e a credibilidade. E tenha certeza que o menor culpado nesta história é o cliente.

Mas porque isto acontece? Podemos resumir em dois simples fatores: Falta de gestão e ego. O gerente do projeto está lá para entregar o projeto, ele deve mobilizar os envolvidos, comunicar e buscar atender os objetivos do projeto. Cada um no projeto tem suas responsabilidades, suas tarefas e tenho certeza que na EAP não terá nada dizendo “refazer o trabalho já feito”.

Agora vamos nos colocar no papel do cliente, imagine que você está construindo uma casa e após levantar as paredes da mesma o pedreiro sai e você precisa contratar outro. Este novo pedreiro decide derrubar tudo e reerguer novamente porque estava tão ruim que ele teve que refazer. O que você faria com este pedreiro? Quem vai pagar por este prejuízo (e desperdício)?

Assim como seu cliente, você também não ficou feliz com está situação. E agora… a situação parece mais aceitável certo?

Enfim, a sugestão que dou é: Trate duramente situações similares, não deixe as pessoas refazerem um trabalho simplesmente porque não foram elas que o criaram. É impossível que tudo esteja ruim sempre, e se isto está acontecendo em sua empresa, tenha certeza que além de estar jogando dinheiro fora, vocês estão perdendo uma ótima oportunidade de melhorar a rentabilidade de seus serviços.

Abraços e aproveitem o feriado prolongado

Cada vez que começo a arremessar as aves multicoloridas de encontro às estruturas milagrosamente robustas, constituídas de madeira, pedra e vidro (para mim aquilo é gelo), começo a pensar nos CIOs.

Eis os primeiros resultados de minha aproximação a la Professor Pardal e como, acredito, que esse jogo pode ajudar executivos no cumprimento de suas atribuições:

1. Para entender, é preciso jogar

A única maneira de aprender a passar de fase no Angry Birds é tentar. O mesmo acontece com a tecnologia. Ainda vejo vários casos de CIOs restringindo o acesso a sites de relacionamento digital ou distribuindo telefones diferentes por força da incompatibilidade entre a arquitetura da empresa ou por representar uma ameaça razoável aos dados corporativos e informações de clientes. É necessário que os CIOs entendam a necessidade de integrar as tecnologias emergentes em sua rotina. Podem aproveitar a oportunidade e permitir que os colaboradores usem seus dispositivos no contexto profissional. Dessa maneira as pessoas teriam maior entendimento acerca dos riscos e dos porquês das restrições.

2. O sucesso de cada um está no reconhecimento de seu talento

Cada um dos bichos com penas do Angry Birds tem um talento único. Tem aqueles brancos que ricocheteiam e soltam bombas; os amarelos, irados, que se arrebentam contra paredes depois de um turbo em pleno vôo; e os azuis, menores, que, uma vez no ar, assumem formação de esquadrão de caças para detonar o suposto vidro. Um verdadeiro CIO também deve ser um CTM (Chief Talent Manager – executivo gestor de talentos). Sua tarefa seria a de adequar o talento pessoal a cada necessidade específica da empresa.

Além disso, os CIOs/CTMs devem prever as atribuições futuras dos colaboradores para treiná-los adequadamente.

3. Começou mal? Volte

Não dê murros em ponta de faca. Bons jogadores de Angry Birds sabem, assim que o penoso abandona o conforto do estilingue, se o tiro será certeiro ou não. Quando sentem que não foi dessa vez, param e reiniciam a fase – uma maneira de evitar prejuízos, mesmo que seja “apenas” tempo.

Por força de algum mecanismo estranho, os CIOs se parecem muito com os experientes jogadores. CIOs percebem rapidamente quando algo não vai bem ou como era esperado. Mas lhes falta o pulso firme para interromper a miríade de ações de implantações de software e de alterações na TI em andamento. Sugere-se que sejam corajosos e cortem o mal pela raiz, antes do prejuízos que, diferentemente do jogo, vão muito além de “apenas” tempo.

4. Para cada problema, há um especialista

Para cada tipo de material existe uma ave apropriada, desenvolvida especificamente para dar conta do obstáculo. Essa relação fez do jogo algo muito interessante, e complexo.

Infelizmente tal clareza não é oferecida aos CIOs que precisam enfrentar obstáculos diferentes, alguns desconhecidos. Os dias em que uma dupla de programadores, refrigerantes e uma pizza gigante resolviam o problema da TI já eram. Hoje, áreas específicas, como a rede, interface de usuário e outras questões demandam por mão de obra especializada.

No Angry Birds não existe o recurso de outsourcing para dar conta de tarefas especiais. Por sorte, os CIOs têm essa opção.

5. Planeje e verifique a real necessidade

Em seu universo próprio, com leis da física exclusivas, é necessário um pouco de experiência antes de gastar a munição voadora. Às vezes, arremessar um daqueles pássaros negros que explodem perto de uma muralha não trará o resultado esperado. O mesmo vale para os CIOs que, antes de realizar enormes modificações empresa afora, precisam verificar a viabilidade – inclusive política – das alterações.

Isso me lembra um caso de vários anos. Era época de migrar de servidor de emails e as horas de conversa resultaram em compromissos que jamais foram cumpridos. Para a modernização acontecer, foi necessário que o CIO fosse pressionado e pusesse as mãos na massa. Mandou uma mensagem aos seus subordinados, em que ameaçava cortar a comunicação caso insistissem em permanecer com o serviço de email antigo. Fica a lição: use suas armas de CIO na hora de fazer e de acontecer.

6. Melhorias requerem aperfeiçoamento

Conseguir um score mais alto em Angry Birds é tarefa árdua. Vez por outra, você descobre um macete, um jeito diferente de vencer os obstáculos e de bater seu recorde anterior. Mesmo assim, tais descobertas são uma raridade. À medida que as fases vão fiando mais difíceis, o ciclo de aprendizado se repete e, novamente, quebrar o recorde anterior é um desafio.

Depois de extenuantes experimentos científicos chego à conclusão que os CIOs devem se acostumar ao fato de que equipes de alto rendimento demoram mais para superar os resultados anteriormente atingidos. A mesma regra vale para a satisfação de clientes e para plataformas. Mas tal realidade não deve tolher a busca por constantes melhorias.

Assim que houver mais um salto qualitativo, ele será surpreendente e trará excelentes resultados. Manter o foco em táticas, sem deixar de lado as estratégias e a humildade para reconhecer que é hora de parar, são essenciais.

7. As tarefas mudam

Todas as diferentes configurações dos obstáculos no Angry Birds em uma mesma fase têm uma característica em comum. Logo, ser bom em um tipo de ambiente não o qualifica como mestre do jogo.

Conforme mencionamos há pouco, A a TI está cercada por ambientes que requerem habilidades especiais.

No caso dos CIOs, tal circunstância demanda por uma equipe que tenha seus mestres em cada área, alguns deles, em condições de completar tarefas que você, como líder, não tem aptidão para resolver. Nessa hora, quando surgem obstáculos estranhos e intimidadores, o bom CIO escolhe entre capacitar a equipe a ponto dela poder dar conta da tarefa ou chamar um colaborador externo. Antes disso, porém, verifique com os integrantes da equipe o que o novo cenário traz e como podem se preparar para a próxima mudança.

8. Existe mais de uma forma de ganhar o jogo

Escolher entre um daqueles tiros super verticais ou tentar um arremesso em ângulo menor? Esse raciocínio passa pela cabeça de cada jogador. Ficar refém de uma tática apenas pode conduzir o jogador à loucura, além de mantê-lo preso a uma série de tentativas frustradas.

CIOs devem manter uma mente aberta às alternativas de ataque para cada circunstância. Saber ouvir sugestões sobre como tecnologias emergentes podem acelerar processos e agregar valor ao negócio.

Tomar sempre o caminho conhecido é uma atitude segura, porém altamente limitante. Se o objetivo do jogo for vencer, e não conheço nenhum jogo com objetivo diferente desse, é necessário enfrentar riscos. Essa aptidão de ir em encontro ao desconhecido é, muitas vezes, uma vantagem competitiva, ao passo que pode ser uma loucura. Ao CIO cabe reconhecer a diferença entre risco calculado e irresponsabilidade. Se optar pelo primeiro e suceder, terá dado um passo importante em direção à verdadeira liderança.

[Daniel Rasmus, CIO/EUA]

Recebemos muitos emails com perguntas como:

“Meu consultor CMMI falou que eu tenho que fazer isso, desse jeito porque o CMMI pede que seja feito”

“O consultor falou que isso deve ser feito assim porque o CMMI pede”

“Segundo a consultoria MPS.Br temos que fazer desse jeito porque o MPS.Br pede”

Bom… a recomendação que damos é: “Desconfie quando alguém falar: Isso tem que ser assim porque o modelo pede”. O consultor DEVE explicar o valor, porque e quais os benefícios. Vamos lembrar novamente, tanto o CMMI quanto o MPS.Br não definem a forma de como as coisas devem ser feitas. Ambos definem recomendações das melhores práticas de mercado, e estas práticas podem ser atendidas das mais diferentes formas.

Simplificando um pouco, na área de processos de Planejamento de Projetos (PP), temos que realizar o planejamento do projeto e produtos de trabalho, mas não diz como isto deve ser feito. Você realizar o planejamento em doc, em um sistema, escrevendo em um papel, enfim… da forma que você achar melhor, da forma que melhor atender seu negócio.

Os consultores de programas de melhoria de processos devem ter profundos conhecimentos (e normalmente tem) dos modelos e de suas práticas, estes devem ajudar seus clientes a compreender seus benefícios.

Pegando outro exemplo, a área de processo DAR (Análise de Decisão) normalmente é a mais incompreendida, a maioria das pessoas com quem converso não entende pra que serve está área de processos. E ela é realmente bem confusa. Costumo comentar que todo mundo realiza este processo no seu dia-a-dia, só que realiza de forma informal e nem sabe que realiza. Fazemos uma análise semelhante à solicitada em DAR quando por exemplo queremos comprar uma TV, um carro, escolher um serviço e outros. Isto porque definimos opções, definimos o que é mais importante para nós e fazemos uma avaliação de qual será a melhor opção.

Fica a dica: desconfie de frases como “o modelo pede”. Peça que explique o “porque”

Independentemente do quanto um projeto de TI possa ter sido bem planejado, é importante perceber que algumas vezes ele é cancelado por razões que fogem ao controle da equipe envolvida. Mas, com exceção de mudanças na gerência ou ainda nas prioridades da empresa, é possível mapear o que não pode dar errado de jeito algum.

Quando a implantação de um projeto de CRM (gerenciamento do relacionamento com o cliente), ERP, CMS (sistema de gestão de conteúdo) se mostra como um grande fiasco, imediatamente é possível detectar falhas de comunicação, problemas relacionados à política interna, atrasos ou até mesmo erros fatais de estimativa de custos.

Diante da inexistência de um único culpado, buscamos analisar todas as variáveis envolvidas. Geralmente, ao fazer perguntas básicas como ‘quem’, ‘o quê’, ‘quando’, ‘onde’ e ‘por quê’, encontramos um meio de começar a investigar as causas do problema.

Entre os requisitos básicos e fatores ambientais necessários para o sucesso de um projeto, pode acontecer um erro minúsculo cometido no início do projeto, e que passou despercebido durante  todo o tempo de desenvolvimento e se transformou em uma bola de neve gigantesca e avassaladora tempo depois.

Um exemplo disso é constatar, já com o projeto implantado, que os colaboradores da empresa não têm instrução suficiente para maximizar o uso de todas as ferramentas disponíveis.

Há quem garanta que para um projeto ser bem-sucedido basta caprichar no planejamento. Trata-se de uma verdade parcial, pois, além da falta de planejamento, é possível elencar outros quatro erros relevantes:

Falhas na metodologia do projeto

Um bom exemplo de como ter um mapa preciso do trajeto que se quer percorrer pode fazer toda a diferença numa viagem. Porque será que  inventaram o GPS? E com relação aos projetos não é diferente, ou estabelecemos todos os itens necessários ao planejamento, desenvolvimento e implementação, ou ficaremos andando em círculos, sem chegar a lugar algum.

Falta de envolvimento dos usuários

Uma das piores coisas que pode acontecer é ouvir de um usuário: “Nós não pedimos isso” ou “Isso está longe de atender às nossas necessidades”. Claro que toda novidade exige um tempo de aculturação, afinal, o que “se fazia de um jeito” passará a ser feito “de outro jeito”, com melhores resultados.

Mas, vencendo a resistência natural dentro das empresas, o projeto tem de atender às expectativas dos usuários.
O problema acontece quando a equipe responsável pelo projeto simplesmente se esquece de envolver pessoas dos mais diversos departamentos, na tentativa de encontrar um eixo de trabalho em comum.

Falta de apoio da alta diretoria

Nesse cenário em que as pessoas tendem a resistir ao que é novo e demanda um mínimo conhecimento tecnológico, será muito mais fácil conquistar o apoio dos colaboradores que vão fazer uso constante das soluções implementadas se pudermos contar com o apoio e o envolvimento dos chefes.

Isso garante mais credibilidade.

Erro no dimensionamento do projeto

Um projeto deve ser visto como uma conquista coletiva, não o feito de uma pessoa só, portanto, não adianta querer abraçar o mundo com as mãos, porque vai sobrar mundo.

É essencial mapear as necessidades da empresa e alinhar o que é possível fazer com os pré-requisitos que se tem em mãos.

Projetos superdimensionados perdem a credibilidade logo de saída e raras são as vezes que são concluídos com sucesso. Algo semelhante acontece também quando são subdimensionados.

[Adaptação do texto de Adriano Filadoro, sócio e diretor de tecnologia da Online Brasil - baguete.com.br]

Você sabe qual CMMI usar? Aliás, você sabia que existe mais de um?

A maioria das pessoas conhece apenas o CMMI para desenvolvimento, e há até pouco tempo existia apenas este CMMI mesmo, todavia, algo não estava certo. Empresas de serviços e outsourcing tentavam usar o CMMI para desenvolvimento em seus serviços e isto não se encaixava. Da mesma forma, compradores tentavam usar o CMMI-DEV para gerenciar os trabalhos de seus fornecedores, e, novamente as coisas não encaixaram.

O SEI percebeu estas situações e resolveu melhorar o modelo criando uma versão para serviços e outra para aquisições. Para estes dois novos CMMIs foram criadas novas áreas de processo, específicas e focadas. E com isso criou-se um conjunto de áreas de processo “core”, um conjunto para desenvolvimento, um conjunto para aquisições e por último mais um conjunto para serviços e você pode como isso ficou na imagem abaixo:

As áreas de processo “core” são:

• CAR: Causal Analysis and Resolution
• CM: Configuration Management
• DAR: Decision Analysis and Resolution
• MA: Measurement and Analysis
• OPD: Organizational Process Definition
• OPF: Organizational Process Focus
• OPM: Organizational Performance Management
• OPP: Organizational Process Performance
• OT: Organizational Training
• PPQA: Process and Product Quality Assurance
• REQM: Requirements Management
• RSKM: Risk Management

As áreas de processo focadas no CMMI-DEV são:

• IPM: Integrated Project Management
• PI: Product Integration
• PMC: Project Monitoring and Control
• PP: Project Planning
• QPM: Quantitative Project Management
• RD: Requirements Development
• SAM: Supplier Agreement Management
• TS: Technical Solution
• VAL: Validation
• VER: Verification

As áreas de processo do CMMI-ACQ são:

• AM: Agreement Management
• ARD: Acquisition Requirements Development
• ATM: Acquisition Technical Management
• AVAL: Acquisition Validation
• AVER: Acquisition Verification
• IPM: Integrated Project Management
• PMC: Project Monitoring and Control
• PP: Project Planning
• QPM: Quantitative Project Management
• SSAD: Solicitation and Supplier Agreement Development

E por último, as áreas de processo do CMMI-SVC são:

• CAM: Capacity and Availability Management
• IRP: Incident Resolution and Prevention
• IWM: Integrated Work Management
• QWM: Quantitative Work Management
• SAM: Supplier Agreement Management
• SCON: Service Continuity
• SD: Service Delivery
• SSD: Service System Development
• SST: Service System Transition
• STSM: Strategic Service Management
• WMC: Work Monitoring and Control
• WP: Work Planning

Hoje a maioria das implementações CMMI são focadas no CMMI-DEV. Como a maior parte dos contratos de TI são Outsourcing, podemos dizer que o modelo mais apropriado para estas empresas deveria ser o CMMI-SVC e não o CMMI-DEV.

Vamos imaginar o seguinte cenário. Você cuida da área de codificação e constantemente sua equipe reclama que as especificações vêm mal feitas. Por outro lado, a equipe de testes também reclama que os códigos possuem muitos erros. O que fazer?

Considere a implementação de critérios de entrada e critérios de saída.

Uma das reclamações mais comuns dos programadores é que as especificações estão incompletas, em casos assim, uma boa sugestão é reunir a equipe de desenvolvimento e pedir que definam o que seria uma boa especificação. Com base nesta definição, criamos uma lista de critérios que toda especificação deve ter (ou pelo menos a maioria), e um programa não deve ser aceito sem os insumos necessários. Você pode por exemplo pedir que toda especificação venha com pelo menos:

• Especificação técnica
• Protótipo de tela
• Dados exemplos
• Casos de testes
• Pelo menos 5 cenários de testes

Este exemplo apesar de simples, pode resolver horas de retrabalho desnecessário e após um certo tempo, a equipe de desenvolvimento pode (e deve) gerar uma lista dos 10 problemas mais comuns nas especificações. Este pequeno processo pode aumentar a qualidade da equipe de especificação técnica e melhorar seus processos automáticamente. Consequentemente, a produtividade de ambas as equipes aumentará com o tempo.

Da mesma forma que a equipe de desenvolvimento tem critérios de entrada, a equipe de testes também tem, e estes podem ser os critérios de saída da equipe de desenvolvimento. Os critérios de saída visam reduzir a probabilidade de problemas voltarem e consequentemente gerar retrabalho (+ redução na produtividade + aumento no custo). Como exemplo podemos definir dois simples critérios de saída da equipe de desenvolvimento:

• Base de dados exemplo
• Evidências de que os testes foram realizados (conforme cenários)

Estes dois simples itens ajudam muito no aumento da qualidade e redução do custo (com retrabalho), pois a equipe de testes evitará enviar erros fake que tipicamente são encontrados por não ter uma massa de dados coerente e garantirá que a equipe testou o que foi definido pela equipe de especificação. Da mesma forma, a área de testes pode criar (ou ajudar) no top 10 problemas mais comuns em ambas as áreas.

Note que neste ponto, a melhoria de processos acontece de forma natural afetando as três ou mais áreas (especificação técnica, desenvolvimento e testes) pois constantemente as equipes vão se policiando e mostrando os problemas mais comuns nas áreas.

A qualidade aumenta, o custo é reduzido, a produtividade é aumentada e todos ficam felizes.

Uma das ferramentas mais simples e práticas ferramentas para a gestão de processos e garantia da qualidade são os checklists (também conhecidos como listas de verificação e uma das sete ferramentas da qualidade). Muito comum na indústria, os checklists são a base para o desenvolvimento do trabalho e garantia de que ele será realizado seguindo os passos certos. Veja o exemplo de quando compra-se um carro, antes dele ser entregue ao comprador, verifica-se uma série de itens para garantir que o novo comprador não terá surpresas desagradáveis. Agora imagine a quantidade de verificações que são realizadas para se colocar um satélite em órbita.

Os checklists são uma boa forma de “lembrar” o que deve, ou deveria estar pronto. Eles podem ser utilizados para direcionar as atividades de um determinado trabalho ou até mesmo verificar se tudo está ok. É importante lembrar que por mais experiente que seja o profissional, ele pode esquecer coisas importantes pois sua memória é limitada. Para lembrar dos passos e atividades ele poderia carregar os procedimentos, todavia, isto seria inviável. Desta forma, os checklists fazem o meio termo e ajudam as pessoas a lembrar o que deve ser feito e garantir que foi feito conforme previsto.

Para utilizar os checklists da melhor forma você pode seguir as seguintes orientações:

Treine as pessoas

Lembre-se que os checklists podem ser uma versão resumida de processos e procedimentos, logo, se as pessoas não receberam treinamento nos processos, de pouco adiantará o uso de checklists. Os checklists não devem ser utilizados como a única fonte de referência sobre um determinado processo.

Procure cobrir todo o processo

Lembre-se que todas as atividades importantes devem estar presentes no checklist. Como exemplo: espera-se que alguém aprove um documento, inclua um item para verificar se este documento foi aprovado.

Seja sucinto

Novamente, os checklists não são o procedimento, desta forma deve-se evitar textos longos. Seja objetivo. Explique o que deve ser feito ou verificado no menor texto possível. Um profissional treinado deve compreender facilmente o que se espera do item de verificação.

Mantenha um processo de evolução contínua

Procure manter um fórum ou sistema para que as pessoas tem contato com os checklists enviem sugestões (e responda todas). Não mude seus checklists a toda hora, consolide uma determinada quantidade de alterações, crie uma nova versão e comunique o que foi alterado (e os benefícios esperados). Procure disseminar a cultura de melhoria contínua.

No desenvolvimento de sistemas podemos utilizar checklists em vários momentos do projeto como critérios de entrada e saída, garantia da qualidade, verificação entre pares, liberação de release e outros.

Futuro próximo do Gerenciamento de Projetos

Os próximos anos prometem ser muito prósperos para os profissionais de gerenciamento de projetos. Copa do mundo, olimpíadas, fusões, aquisições e a grande quantidade de investimentos internacionais previstos para entrar no Brasil devem provocar ainda mais o crescimento da grande onda de demandas e empreendimentos em projetos em todos os setores da economia.

Neste cenário promissor que já esta em curso, não há dúvidas que o aquecimento das oportunidades para profissionais de projetos devem aumentar significativamente, onde de certo, os profissionais bem preparados com formação, certificações, experiências nos contextos técnico e gerencial estarão super requisitados e valorizados no mercado.

Os Escritórios de Projetos

Na onde deste crescimento, um “setor relativamente novo” neste cenário terá também grande destaque e atenção neste contexto: Os Escritórios de Projetos. Também muito conhecidos mesmo no Brasil como PMO (Project Management Office), que geralmente são definidos como unidades organizacionais instituídas para atuar exclusivamente em ambientes de projetos, podendo ser responsáveis por diversas funções como desde simples atuações operacionais como centralizações e distribuições de informações de projetos ou como funções mais estratégicas como desenvolvimento da maturidade em gerenciamento de projetos, co-gestão em Projetos, Programas e Portfólios foco e aderência nos alinhamentos e objetivos organizacionais e demais funções.

Crescimento dos PMOs nas organizações Funcionais e Matriciais

Na medida em que as organizações estão evoluindo seus níveis de entendimento, investimento e comprometimento na gestão de projetos como fator relevante para o sucesso de seus empreendimentos, crescem também na mesma proporção o interesse e investimentos em se estabelecer Escritórios de Projetos para apoiar, monitorar e desenvolver suas estruturas de projetos.

Mesmo organizações não orientadas a projetos, as tipicamente funcionais como bancos, seguradoras e industrias já investem fortemente na implementação e desenvolvimento de escritório de projetos para suportar não só seus empreendimentos internos, mas principalmente na função de acompanhamento de projetos junto a seus fornecedores, visando garantir prazos, investimentos, qualidade e minimizar riscos.

PMOs e as empresas Projetizadas

Já as organizações mais orientadas a projetos (as Projetizadas), o PMO se tornou uma estrutura (mesmo que mínima) obrigatória. Já é comum que o PMO apareça no desenho das estruturas organizacionais deste tipo de empresas.

Nestes cenários de estruturas Projetizadas, o PMO geralmente é responsável por definir e manter métodos, processos e ferramentas para gestão de projetos, além de atuar como centro de excelência e suporte para equipes e também servir como elo entre as camadas executivas da organização e as áreas de projetos.

Crescimento de profissionais para PMOs

Outro fato que reflete esta realidade sobre escritórios de projetos é a grande quantidade de oportunidades profissionais que estão surgindo para “tocar” estas áreas. Para comprovar esta realidade, basta entrar nos principais sites de empregos e digitar o texto “PMO” em uma pesquisa por cargo, por exemplo.

Concluíndo

Portanto sem dúvida nenhuma, Escritórios de Projetos se tronaram fatores chave para as organizações que primam pela a excelência e maturidade em gestão de projetos.

[Marcos Pires]

MPS.BR é a sigla de Melhoria de Processos do Software Brasileiro, modelo este que foi criado pela Softex e patrocipado pelo MCT. Mas o que é isso afinal de contas?

O MPS.BR é uma adaptação para as empresas brasileiras – em especial micro, pequenas e médias empresas – de um modelo de maturidade de processos de desenvolvimento de software conhecido internacionalmente como CMMI-DEV.

Muito se fala sobre esses modelos. Mas, após pesquisar exaustivamente sobre o assunto, cheguei a uma triste conclusão: Todo o material carece de clareza. Assim como o CMMI, há muito “diz-muito-sem-dizer-nada”. Inclusive, os próprios guias de implementação desses modelos são confusos. Para ajudar, em grande parte de nossas universidades, aprende-se o básico. A maioria delas forma programadores e não analistas ou arquitetos.

Com base neste e outros pontos resolvi tentar desmistificar esse assunto. Como estou no Brasil, nada mais lógico do que começar pelo MPS.BR, mas vale lembrar que o mesmo vale para o CMMI.

Pensei em escrever esse artigo de diversas formas e cheguei à conclusão que a melhor seria por meio de perguntas e respostas. Não que você já se tenha feito essas mesmas perguntas (o material disponível sobre o assunto é confuso e muitos não chegam nem no nível da dúvida). Mas as perguntas nos ajudam a raciocinar e esclarecer o assunto.

Este primeiro artigo é apenas uma breve introdução sobre o MPS.BR de forma geral.

O que é o MPS.BR

É um modelo de maturidade de processos relacionados com o desenvolvimento de software. Esse modelo foi adaptado de um outro modelo conhecido internacionalmente (e de muito sucesso) como CMMI-DEV para a realidade das empresas brasileiras. Isso foi necessário por que o CMMI-DEV prevê o amadurecimento dos processos em apenas cinco níveis. E, com o tempo, percebeu-se que a coisa tinha de funcionar de forma mais gradual aqui no Brasil. Daí quebraram os cinco níveis do CMMI-DEV em sete, que vão do G ao A, e fizeram alguns pequenos ajustes.

O que é um modelo de maturidade de processos?

Toda empresa ou indivíduo que desenvolve software já faz isso por meio de algum processo. Esse processo pode ser caótico, obscuro e até mudar constantemente, mas não deixa de ser um processo. E isso nada mais é do que uma seqüência de atividades. Mesmo que você não se dê conta disto, tudo que você faz no trabalho de desenvolvimento de software segue uma seqüência de atividades. Às vezes essa seqüência não é fixa. Às vezes essa seqüência não segue uma ordem lógica. Às vezes essa seqüência provoca algum retrabalho. Mas perceba que sempre existirá uma seqüência. Às vezes essa seqüência já é eficiente, mas ninguém mais além de você sabe como funciona. Um modelo de maturidade de processos serve para corrigir esses e muitos outros problemas.

O MPS.BR descreve um modelo de amadurecimento gradual dos processos de desenvolvimento de software. Ou seja, você não precisar melhorar tudo de uma vez. Pode fazer isso aos poucos, de forma gradual. É para isso que servem os níveis de maturidade.

Vale ressaltar que o MPS.BR é apenas um modelo. Ninguém é obrigado a segui-lo a risca. Mas… ele é uma coletânea das melhores práticas relacionadas com o desenvolvimento de software. Assim, talvez valha a pena considerá-lo se não no todo, mas em parte. Entretanto, como ele é uma adaptação do CMMI-DEV, essas melhores práticas foram coletadas em outros mercados como EUA e Europa principalmente. E isso pode por em dúvida a aplicabilidade dessas supostas melhores práticas a nós, brasileiros. Essa dúvida, porém, só o tempo poderá dirimir.

O que é um processo maduro?

Ótima pergunta!
Dizer que um processo é, ou não, maduro pode gerar muita polêmica. Um processo é maduro quando ele é previsível, é estável e atinge os resultados esperados – poderiamos adicionar o baixo custo, mas isto normalmente é consequência. Mas a dificuldade é justamente medir os resultados e o custo pois em nossa área não há muito a cultura de se trabalhar com dados e as decisões são tomadas muitas vezes com base em percepções e não em resultados.

Portanto, para saber se um processo é ou não maduro, precisamos primeiro conseguir medi-lo. E é justamente esse a base para o objetivo final do MPS.BR: conseguir medir o desempenho dos processos, predizer seu comportamento futuro e melhorar sempre. Em teoria, uma empresa no Nível A do MPS.BR conhece plenamente o desempenho de seus processos e os fatores que os influenciam. Ao descobrir que um processo qualquer não é maduro, cabe à empresa encontrar formas de amadurecê-lo DE FATO, mas isto acontece fortemente no MPS.Br nível B – até chegar à ele você (vamos dizer) organiza a casa.

Na prática, as empresas já terão subsídios para amadurecer os processos desde o Nível F. Ou seja, não se precisa esperar até o Nível A para tomar alguma ação corretiva, elas podem (e devem) ser tomadas desde os níveis iniciais.

Que ações a empresa precisa tomar? O MPS.BR não diz. Ainda bem!

E para que um processo possa ser medido e corrigido ele precisa ser transparente, medido e gerenciável. Tudo gira em torno disso. Se um processo não é transparente, então não pode ser medido. Se não pode ser medido, então não temos como saber se os seus resultados são os melhores possíveis a um determinado custo. Se um processo não é gerenciável, mesmo que se possa medi-lo, então não se pode corrigi-lo, melhorá-lo. Se não podemos melhorá-lo, não podemos amadurecê-lo. Essa é a lógica da coisa toda.

Maduro para quem?

Maduro para todo mundo, ora bolas!, mas especialmente para as gerências e alta direção. Lembre-se: quando vir a palavra maduro, pense em transparente, medido e gerenciável. Nunca esqueça isso.

Porque meu gerente está especialmente interessado nisso?

Lembra do transparente, medido e gerenciável? Pois é. Se o processo é transparente, o seu gerente sabe exatamente o que você está fazendo ou deve fazer e o que você pode fazer. Sabe se você está enrolando o serviço. Sabe se você precisa de ajuda para cumprir o prazo. Pode até conferir o que você já produziu.

Se o processo é gerenciável, o seu gerente pode aproveitar o que você já produziu e te substituir por outra pessoa para que você toque outra atividade. Pode colocar mais alguém para te ajudar. E pode até pedir para você refazer algo antes que seja tarde demais.

Quando o processo é transparente, ele deixa de ser aquela caixa preta que ninguém além de você sabe como funciona.

Quando o processo é transparente, fica mais fácil saber quais são os bons funcionários e quais não são. Fica mais fácil premiar o bom desempenho. Um processo maduro depende menos dos indivíduos. E também fica mais fácil identificar quem só esta fazendo marketing e não esta trazendo resultados.

Ah, então devo me preocupar com o meu emprego?

Sim e não.

Se você é um mau funcionário, o MPS.BR vai deixar isso mais evidente pois, como já falei, os processos vão ficando cada vez mais transparentes. Mandar-te embora é uma decisão do seu gerente – o MPS.BR não obriga nenhuma empresa a fazer isso!

Acontecerá justamente o contrário se você for um ótimo funcionário. O MPS.BR vai deixar isso mais evidente e, talvez, você seja até promovido. Na pior das hipóteses, você vai continuar se destacando como bom funcionário. Note que o MPS.BR pretende tornar os processos menos dependentes de indivíduos. Repito: indivíduos. Todo processo sempre dependerá de uma boa equipe. E bons gerentes escolhem bons funcionários para as suas equipes. Ou seja, se é bom funcionário, está dentro!

Ok, mas onde entra a documentação nisso tudo?

Sabia que você ia tocar nesse assunto. Após a implementação do MPS.BR, seja qual for o nível, não é raro os desenvolvedores reclamarem da quantidade de documentação que eles precisam produzir. Esse problema, contudo, varia de empresa para empresa.

O MPS.BR não obriga nenhuma empresa a produzir os artefatos A, B ou C. Na verdade, ele não te obriga a ter um único documento. Você precisa sim ter evidências de que realizou determinadas atividades, mas isto pode ser provado de várias formas.

Algumas empresas utilizam formulários de preenchimento manual, outras utilizam ferramentas onde o preenchimento é quase automático e outras como as com modelos SCRUM usam métodos totalmente diferentes. Se você não está contente com a forma como alguns artefatos são produzidos, procure a área responsável e sugira melhorias. O MPS.BR só é viável se todos se comprometerem com o modelo. Se isso não está acontecendo na sua empresa, a alta direção deveria promover isso com incentivos concretos. Só treinamento não basta.

Para que serve essa documentação toda?

Já que você insiste no assunto, vamos lá! Pessoalmente, também não sou muito fã desses artefatos. Mas acredito que sempre há uma forma mais fácil e simples de produzir a documentação implícita no MPS.BR.

Outro problema é que normalmente a gente só sente falta de um determinado documento em uma situação de conflito. Imagine a situação onde você fechou com o cliente que o relatório de vendas vai ser apresentado como uma página web comum. Quando você chega na validação ele comenta que não era nada disso e que o que ele tinha pedido era um relatório com opção para imprimir, com paginação e que permitisse exportar para excel e tivesse um pivot table. Se você não documentou o primeiro pedido imagine de quem será a culpa pelo prejuizo?

Mas em linhas gerais, essa documentação toda serve para tornar o processo mais transparente e segurança para ambos os lados.

Ouvi dizer que tudo precisa ser um projeto; isso é verdade?

Sim e não.

Mas isso não deve ser problema. Você pode aplicar o MPS.Br em Projetos e demandas contínuas como fábrica de código, testes, especificação, etc. Mas mesmo estes trabalhos de demandas contínuas podem ser chamados de projetos. Chego até a dizer que mudando um pouco a terminologia de Software, podemos aplicar o MPS.Br em diversas outras áreas.

Mas… voltando a projeto: O que é um projeto afinal de contas? Projeto é um trabalho com escopo, custo, início e fim determinados e normalmente ele cria algo único. Mas isso é óbvio! E na verdade tudo que é desenvolvido é algo novo. Se não é novo, já existe e, portanto, não precisa ser feito. Logo, o que precisa ser feito é sempre algo novo em menor ou maior escala. Pense sobre isso. Tirando a correção de erros, TUDO é novo no desenvolvimento de software.

Assim, perceba que não faz diferença chamar o seu trabalho de projeto. Concordo que é um erro do MPS.BR exigir uma rotulação para os trabalhos. Mas, já que não faz diferença, o que custa atender?

Ah, mas um projeto é mais burocrático…

Novamente, sim e não. Como já disse, tudo depende da sua empresa. Algumas atividades são necessárias não por simplesmente existir um projeto, mas por que o processo precisa ser transparente e gerenciável. Nunca esqueça disso.

Preciso de alguma ferramenta?

Não. Mas o uso de algumas fica implícito no MPS.BR. Ou seja, não é algo obrigatório, mas muitas vezes é desejável. Lembre-se que as ferramentas existem para agilizar os trabalhos, reduzindo o tempo e consequentemente o custo.

Como exemplo, você pode fazer um controle de configuração através de uma estrutura de diretórios no windows, com (por exemplo) pastas e mudanças nos nomes dos arquivos. Isto vai levar um determinado tempo para fazer e consequentemente um custo. Já se você colocar uma ferramenta para apoio como SVN, Sharepoint ou até mesmo o Source Safe você economizará no mínimo metade do tempo (e consequentemente metade do custo).

O que a empresa ganha com isso?

Relacionados ao MPS.Br há poucos estudos, todavia se olharmos o CMMI (que é a mesma coisa) podemos ver que normalmente as empresas aumentam significativamente sua produtividade, assertividade nas estimativas, aumentam a satisfação de seus clientes, reduzem consideravelmente os custos e aumentam a qualidade de seus produtos. Estes mesmos estudos indicam que o retorno do investimento ocorre rapidamente.

Conheço quase 15 casos aqui no Brasil de implementações com MPS.Br e posso dizer que os patrocinadores estão muito contentes com os resultados obtivos e estão buscando os níveis posteriores pois perceberam que “valeu a pena”.

Conclusão

Este texto é apenas uma breve introdução ao assunto.
Vimos que o MPS.BR (e por extensão o CMMI) não é esse bicho de sete cabeças que as pessoas imaginam. A chave de tudo, na minha opinião, é a transparência e gestão do processo – com a conseqüente medição.

[Adaptado do texto de Samuel Diniz]

Excelente artigo escrito por Samuel Diniz comparando o desenvolvimento de software com uma reforma de casa.

Dá gosto ver o resultado de uma boa reforma – ainda mais se teve um bom projeto de um arquiteto ou decorador. Do contrário, é um desgosto sem tamanho ver que, ao final, após tanto dinheiro, tempo e trabalho gastos, aquela reforma dos seus sonhos não ficou exatamente como você imaginava. Pior ainda é descobrir que para ajustar tudo talvez você gaste mais do que para fazê-lo.

Reformar ou construir uma casa é como desenvolver software. Inclusive, essa é a metáfora mais comum que se utiliza para racionalizar o desenvolvimento de um software. Você parte de uma idéia abstrata e depois se esforça para materializá-la. Como todo trabalho de engenharia, o resultado final depende de uma boa definição do escopo, comunicação, colaboração e controle.

Assim, se você nunca passou por uma reforma antes e está pensando em iniciar uma empreitada, ou pensa em desenvolver software , aqui vão algumas dicas de quem conviveu com uma reforma bem abrangente, cometeu vários erros, quase morreu de desgosto, mas pelo menos aprendeu algumas boas lições para a próxima vez. Em cada dica, eu faço uma analogia com o desenvolvimento de software.

Tenha uma idéia MUITA clara do que será feito ANTES de iniciar a obra

Esta é provavelmente a dica mais importante: Só inicie a obra quando você souber exatamente o quê e como será feito. Estamos aqui falando de definição do escopo e levantamento de requisitos. Não pense que tudo se resume ao projeto do arquiteto ou decorador. Nem basta saber os tipos de materiais que serão usados. Você precisa saber EXATAMENTE o quê será feito. Qual será a cor do piso? Onde será utilizado? Como serão feitas as emendas e os recortes? Se algo der errado, quais as alternativas? Você verificou se as instalações hidráulica e elétrica propostas no modelo são realmente viáveis? Tem certeza que aquele registro importante ou o painel de disjuntores não vão ficar atrás de algum armário? O armário planejado vai mesmo comportar aquilo que você pretende guardar nele?

Considerou o espaço para ventilação que alguns eletroeletrônicos precisam?

Analise bastante o projeto e confronte-o com o local. Cruze as plantas que você já tem com as do projeto. Estude os possíveis cenários de uso. Faça algumas simulações com recortes de papelão. Quanto mais tempo você gastar confirmando o projeto e tomando decisões (ou seja, planejando), menos tempo, dinheiro e trabalho você vai perder contornando restrições durante a obra. Muito faz-desfaz será evitado com uma boa análise e planejamento e comunicação com aqueles que vão executar a obra.

Em desenvolvimento de software é a mesma coisa. O escopo precisa estar muito bem definido antes do início do projeto. E, uma vez iniciado, a coisa mais importante a fazer é definir os requisitos e promover o entendimento claro deles por todos os interessados. Entregar algumas funcionalidades logo cedo, como prega o desenvolvimento ágil, pode contribuir para esclarecer os requisitos no início do desenvolvimento, que é muito mais barato. Se isso não for possível, prototipar pode ser de boa ajuda. É claro que podem ocorrer mudanças no decorrer da empreitada. Mas quanto mais tempo de análise você gastar com isso no início, menores serão os aborrecimentos depois.

Não inicie a obra sem ter providenciado todos os materiais necessários

Entenda que nem tudo em uma obra pode ser feito de uma vez só. Assim, é prudente providenciar todo o material necessário à obra, para o caso do pedreiro precisar aproveitar o tempo para fazer uma ou outra coisa enquanto espera ‘aquela massa’ ou ‘aquela tinta’ secarem. Providenciar com antecedência todos os materiais vai também possibilitar que você contrate a mão-de-obra por empreitada e o pedreiro, ao ver que todo o material está disponível, vai concordar com isso. Ganha você que provavelmente vai gastar menos dinheiro com mão-de-obra e provavelmente vai receber a obra antes, e ganha o pedreiro que vai poder aproveitar ao máximo o seu tempo e ganhar dinheiro ao assumir outra obra o quanto antes.

Em desenvolvimento de software os ‘materiais’ são informação e os programadores assumem o papel de ‘arquiteto’ e ‘pedreiro’. Escopo e requisitos são as informações que eles precisam para modelar e desenvolver o software. Não caia no erro de alocar essas pessoas sem ter essas informações prontas. No início do projeto, você não precisa alocar toda a equipe de programadores para levantar requisitos. A equipe de requisitos e talvez um programador mais experiente são, em geral, suficientes para uma boa análise de requisitos e definição da iterações. Deixe para alocar programadores depois, quando você tiver pelo menos uma iteração bem definida para ser construída, do contrário eles ficarão ociosos.

Essa dica também é importante por causa da próxima dica.

Não confie nos prazos de entrega dos materiais

A postura mais ingênua que você pode ter é acreditar que os prazos de entrega dos materiais prometidos serão cumpridos pelas lojas. Pode colocar o dobro ou, dependendo do caso, o triplo. Isso se a loja não te ligar para dizer que aquele piso que você contava para amanhã na verdade está em falta no depósito e só será entregue daqui a um mês ou mais. É por isso que é tão importante providenciar todos os materiais antes de iniciar a obra. Do contrário você corre o sério risco de deixar o seu pedreiro ocioso. Ele vai acabar assumindo outra obra para não ficar parado e isso vai dar início a um ciclo vicioso de enrola-enrola da sua parte e da parte dele. E aí, caro leitor, esqueça aquele prazo de um mês para terminar a reforma.

No desenvolvimento de software esse problema geralmente ocorre quando você terceiriza a construção do software. Se você contrata uma empresa (ou um “freela”) para construir seu software, mas não entrega as informações de que ela precisa, essa empresa vai acabar assumindo uma outra construção – afinal ela precisa trabalhar para receber – e isso pode acabar gerando o famigerado ciclo vicioso de enrola-enrola. Percebe-se que os clientes, em geral, são rápidos para definir o escopo, mas muito lentos para ajudar na especificação de requisitos e PRINCIPALMENTE homologar os entregáveis que muitas vezes ocorrem cedo no projeto. Assim, minha dica é: Não assuma compromissos se o cliente não estiver disposto a assumir compromissos (contratuais) para o fornecimento dos requisitos e prazos para homologação.

Não trabalhe no limite

Essa dica vale para todos os aspectos de uma construção ou reforma. Cuidado com tudo aquilo que parece estar no limite. Contar com o limite dos prazos, limite dos espaços, limite dos materiais, em fim, todos os limites. Pense nisso também quando pensar nos seus armários planejados. Criar aquela divisória que cabe ‘exatamente’ aquele microondas ou o receiver do seu home theater pode não ser uma boa idéia, afinal, esses eletroeletrônicos precisam de uma área de folga para circulação de ar e passagem dos cabos e tomadas. Quando o assunto é limites, é interessante trabalhar sempre com uma margem de tolerância de pelo menos 10% em todas as dimensões.

Os limites também devem ser evitados no desenvolvimento de software. Se você tem um prazo, por exemplo, não conte com o limite dele para entregar algum produto. Algo pode sair errado e aí você vai ficar mal visto. Planeje sempre com pelo menos 10% de folga. Evitar limites vale também para aspectos relacionados com recursos de processamento. Digamos que você precise desenvolver algum software que vai ficar no limite da capacidade de uma infraestrutura qualquer – rede, armazenamento ou processamento em geral –, muito cuidado! Trabalhar no limite não te dá margem para errar. E errar, caro leitor, é inerente ao ser humano (sem falar que algumas máquinas falham também!).

‘O gado só engorda com o olho do dono’

Essa frase é uma máxima que todos deveriam levar para o resto da vida. É como se diz: Se você quer um trabalho bem feito, faça você mesmo. Infelizmente, não podemos fazer tudo aquilo que precisamos. Mas em geral podemos pelo menos ver e acompanhar aquilo que está sendo feito para nós.

No caso de uma reforma, isso é importantíssimo. Como já foi dito no início deste artigo, há muitos detalhes que vão além do projeto. Por isso, é vital que você acompanhe de perto a obra. Caso você trabalhe o dia inteiro, converse com o seu chefe para flexibilizar de alguma forma o seu horário para que você possa passar pelo menos uma ou duas horas por dia acompanhando a execução da reforma.

Você não vai se arrepender. Além de evitar muitos erros e supresas, esse controle vai diminuir a probabilidade de erros serem cometidos em cima de outros erros. Em outras palavras, menos retrabalho. Estamos falando aqui de boa comunicação e feedback constante.

Isso é evidente no desenvolvimento de software. O manifesto ágil deixa isso bem claro quando fala da colaboração com o cliente. Inclusive, alguns modelos ágeis sugerem que um representante do cliente ou usuário fique constantemente com a equipe de construção. A idéia é obter informações do cliente em tempo de execução (desculpe o trocadilho), evitar surpresas na hora de apresentar os entregáveis e, com isso, evitar retrabalho.

Entenda que refazer desmotiva

As pessoas em geral levam numa boa concertar seus próprios erros. Já quando o assunto é concertar erros dos outros… Ninguém gosta de refazer algo por culpa de outra pessoa. Em reformas isso é muito comum. Você diz para o pedreiro colocar a pia naquele lugar, depois muda de idéia e pede para ele refazer tudo e mudar a posição. A chance de ele ficar com má vontade e fazer pior é muito grande, pois isso é do ser humano. O que fazer nesses casos?

Mesmo com bom planejamento, é comum ter que fazer um ou outro ajuste. Assim, entender que refazer desmotiva é vital para o sucesso. Ao pedir que alguém refaça um trabalho por uma culpa que não seja dessa pessoa, explique com tato que entende que a culpa é sua (ou de seja lá quem) e que você reconhece que refazer aquilo pode acabar atrasando a entrega total e assim por diante. Talvez seja interessante até combinar um pagamento extra para esses casos – é justo!

Em desenvolvimento de software é a mesma coisa. Programadores em geral gostam de ‘escovar bits’ atrás de seus próprios erros, mas detestam refazer algo por culpa dos outros. Entenda que isso pode desmotivá-los a fazer a coisa com a mesma qualidade do original e reconheça de quem é a culpa. É interessante que esses casos estejam previstos em contrato com a devida compensação financeira.

Espero que essa dica ajude a todos que estão pensando em fazer uma reforma e também àqueles que lideram equipes de desenvolvimento de software.

E você? Tem alguma dica para nós?

1. Seu processo de tomada de decisões geralmente envolve uma moeda, uma mesa de bar e cerveja [DAR];
   .
2. Seu processo de gerenciamento de riscos foi desenvolvido há alguns anos por um grupo de estagiários (porque eles estavam sem demanda) [RSKM];
   .
3. Seu processo de integração ainda utiliza a palavra disquete (e em vários lugares) [PI];
   .
4. Seu processo de análise de causa é baseado a opinião de quem chega primeiro e fala [CAR];
   .
5. Se der crash na maquina de um programador, ele terá que desenvolver tudo que estava lá novamente [CM];
   .
6. O planejamento de um projeto é (na melhor das hipóteses) um cronograma simples [PP];
   .
7. Sua técnica de dimensionamento se baseia na opinião do primeiro programador que você encontrar (e se você perguntar à cinco programadores diferentes, cada um vai falar um esforço bem diferente) [REQM];
   .
8. Sua empresa faz apenas validação do produto final (quando o faz). Normalmente o programador chega ao seu cliente e pergunta: “e ai… ta bom?” E fica repetindo até escutar: “Ta” [VAL];
   .
9. Mais de 90% dos erros encontrados pela sua área de garantia da qualidade de processo e produto são erros de português [PPQA];
   .
10. Melhorias nos processos são avaliada semestralmente pelo gerente do departamento (Somente são analisadas as melhorias com o texto “redução de custos”) [OID];
    .
11. Seu plano de implantação é: “E então acontece…” [OPF];
    .
12. O acompanhamento de projetos é realizado “quando o gerente do departamento cobra como esta o projeto” [PMC];
    .

Estes mesmos critérios servem para o MPS.Br nível Z

;D

[Adaptado de www.cmmitraining.com]

Constantemente as pessoas perguntam qual o relacionamento entre o modelo X e o modelo Y. O gráfico abaixo demonstra este relacionamento através dos modelos que mostram “o que fazer”, os modelos que mostram “como fazer” e os modelos de “melhoria contínua”. Não são todos, mas os mais comuns.

A implantação da ISO 9001 oferece, além da possibilidade de ampliar mercados, uma série de vantagens para as empresas: aumenta o nível de organização interna, o controle da administração e a produtividade. Além desses benefícios, também leva a redução de custos e do número de erros e melhora a credibilidade junto a seus clientes. Serve ainda:

• Para atender a clientes que já possuem um SGQ (Sistema de Gestão da Qualidade) implantado e pedem o certificado de seus fornecedores.
• Para se preparar para crescer.
• Para trazer para dentro da organização os conhecimentos das pessoas que trabalham nela. Assim, se uma pessoa, por exemplo, ganhar na loteria ou se aposentar e deixar o emprego, o seu trabalho terá continuidade de maneira mais fácil.Quando há na organização atividades complexas.
• Quando é preciso treinar novos colaboradores.
• Se várias pessoas exercem a mesma atividade e é preciso que elas façam essa atividade da mesma forma.

A norma NBR ISO 9001 é aplicável a qualquer produto, a qualquer tipo de serviço e a qualquer tamanho da organização. É também compatível com outros sistemas de gestão e focada em melhoria contínua. Além disso, é voltada para os resultados dos negócios.

O SGQ (Sistema de Gestão da Qualidade) faz parte de vários sistemas que existem nas organizações, entre eles: o Sistema de Informação, o Sistema Financeiro, o Sistema de Vendas. Ao se implantar o SGQ busca-se algo que seja compatível com a organização, que agregue valor e que seja interligado com outros processos organizacionais.

As organizações precisam ser lucrativas, pois uma organização não lucrativa pode falir. E se fechar vai prejudicar não somente os funcionários da empresa, mas também as famílias desses funcionários. Sem falar que prejudica também os clientes e a comunidade que precisam da organização.

Algumas empresas têm clientes que preferem comprar de empresas certificadas na ISO 9001. E como ela quer continuar fornecendo para esses clientes, busca a certificação. Depois de conseguir o certificado, a empresa percebe que a certificação valeu a pena, já que obteve, entre outros, os seguintes benefícios:

• Melhoria na transferência interna de conhecimentos e desenvolvimento de competências.
• Melhoria da moral e da motivação da equipe, já que entende o porquê faz suas atividades e se motiva.
• Redução dos custos com qualidade (refugos, retrabalho, devolução).
• Aumento da competitividade, com custo mais baixo.
• Aumento na satisfação dos clientes.
• Aumento na rentabilidade.

Para implantar a norma ISO 9001, a empresa precisa primeiro dizer o que faz, depois, fazer o que disse que faz. Para isso, escreve-se as atividades da forma que são realizadas e posteriormente verifica-se se todos fazem da forma que está escrito. Caso contrário, revisa-se a documentação ou treina-se as pessoas a fazerem como está escrito. Assim, depois de um ciclo de verificações e melhorias, todos farão como está escrito. Obtem-se, então, uma padronização da forma de se realizar os processos. Só que isso acontece elevando-se o nível de cada processo, já que se padroniza a melhor maneira de se fazer o que precisa ser feito.

Durante a implantação da norma cria-se também o hábito de registrar o que se faz. Esses registros evidenciam a forma como foram realizadas as atividades, para se ter um histórico do que aconteceu e para se obter dados importantes para a tomada de decisão. Além disso, facilitam a programação das atividades futuras melhorando a performance da equipe.

Uma norma bem implantada leva a redução de custos, porque diminui a quantidade de erros e o desperdício. Também leva ao crescimento e à mudança na escala de produção, o que na maioria das vezes ajuda a baixar os preços. Isso garante uma maior satisfação dos clientes que, assim, compram mais, melhorando os resultados da empresa. É um ciclo de melhorias contínuas. A Organização planeja a melhoria, implanta e checa para ver se está tudo de acordo. Caso positivo padroniza-se a solução e, depois, pensa-se em novas melhorias. Caso contrário, atua-se no problema para solucioná-lo. Com isso, a empresa segue tornando-se cada vez melhor.

[Sonia Jordão]