Em toda corporação existe a necessidade de se criar algumas ferramentas para facilitar, ampliar, gerenciar ou simplesmente monitorar alguma coisa. Com o intuito de fazer as coisas acontecerem rapidamente as vezes descuidamos de alguns passos fundamentais para o sucesso de nossas aplicações.

O intuito deste post é detalhar um pouco sobre como gerenciar um projeto de forma eficaz, tentando sempre priorizar a solução em sua maneira mais integra possí­vel. Abaixo irei descrever o que julgo por um bom gerenciamento de projetos. As informações aqui são com base em estudos vistos na faculdade e expêriencias vividas ao longo de minha carreira profissional.

Saber e conhecer o máximo possível sobre o que se trata o projeto é o detalhe mais importante e mais esquecido quando se trata de começar um projeto. Em muitos casos o cliente não sabe exatamente o que ele quer, ele sabe que há uma deficiência em um determinado procedimento mas não sabe ao certo a origem desta falha, a maneira que ela ocorre e até se ela realmente ocorre. É ai que vem o papel do gerente de projetos, nesse momento deve se entrevistar o cliente, questionar coisas que podem parecer absurdas em um primeiro momento mas que podem fazer toda a diferença no decorrer do projeto. Tratar o cliente de maneira tentar retirar o maior numero de informações possível de todo o seu processo, desde a entrada de uma simples solicitação verbal à alguem até a o fluxo final dos impactos dessa solicitação.

Pense em uma situação aonde o seu cliente precisa controlar o estoque de um determinado produto. Para saber exatamente do que se trata a solução que o cliente precisa, não basta saber que ele quer controlar estoque, deve se indagar o porque de ele querer essa solução, quando questionamos o cliente é ai que ele realmente explica a sua necessidade, muitas vezes de maneira confusa. Mas nessa resposta dele pode surgir algo como “Possuo um grande numero de fornecedores para um mesmo produto e preciso saber quanto comprei de cada fornecedor para poder negociar uma próxima compra”. Olha que informação importantíssima você acaba de ter, o cliente não queria apenas um sistema de entrada e saída de produtos em uma base de dados, mas sim um sistema aonde ele tenha controle sobre todos os seus fornecedores, aonde ele consiga emitir uma ordem de compra que futuramente irá gerar uma entrada de estoque. Ele também quer ter relatórios aonde ele consiga saber quanto, quando e como ele comprou o produto com um determinado fornecedor. E se prestarmos bastante atenção em cada detalhe daquela simples frase ainda iremos achar muitas outras coisas que podem auxiliar o seu cliente no simples controle de estoque.

Dei esse exemplo para mostar o quanto é importante saber as necessidades do cliente. Sem essas informações muito provavelmente o orçamento gerado, os prazos estipulados e a satisfação do seu cliente seriam fortemente abalados, gerando futuramente “dores de cabeça” com renegociações.

Após entender as necessidades do cliente, deve se desenhar ou escrever, de maneira bem simples de facil entendimento, o fluxo de todo o processo apontando momentos críticos e exemplificando como a solução irá atender à cada detalhe do processo. Tendo esse esquema em mãos temos que mostrar para o cliente como uma forma formalizar para o que o sistema se propõe e de que maneira ele irá resolver todo o processo. Assim que aprovado o fluxo da solução e a maneira como ele deverá servir ao cliente, devemos levantar os custos de analise, desenvolvimento, implantação, treinamento e manutenção da solução.

Em posse das necessidades do cliente, iremos começar a desenhar os diagramas propostos pela UML(Unified Modeling Language). Julgo de maior necessidade os diagramas de caso de uso, classes e se necessário o diagrama de sequência de um ou outro processo mais complexo. Não irei entrar em detalhes de o que cada diagrama significa e como devem ser feitos, existem documentações bem mais técnicas e completas que podem ser encontradas em sites e em livros específicos sobre UML.

Outro ponto excencial é a elaboração de um banco de dados baseado nos padrões de entidade e relacionamento. Lembro que com um banco bem estruturado temos um ganho significante no desenvolvimento de todo e qualquer projeto. Sabendo como dispor e documentar cada entidade e seus relacionamento temos uma forte ferramenta durante todo o decorrer do projeto. Em próximos posts irei detalhar algumas das boas práticas sobre o desenvolvimento de banco de dados.

Tendo os diagramas e o banco de dados, a vida do projeto e da solução está quase que cem porcento garantida. A partir dai é botar a mão na massa sempre lembrando de documentar todo o processo de desenvolvimento, e se a linguagem escolhida permitir, utilizar os padrões de OO(Object Oriented ou Orientação a Objetos) contando com reaproveitamento de códigos, encapsulamento, hierarquia, e outros recursos que a OO nos oferece. Alguns desses tópicos de OO também serão tratados em posts futuros.

E para finalizar no momento da implementação basta ter bastante cuidado pra que tudo funcione como o programado e com base em toda a documentação gerada durante todo o projeto devemos elaborar um manual com telas e linguagem bem simples para que os usuários não tenham maiores problemas na hora de utilizar o sistema.

No related posts.

Postar um comentário