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