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
