Caro Emerson.
Gostaria de agradecer as dicas sobre planejamento. A "gordurinhas"
foram muito �teis. Aqui na empresa cometemos o erro de n�o coloc�-las no
projeto de migra��o de servidores e agora estamos correndo para poder
entregar tudo dentro do cronograma.
Nunca mais vou esquecer de deixar os projetos bem gordinhos para que
tudo saia como planejado.
Gustavo
-----Mensagem original-----
De: Ribeiro Emerson Gomes [mailto:[EMAIL PROTECTED]
Enviada em: sexta-feira, 13 de maio de 2005 11:41
Para: M�rcio In�cio Silva; Lista Debian-User-Portuguese
Assunto: RE: Custo de projeto
Precisando, � s� falar.
Emerson
-----Original Message-----
From: M�rcio In�cio Silva [mailto:[EMAIL PROTECTED]
Sent: sexta-feira, 13 de maio de 2005 10:31
To: Lista Debian-User-Portuguese
Cc: Ribeiro Emerson Gomes
Subject: Re: Custo de projeto
Em Sex 13 Mai 2005 10:08, Ribeiro Emerson Gomes escreveu:
> Ol� lista,
>
> Obrigado, fico feliz por ajudar...
>
> Vamos por partes:
> >Voc� poderia me dizer qual o metodo mais seguro para avaliar as horas
> >do projeto (ou realmente tem que ser com a experi�ncia propria) ou um
> >livro ou link que fale sobre isso.
>
> Existem muitas t�cnicas e conceitos. Eu, particularmente, n�o acho que
> gerenciamento de projetos tenha receita de bolo (como muitos gerentes
> pensam). Eu tento me apoiar em tr�s pilares:
>
> 1) Detalhar as tarefas ao m�ximo. Nada deve ser esquecido. Quem aqui
> j� teve a oportunidade de fazer um plano de neg�cios para abrir um
> novo neg�cio sabe do que estou falando. � chato, � massante, mas �
> necess�rio...Isso porque os problemas sempre acontecem no detalhe...
> Dificilmente vc vai ter uma tarefa do tipo: Criar cadastro de clientes
> e um problema do tipo: n�o foi poss�vel criar o cadastro de cliente. O
> problema vai parecer mais com: O bot�o de impress�o do cadastro de
> clientes n�o funciona. Detalhe tudo...
>
> 2) Conhe�a sua equipe. Sinceramente, se tem uma coisa que me tira o
> sono � n�o conhecer quem vai desenvolver os programas. Eu sempre tento
> trazer gente de minha confian�a... Quando n�o d�, eu dou uma
> investigada na qualidade do servi�o da pessoa. Tento descobrir 4
> coisas: a - quanto essa pessoa conhece do ambiente que est�
> trabalhando (linguagem, banco, etc..) b
> - como � a l�gica dessa pessoa (desconfie de quem faz "IF NOT" com "ELSE")
> c - O n�vel de capricho dessa pessoa (coment�rios no fonte,
perfeccionismo,
> esmero...) d - como anda a rela��o dela com a companhia e seu n�vel de
> motiva��o.
>
> 3) Reaproveite c�digo. Al�m de agilizar o desenvolvimento, voc� pode
> por aquele programador mais limitado apenas para juntar pe�as. Coisas
> triviais devem ser reaproveitadas, para evitar que de�m erro. No mundo
> ideal, existiria uma �tima classe visual e n�s desenvolver�amos apenas
> a camada de neg�cios...
>
> >Por exemplo: Para fazer uma tela de cadastro de clientes, geralmente
> >o tempo de de 12 a 16 hs, so que, mesmo separando tudo em
> >micro-tarefas, sempre h� confus�o na hora, devo levar em conta a
> >cria��o do banco, a cria��o de todas as classes e fun��es ou devo
> >levar em conta que nessa hora j� devo estar com todas as classes e
> >fun��es prontas al�m � claro do banco.
>
> Acho que voc� deve se aprofundar mais nas tarefas. Essas "confus�es"
> que voc� citou, devem ter sido causadas por coisas que voc� n�o
> conseguiu imaginar antes. Leve em considera��o a cria��o de todos os
> **m�todos** de todas as classes. Quando voc� estiver listando os
> m�todos de uma determinada classe, vai perceber problemas que n�o
> perceberia se fizesse
> apenas: Classe de clientes - 4 horas. Leve em conta a cria��o do banco:
que
> vai fazer a modelagem?, quem vai revisar a modelagem?, quem vai gerar o
> script?, quem vai executar?, quem vai dar os grants?, quem vai criar os
> usu�rios?, Quem vai inserir clientes de teste ? quando cada uma dessas
> pessoas vai ter tempo de executar essas tarefas ? Qual o plano B se uma
> delas der errado ? Ai voc� aproveita essa lista de tarefas e escreve duas
> ou tr�s linhas sobre cada uma. Ao final voc� ter� uma bela documenta��o do
> projeto. Se algo der errado, volte nessa documenta��o e veja o que vc n�o
> conseguiu prever. Acrescente esse item no pr�ximo projeto. Claro que tem
> coisas que s�o imprevis�veis: enchentes acontecem, o programador pede a
> conta, a m�e de algu�m morre... Por isso deixamos gorduras ao final de
cada
> macro tarefa...
>
> >N�o sei se estou sendo muito claro, o que eu gostaria mesmo � de
> >saber a forma mais correta de fazer o "c�lculo" das horas que vou
> >gastar no projeto.
>
> Clarissimo :-). N�o � um c�lculo.. � um desafio de futurologia... A
> matem�tica n�o resolve isso.
>
> >Ps.: Mesmo usando o Planner para programar e acompanhar todas as
> >etapas e saber o inicio, fim e tempo do projeto, ainda assim na hora
> >de colocar o tempo de cada tarefa ainda fica tudo meio que empirico
> >:-)
>
> Vc precisa muito mais que o Planner, o dotProj ou o M$-Project...
> Escreva muito... Tente se imaginar executando a tarefa e liste todos
> os passos em um documento. Tente imaginar o que deve ser feito e o que
> pode n�o dar certo. Esse documento dever� virar a especifica��o da
> tarefa, que vc entregar� ao programador como base. Vc pode pedir a
> ajuda deles para fazer isso. Quando n�o conseguir mais ouvir falar do
> assunto, � hora de atribuir tempo e recurso as tarefas. � mais f�cil
> atribuir tempos a coisas pequenas. Deixe gordurinhas em cada
> micro-tarefa. Guarde seus cronogramas/especifica��es j� executados.
> Utilize-os como base para os pr�ximos. Isso faz com que atribuir tempo
> fique menos emp�rico. Mas lembre-se da hist�rinha sobre confiar na
> equipe.
>
>
> Abra�os
> Emerson
Obrigado amigo, foi muito esclarecedor e resolveu varias de "minhas"
pend�ncias.
Qualquer coisa tamos ai!!!
Um abra�o.
--
___________________________________________________
EAS Tecnologia e Informa��o - http://www.eas.com.br
M�rcio In�cio Silva - [EMAIL PROTECTED]
� � �.~.
� � / v \ � Seja Livre, use GNU/Linux! �
� / ( � ) \
�^^-^^ � � � GNU/Debian/Linux
