Traduzindo MSF significa “Microsoft Solutions Framework”. Apesar do nome Microsoft explícito, o MSF não é uma ferramenta que você pode comprar em uma revenda autorizada. Em superficiais palavras, apenas como introdução ao assunto, podemos definir MSF como um conjunto de “Best Practices” para a condução de um projeto de software – do ponto de vista gerencial.
Caso não esteja explicitamente declarado a seguir, antecipadamente declaro que uma das linhas mestras de conduta para este texto foi a de não apresentar diretamente uma ferramenta no qual possa parecer propaganda de um determinado fornecedor. Um posicionamento responsável que também me comprometi para este texto foi o de apresentar do ponto de vista prático funcional as experiências (lições) do meu escopo de realização histórica.
Antes de nos aprofundarmos necessariamente neste assunto, desejamos explicitar minha leitura sobre a utilização de ferramentas como metodologia de controle de projetos.
Programas versus Projetos
Quando definimos programas, podemos sem medo de errar apresentarmos o conceito único e indivisível (inquestionável) que: _ Programa é um conjunto de instruções pré-estabelecidas que são executadas por um computador.
A riqueza da língua portuguesa pode até permitir que você altere a redação, mas o sentido será sempre o mesmo. É o que eu gosto de classificar como afirmativa óbvia ululante, ou seja, uma verdade absoluta que você percebe que não existem questionamentos.
No tocante ao ponto de comparação, note que não existem variáveis que influenciam estas instruções. Elas são pré-estabelecidas. Por mais que aconteçam problemas de hardware ou de sistema operacional, o programa tentará infinitamente executar somente estas instruções até ser finalizado.
Já sobre projetos, desde meus tempos de estagiário – já escutei ou li diversas definições verdadeiras. Lembro-me que há pouco tempo atrás eu gostava de limitar a definição de “projetos” a um trabalho com escopo previamente definido, em outras palavras, com início – meio – fim. Hoje, com a prática de muitos projetos entregues, posso assegurar que projetos não devem ser previamente definidos.
Voltando ao ponto de comparação, em projetos não possuímos instruções pré-estabelecidas mesmo que as vezes podemos nos enganar acreditando nisso. Existem, na realidade, muitas variáveis de influência em projetos e todas elas convergem para um único ponto central – o ser humano.
Em meu questionamento crítico, as ferramentas ou técnicas que impõe instruções, ou mais rígido, regras pré-estabelecidas são impulsionadoras à falha. A pergunta é: como direcionar os projetos sem analisar as interferências humanas dos participantes do mesmo?
A relação humana com os projetos, é tão determinante e diferente que, sem sombra de dúvida, afirmo que um projeto nunca é igual a outros e nunca será. Nem sequer similar, mesmo que com o mesmo grupo de pessoas.
Antes de apresentar minha posição sobre a questão, outro destaque influenciador é a percepção que não existem mais (se é que um dia existiram ou foi uma imposição dos fornecedores) projetos de software com início – meio – fim definidos com muita antecedência, como desejam as metodologias.
Em pleno novo milênio, é inadmissível não compreender que todo usuário solicitante tem no mínimo o direito de evoluir seu conceito prático sobre determinada funcionalidade. Agir desta forma é renegar a inteligência em seu conceito mais básico, o da leitura interna.
Conclusivamente, porque exigir dos projetos que eles sejam programas se na prática isto é impossível?
Apresentada a polêmica, responsabilizo-me em fornecer minha posição de forma clara, transparente e única: A receita de construção de projetos é escolher pessoas que compreendam e utilizem a trilogia com inteligência.
A Trilogia
Após entender que projetos são na verdade o gerenciamento eficiente de pessoas, a técnica necessária a ser utilizada é livre, criativa e específica – desde que baseada na trilogia “comunicação, processos e papéis”. É quebrar o paradigma estereotipado de existir receitas de bolos para projetos. Normalmente estas receitas são do tipo “one size, fits all” e não servem ao escopo único de seu desafio novo chamado projeto.
Observando as propostas existentes com ferramentas caríssimas, verifica-se que elas tentam prever tantas coisas genéricas que a especificação do projeto geralmente é mais onerosa que a própria construção do mesmo. No meu ponto de vista é inadmissível aceitar isso, seria o mesmo que dizer que o plano diretor (ou planta) de um edifício é mais cara que a construção efetiva. De fato notamos nos projetos orientados por estas ferramentas que inconscientemente acontece uma espécie de ilusão coletiva: todos fingem fazer tudo que a metodologia exige, mas praticam seu conhecimento próprio.
Você pode optar por perpetuar a ilusão coletiva que existe em projetos de informática, afinal são com estas mentiras que muitos mercados funcionam. É uma linha determinada “me engana que eu gosto”.
Em linhas gerais acredito que você pode usar as técnicas que desejar, recomendo as que você pessoalmente domina desde que respeitando as adaptações necessárias a cada projeto específico. Entretanto, que seja muito claro a todos os participantes do seu projeto: As formas e regras de comunicação, os processos estabelecidos e os papéis responsabilizados.
Processos
É mais fácil perceber a ausência do que a existência de processos em seu projeto. Este é um assunto digno das “cadeiras” de administração e pode ser facilmente comparado a O&M – Organização & Métodos.
Na ótica simplista que determinamos para este texto, podemos compreender que sem processos conhecidos e “adotados” pelos demais participantes do projeto, a rotina criativa e direcionadora necessária ao gestor vão levá-lo a exaustão e em sua ausência (do gestor) ao caos no projeto.
É o mesmo que afirmar sobre determinados recursos que não podem ser substituídos. O primeiro ponto de vista pode parecer interessante, principalmente se és este gestor, afinal não podes ser dispensado. Os realmente gestores entendem que essa relação de dependência não é sadia e elevam desnecessariamente o risco do projeto.
Independente da metodologia que deseja adotar para o projeto, os participantes não podem ficar a espera de um gestor determinístico que direciona toda e qualquer ação. Esta “entidade onipresente” gestora deve, ao invés disso, proporcionar a todos os participantes do projeto antecipadamente os métodos para a ação, permitindo e incentivando também a todos suas próprias capacidades críticas e evolutivas.
A trilogia nos ensina uma unicidade, não há a possibilidade de quebrá-la. Em outras palavras, sem processos seu projeto será um fracasso.
Comunicação
Na década de 80 havia um programa de calouros comandado por um “showman” chamado Chacrinha. Insistentemente ele repetia uma máxima que era: _ Quem não se comunica, se trumbica. Na ingenuidade de minha infância não fazia a menor idéia sobre o que significava isto.
É impressionante como trabalhamos ao lado de pessoas, passamos o dia inteiro conversando sobre um monte de coisas importantes como filmes, futebol e até novelas (argh!), e não falamos sobre o projeto. É mais fácil gastar horas procurando uma informação ou pior, deduzi-la, que discutir com o companheiro de projeto ao lado.
Devem existir centenas de explicações filosóficas para este fenômeno, deixo-as para os intelectuais e psicólogos. Minha prática sobre este assunto é: Escreva todas as informações importantes “do e para” o projeto, coloque-as em locais visíveis a todos como uma espécie de bandeiras penduradas.
Este pilar trilógico é o mais livre e criativo dos três, faça da melhor forma ao seu projeto.
Papéis
Para mim este é o tópico mais importante e original da proposta MSF. Poderia atrever-me a escrever que os papéis são a base da trilogia, reconhecendo o risco desta afirmativa.
O pensamento é determinar à certas pessoas potenciais participantes do projeto a responsabilidade de papéis com escopos claramente definidos. Estes papéis são equilibrados e distribuídos de forma a facilitar a identificação de riscos no projeto e sua correta ação para a solução.
Os papéis necessários são: Program Manager, Product Manager, User Experience, Tester, Release Manager e Developers. Por uma opção pessoal de não gostar do resultado da tradução dos termos, mantemos os originais em inglês.
Developers: São os desenvolvedores propriamente dito. Em times grandes é aconselhável determinar apenas um que seja uma espécie de team leader para participar das reuniões e transmitir as informações aos demais. A prática também nos indica que este team leader deve ser um programador sênior, que funcione como direcionador de assuntos técnicos especialistas.
Release Manager: Quanto custa um dia de um time de 10 programadores parados porque o servidor centralizador de códigos fontes esta com problemas? Ou a rede esta com vírus, ou e mais “ou”. Este é o papel responsável por garantir toda a infra-estrutura necessária ao bom andamento do projeto. Além disto, este papel deve com antecipação planejar requisitos técnicos acerca do assunto implantação e distribuição (deployment).
Tester: Não existe projeto sério sem que haja um trabalho fundamentado em técnicas e métodos para testes. Ferramentas de automação de testes, Units Test, testes de carga, tunning de aplicativo, tunning de banco de dados e muitos outros tópicos que necessitam de um papel responsável e comprometido no projeto para endereçá-los.
User Experience: É o usuário propriamente dito, em outras palavras, quem usará o programa e sabe questionar a praticidade de suas funcionalidades ofertadas. Não existe programa sem usuário e é um gigantesco erro agir diferente desta afirmativa. Um macete é escolher um usuário super exigente, quanto mais crítico melhor será o resultado final.
Product Manager: Em todas as relações de negócios, sempre haverá uma espécie de vendedor que também funciona como advogado do cliente. Este papel tem a responsabilidade de ouvir clientes, pesquisar e direcionar funcionalidades que irão compor o aplicativo. Ele se torna também o melhor consultor e vendedor do projeto.
Program Manager: Pense em alguém que fotografa, vê todas as situações e imediatamente indica luz verde ou luz vermelha sobre cada particular. É a “eminência parda” do time. Conhece negócios, tecnologia e gestão de pessoas. Pode significar diretamente o sucesso ou o fracasso de um projeto. É o responsável, é o apaziguador, é o direcionador, é o esclarecedor.
O MSF defende em suas premissas que estes papéis não sejam hierarquizados, entretanto na prática o Program Manager possui a missão mais forte de liderança.
Pratica-se, conforme a criticidade momentânea do projeto, reuniões com periodicidade combinada entre os “papéis” do projeto objetivando nivelar a informação sobre os trabalhos. Os resultados destas reuniões chamam-se de Status Report e Risk Analisys.
Com estas práticas simples e com pessoas inteligentes, criativas e comprometidas – todos os projetos têm suas adaptações e ajustes necessários para um caminho de resultados reais, “tocáveis”.
Não há ferramenta ou técnica metodológica capaz de substituir o ser inteligente em um projeto de software, pela própria compreensão do que é método. Método no dicionário de língua portuguesa é definido como “procedimento, meio ou técnica para ser fazer alguma coisa de acordo com um plano”. Metodologia é um estudo dos métodos e não a imposição de métodos. Metodologia, para mim, deve ser a capacidade crítica de avaliação sobre uma técnica, se ela foi a melhor forma de se atingir o resultado esperado.
Estas informações que tratamos, não são técnicas setorias específicas adquiridas em instituições de ensino. São vivências maturadas globais resultantes da união de algumas especificidades técnicas, administrativas e humanas aplicadas aos projetos realizados.
Desejo muito sucesso em seus projetos.
Fabio Camara, MCP, MCSA, MCAD Charter, MCDBA e MCSD.NET – É Diretor de Operações da ArchITettura Soluções em Tecnologia e já entregou vários projetos ao longo de sua história profissional. Escreveu os livros “Projetos com Windows DNA e .NET”, “Dominando o Visual Studio.NET com C#”, “58+ Soluções em .NET” e “Orientação a Objeto com .NET” dentre outros.
