MODELOS DE MELHORES PRÁTICAS

Os modelos de melhores práticas são abordados na área de computação pelos processos de desenvolvimento de software. Têm como objetivo alcançar um aumento na qualidade do software e do seu processo de produção (com o estabelecimento de um processo de melhoria contínua), aumentando a previsibilidade e o controle, e a partir de uma demanda adequada, proporcionar a redução de custos.

No entanto, as idéias que inspiram estes modelos não representam uma novidade. Afinal, Zuboff (1988, p. 390) já descreve organizações onde os gerentes enfatizam a inteligência da má- quina e o controle gerencial sobre a base de conhecimento, prejudicando o desenvolvimento do conhecimento pela força de trabalho. Eles utilizam a tecnologia como um sistema anti-falhas, para aumentar o previsibilidade e o controle sobre a produção e as funções organizacionais.

É importante frisar que Zuboff (1988) considera estas práticas prejudiciais à criação de conhecimento pelas pessoas (força de trabalho). Isso corrobora a colocação de DeMarco e Lister (1999), que criticam os processos de melhoria de processos, pois acreditam serem prejudiciais, pois promovem a institucionalização da responsabilidade sobre a melhoria dos processos4. Na opinião dos autores, a melhoria dos processos deve ser feita pelas pessoas.

Contudo, as críticas apresentadas acima se referiam a alguns modelos anteriores aos mais apregoados atualmente, e que serão apresentados, ilustrativamente, neste trabalho. Contudo, parte das críticas apresentadas pode ser comprovada através das entrevistas realizadas neste trabalho junto à gestores em ambientes regidos por processos de software. Em muitos discursos fica bem clara a preocupação em estabelecer uma relação direta entre a melhoria dos processos e a possibilidade de participação da “força de trabalho” nesta melhoria. O capítulo de Análise deste trabalho desenvolve mais esta discussão (seção 6.2.3, pág. 104).

3.6.1

Competências e os processos de software

Para o processo de software CMMI, há uma KPA (Key Process Area) que trata da integração da equipe (integrated teaming). Seu objetivo é formar e dar suporte a uma equipe integrada para desenvolvimento dos produtos internos. São sugeridos alguns critérios para a definição de membros para a equipe (CHRISSIS; KONRAD; SHRUM, 2003, pág. 235) [tradução nossa]:

• Conhecimentos e habilidades relacionados às tarefas e responsabilidades associadas com os produtos a serem produzidos pelo grupo.

• Habilidades interpessoais e capacidade para trabalhar em grupo.

• Capacidade de complementar o conjunto de conhecimentos e habilidades do grupo. • Potencial para assumir responsabilidades significantes no grupo.

• Capacidade de adquirir novos conhecimentos, habilidades ou especializações relaciona- das às tarefas do grupo.

• Ter carga de trabalho adequada e tempo disponível para cumprir com as responsabilidades na equipe.

• Deve ter base educacional e cultural. • Ser motivado por si.

• Capacidade de representar uma área funcional apropriadamente

É interessante apresentar esta abordagem do CMMI, pois ele trabalha com competências: Habilidades, capacidades, conhecimentos. No entanto, esta KPA é tipicamente utilizada em fábricas de software a partir do nível 3 do CMMI.

3.6.2

Criação do conhecimento versus os modelos de melhores práticas

Há uma similaridade, entre o que foi criticado nos estudos de Zuboff (1988), já comentado no início desta seção, com a proposta apresentada pelos modelos CMM e CMMI, baseada na redução do risco, e no aumento da previsibilidade e do controle sobre os processos de desen- volvimento de software.

Desta forma, há um alinhamento de Zuboff com Nonaka e Takeuchi (1997), que defendem que a responsabilidade sobre a geração do conhecimento deve ser distribuída por todos os fun- cionários, e não só entre os de mais alto nível. Eles afirmam isso se baseando em pesquisas e nos resultados e inovações das empresas japonesas. Lembram que os ocidentais enxergam uma organização como uma máquina para processamento de informações, tratando o conhecimento como algo necessariamente explícito5, que pode ser expresso em palavras e números. Já as empresas japonesas vêem o conhecimento como algo basicamente tácito6- dificilmente visto ou

exprimível. Este conhecimento é pessoal e difícil de formalizar, dificultando a sua transmissão e o seu compartilhamento.

Para os japoneses, a função dos gerentes não é a responsabilidade pela criação do conhe- cimento. Eles são responsáveis por direcionar a criação do conhecimento, desenvolvendo con- ceitos gerais para identificar as características comuns, associando atividades ou negócios apa- rentemente díspares em um todo coerente (NONAKA; TAKEUCHI, 1997, pág. 16). Por este modelo, o gerente não passa tarefas especificadas, nem detalhadas, mas sim desafia a equipe a resolver o problema criativamente.

No ocidente há uma crença muito comum, onde o conhecimento pode ser facilmente trans- mitido através da educação e do treinamento. No entanto, é muito comum que se aprenda algo mesmo sem que se perceba. Isto é especialmente comum entre as crianças. É um aprendizado inconsciente, difícil de expressar, pois é difícil de ser percebido, muitas vezes originado na experiência direta.

Peter Senge (SENGE, 2003), em oposição ao modelo de aprendizado japonês, não acre- dita no aprendizado através da tentativa e erro. Ele defende o raciocínio sistêmico, que é um conjunto de ferramentas e conhecimentos, desenvolvidos no ocidente no últimos 50 anos, para ajudar as pessoas a identificarem os padrões. E mesmo dentro de um padrão de sistematiza- ção, ele critica o estilo de liderança onde as tarefas são definidas claramente, e os funcionários conduzidos pelo líder, pois é contrário ao ideal da empresa que aprende.

Já Nonaka acredita que a gestão do conhecimento tem um paradoxo, pois gerenciar implica em controlar, e como criar conhecimento sob o controle?

3.6.3

CMM e CMMI

Ambos são modelos de gestão de processo de software, desenvolvidos pelo Software En- gineering Institute (SEI), que é mantido com verbas do departamento de defesa dos Estados Unidos da América, e é gerenciado pela Universidade Carnegie Mellon, em Pittsburgh.

Também conhecido como SW-CMM, O CMM surgiu da necessidade do departamento de defesa Norte-Americano em determinar se um fornecedor seria capaz de desenvolver um soft- ware exatamente nas especificações solicitadas, e com o padrão de qualidade requerido previa- mente estabelecido.

6_{Segundo Nonaka e Takeuchi (1997, pág. 8), a diferença entre o conhecimento explícito e o conhecimento}

tácito é que o primeiro pode ser facilmente processado, transmitido e armazenado por um computador, enquanto

que o outro não. O conhecimento é gerado justamente durante a conversão do tácito em explícito e do explícito em tácito.

A principal característica do CMM é sua formação através de cinco níveis de maturidade para o processo de desenvolvimento e manutenção de software (FERNANDES; TEIXEIRA, 2004, p. 78-79):

Nível 1 É o estágio em que a gestão do processo não é aplicada, considerado inclusive uma