DevSecOps

8 dez, 2010

Templates são a resposta ou as respostas são os templates?

Publicidade

Em algumas publicações minhas no blog da Qualidata, empresa onde atuo, e em artigos que o Marcelo Costa publicou aqui no iMasters, iniciamos uma discussão sobre as desvantagens no uso de templates, além da amarração e estagnação que estes podem causar. Em decorrência disso chegamos a iniciar uma discussão sobre uma nova
abordagem para o gerenciamento dos nossos projetos que, basicamente,
consistiria na definição de perguntas que deveriam ser respondidas por
cada projeto seguindo o modelo que este achar melhor, ou seja, queremos
substituir o uso de templates por uma abordagem mais dinâmica e que dê
maior liberdade e fluidez ao processo. Além do fato que templates e
documentações em geral servem pra dar uma série de respostas que a
empresa, o gerente e o cliente precisam. Portanto, se gerenciar
basicamente é responder perguntas, por que precisamos amarrar como estas respostas devem ser dadas?

Tenho amadurecido um pouco mais a ideia e estou cada vez mais convencido de que isso poderá trazer grandes benefícios. Ainda não pudemos colocá-la em prática por uma série de motivos, mas mesmo assim quero compartilhar com nossos leitores o que tenho pensado.

Primeiramente vamos tentar definir como seria essa abordagem e que tipo de controle gostaríamos de ter. Além disso quero destacar que não tenho me amarrado a nenhum modelo especifico de gerenciamento ao idealizar essa abordagem, portanto não imagino perguntas do tipo: “Como é feita a descrição de caso de uso no seu projeto?”. Afinal, não sei se no projeto em questão será ou não necessário esse tipo de documento.

Como empresa, não precisamos ter um documento com casos de uso bem escritos nos nossos arquivos. Em vez disso, no momento de idealizar essas perguntas, estamos mais preocupados no “porque” das coisas, e nesse momento acredito que, para esse caso, a pergunta certa seria: “Como você garante que a sua equipe compreende corretamente os requisitos do cliente?”.

Baseado nesse conceito, também podemos notar que as respostas em geral não serão objetivas, cabendo analise e discussão entre a empresa e o gerente de projeto.

É importante limitar a fronteira do que é responsabilidade do projeto e o que é da empresa (nesse artigo, estamos pensando na realidade de uma empresa em questão e estamos cientes que esta pode ser bem diferente em outras empresas).

Acredito que aspectos como a arquitetura a ser utilizada, padrões de código, condições de trabalho da equipe e até mesmo a qualidade de código são responsabilidades da empresa definir e controlar.

Tendo isso em mente, vamos listar algumas das perguntas que, na visão da empresa, eu gostaria de discutir com cada projeto. Vale destacar que as perguntas abaixo tem objetivo apenas de exemplificar o conceito.

01.  Como você garante que sua equipe entende corretamente os requisitos?

Essa acredito ser uma das perguntas mais complexas, que pode inclusive ser desmembrada, afinal nela queremos saber coisas como:

  • Como é feito o levantamento de requisitos em seu projeto?
  • Como o cliente valida e entende o que foi levantado?
  • Como você controla se o que está sendo produzido pela equipe atende o que foi especificado?
  • Como são registradas as principais decisões do projeto?

02.  Como é feito o controle das mudanças no decorrer do projeto?

03.  Como o cliente interage com essas mudanças?

04.  Como os prazos externos e internos ao projeto são definidos?

05.  Como você controla esses prazos definidos?

Poderíamos até idealizar mais algumas perguntas, mas pensando em um projeto pequeno e levando em consideração que, por enquanto, nosso objetivo é apenas passar a ideia, acredito que já temos uma amostragem interessante – que abrange um leque grande de possíveis respostas para cada pergunta.

Os agilistas terão seus métodos, os mais conservadores já possuem outros, alguns mais inovadores talvez venham com propostas bem diferentes para cada projeto. E realmente é este o objetivo: extrair o que cada equipe e o seu gerente tem de melhor além de somar isso à experiência da empresa. Para esta, o objetivo maior é o sucesso do projeto e a experiência que este pode trazer para os processos internos.

Acredito que uma abordagem desse tipo pode trazer alguns benefícios muito relevantes para a empresa pois faz com que o gerenciamento dos projetos não seja feito no “piloto automático”, minimizando o risco de se tomar decisões erradas pelo vício.

A próxima etapa é a conquista da valorização da individualidade e a forma de trabalho de cada equipe, além da liberdade para experimentar e inovar que uma abordagem mais flexível pode propiciar.

É claro que uma empresa tem certos princípios e uma experiência que não se deve ignorar, mas de forma nenhuma esta deve estar ausente nesse processo. Pelo contrário, é algo que deve ser feito em parceria. Só assim será possível maximizar os benefícios para o projeto, a empresa e, consequentemente, o cliente.