Nesta curta série de posts vou tentar listar algumas atitudes que acredito contribuirem para um projeto bem sucedido. Não são de forma alguma suficientes ou mesmo necessárias, mas são coisas que a minha vivência e o bom-senso me dizem aumentarem a probabilidade de um final feliz. Não falarei aqui de aspectos técnicos; eu ousaria dizer que eles são secundários frente às atitudes que vou mencionar.
Devo alertar que a minha experiência é predominantemente com projetos de software de um porte que chamo de "médio" (duração inferior a um ano com uma equipe de até três pessoas). É provável que estas ideias se apliquem a outros tipos de projeto, mas não posso afirmar por experiência própria.
Vou considerar três pontos de vista:
- Da empresa sendo contratada para executar o projeto (empresa)
- Da empresa que está contratando o projeto (cliente)
- Do profissional alocado pela empresa para executar o projeto (desenvolvedor)
Escopo Bem Definido
A primeira coisa importante é existir um escopo bem definido desde o momento da contratação. Uma fonte comum de aborrecimentos para todos os envolvidos são renegociações durante o andamento do projeto provocadas por divergências entre o que faz parte ou não da negociação inicial.
Pode parecer absurdo, mas negócios envolvendo valores significativos são fechados com frequência sem uma proposta formal. O combinado fica espalhado entre documentos desatualizados, e-mails escritos às pressas e a memória dos envolvidos.
Mesmo um documento formal pode ser pouco útil se não tiver uma descrição razoável do meu escopo. Um dos meus primeiros sustos como profissional, quando trabalhava em um fabricante de hardware, foi ser alocado para o projeto de um produto novo e descobrir que o contrato estipulava apenas o preço e a quantidade de peças. Não existia nem mesmo uma lista sucinta de características técnicas ou funcionais. Felizmente, este caso teve um final feliz graças a pessoas entusiasmadas e bem razoáveis dos dois lados. No entanto o risco foi imenso, bastaria ter uma pessoa menos flexível de um dos lados para surgirem questionamentos que o contrato não resolveria.
Comprometimento com o Término
Pode parecer óbvio que quando as duas partes fecham um negócio, e um desenvolvedor é alocado a um projeto, que todos estão interessados em conduzir o projeto até o final. Nem sempre isto acontece. Seja por "outras prioridades", brigas políticas internas ou simples "picuinhas", uma ou várias das partes pode se desinteressar do projeto. O projeto acaba se tornando um exercício de desatolar a vaca do brejo.
Se não existe um desejo forte de levar até o fim, é melhor nem começar. Vai poupar dinheiro e paciência de todos.
Pensar Em Todas As Etapas
Existe uma tendência a se concentrar em determinadas etapas do projeto e ignorar todas. Etapas tipicamente menosprezadas são testes, treinamento e implantação.
Ritmo e Acompanhamento
Um projeto médio é como uma prova de atletismo de meia distância: um ritmo bom e constante é muito melhor que alterar corridas desenfreadas e paradas. A forma de se verificar o ritmo é através do acompanhamento periódico do projeto.
Honestidade e Franqueza
Seja por insegurança, seja por má-fé, muitos projetos se afundam em meias-verdades e mentiras completas. Honestidade e franqueza requerem tanto coragem de quem fala como a compreensão de quem escuta.
Talvez seja ingenuidade minha esperar uma total honestidade; fico satisfeito se pelo menos mentiras irrelevantes forem evitadas.
Um Bom Projeto É...
Distinguir um bom de um mau projeto é mais ou menos como distinguir o lado bom e o lado negro da Força. Como diria Yoda, quando você está entusiasmado, calmo, receptivo a críticas e sugestões e percebendo as coisas andando, você está num projeto bom. Descaso, raiva, intolerância e a sensação de estar atolado sinais de um projeto ruim são.
Nenhum comentário:
Postar um comentário