thegoodfellas/blogset-br huggingface dataset:
os contornos do projeto e tracar uma linha divisoria entre o que deve ser feito e o que nao deve ser, pelo menos neste momento. Muitos novatos se perdem em discussoes interminaveis sobre recursos do produto final que o tornariam perfeito. Sempre me lembro de um amigo muito experiente que, ante a minha ansia em acertar todos os detalhes logo de cara, me dizia que o otimo e inimigo do bom, ou seja: enquanto perseguimos o otimo nos distanciamos de algo que esta bem mais proximo, o bom, e que temos mais chance de conseguir atingir. Com o tempo achei uma forma elegante de contornar as exigencias de projeto sem decepcionar os clientes: nao e que nao faremos o que esta sendo pedido, mas devemos ver que este recurso cabe na versao 2, 3, etc... mas nao cabe na versao 1, que e o que estamos tentando desenvolver neste momento ! Afaste o fantasma da perfeicao.Para voce nao se perder numa lista interminavel de caracteristicas da versao 1, uma boa ideia e pedir ao cliente que liste so que o que e absolutamente essencial. Claro que se voce der a ele 30 minutos para responder, tudo sera absolutamente essencial. Nao adianta, temos de ser realistas, o tempo e curto e temos de escolher so o que realmente e importante. Se escrever e cortar como dizem os grandes escritores, a arte de se definir o escopo do projeto passa por saber o que abandonar e o que reter do universo de necessidades do cliente.Bom, definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas. O objetivo e chegar ao WBS (Work Breakdown Structure), onde temos as unidades de trabalho com tempo medido em dias ou horas de trabalho. Como regra, uma atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos.Em paralelo, deve ser elaborado um orcamento levando em conta quantas horas de cada profissional serao necessarias. Veja um modelo simples:ProfissionalTarefa 1Tarefa 2Tarefa 3T.Total (h)Custo/hCustoGerente de projeto200323150,003.450,00Lider de projeto10321580,001.200,00Analista Senior20002050,001.000,00Programador040206030,001.800,00Testador/Documentador020305015,00750,00Total---168-8.200,00Para montar este modelo, voce precisa saber o custo-hora de cada profissional e estimar o tempo que cada um gastara no projeto. Os profissionais podem estar envolvidos em outros projetos e quando o programador esta cuidando de uma fase do projeto A, o gerente de projeto ja pode estar planejando o projeto B, so voltando ao projeto A quando for para entregar ao cliente e obter a sua aprovacao, sobre o que falaremos mais adiante.Estas estimativas sao mais precisas a medida em que se avanca no detalhamento do projeto. Para estimativas iniciais, admite-se uma variacao de -25% a +75%. Na fase de planejamento, o orcamento deve ter uma variacao de -10% a +25%. Lembre-se que nesta fase, o gerente de projeto ja envolveu quem realizara a tarefa. Na estimativa final, a margem de erro e menor: de -5% a +10%. Aqui, o conhecimento do gerente de projeto de situacoes anteriores fara diferenca. Eu, por exemplo, sei que quando lido com determinados clientes, havera tanto overhead administrativo, como dezenas de reports para cima e para baixo antes que cada
passo importante seja dado, que eu ja estimo 50% a mais do tempo nas tarefas em que o cliente esta diretamente envolvido. Vai da experiencia do gerente, mas nessa hora, se a empresa tem um historico de projetos semelhantes, vale a pena se basear neste background, mesmo que tenha sido com outras equipes e outros gerentes de projeto.Um dos grandes segredos do gerenciamento de projetos e proteger o seu escopo. Projetos que ficam mudando o escopo durante sua execucao tem serias dificuldades em cumprir o cronograma e estouram o orcamento. O risco mais comum e o que se chama de scope creep, quando o escopo vai crescendo a medida que o cliente vai entendendo suas necessidades e reformulando seus objetivos. Ha quem chame este problema de Jacques. Seria uma homenagem a um frances ilustre ? Nao, trata-se apenas da forma como o cliente costuma abordar o assunto: ja que o sistema faz isso, ele pode entao fazer aquilo. Agora eu quero aquilo tambem incorporado ao projeto. O gerente do projeto deve ter calma e analisar com cuidado cada demanda: ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode estar dando um tiro no proprio pe, ja que o prazo e orcamento nao serao tao elasticos quanto as exigencias. Devemos sempre contar com uma certa margem de manobra, mas nos tempos atuais, em que eficiencia e a palavra que esta na ordem do dia, nao ha muita gordura para queimar e os compromissos assumidos pelo gerente podem se transformar num sacrificio, muitas vezes desnecessario, para toda a equipe.Em projetos de software, o scope creep e uma situacao tao comum que nao da para comeca-los sem tomar algumas precaucoes. O primeiro cuidado e negociar a forma de remuneracao: fixa ou variavel. Se for fixa, o risco das mudancas esta toda com o gerente do projeto, se for variavel, o cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja informado a priori dos novos custos. Por precaucao, eu sempre redijo um adendo ao escopo colocando o que sera feito, em quanto tempo e a que custo. Colho a assinatura do cliente e so depois autorizo a execucao da tarefa. Gerentes financeiros nao participam destas reunioes e podem alegar que nao ha previsao de recursos para os extras, entao mantenha-os informados das novas condicoes para evitar dissabores na hora do recebimento.O segundo cuidado e documentar meticulosamente o escopo do projeto. Este documento resume o que sera feito, com que caracteristicas e com que recursos. Ele e um quase-contrato mas nao traz as clausulas de rescisao e as penalidades. Neste momento, tudo esta bem e todos concordam. So que, na cabeca de cada um, ha uma imagem diferente do que sera o produto final. A medida que este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou nao e bem aquilo e podem comecar as decepcoes.A satisfacao do cliente depende em muito do que sera dito e prometido no que se chama de
pre-venda. E neste momento que o gerente de projetos deve entrar em cena para meticulosa, cuidadosa e disciplinadamente escrever tudo o que o sistema deve ter e fazer. Este processo e o planejamento de escopo e num software dele abrange das telas ate os relatorios. Esta tarefa pode ser delegada para um analista, mas a responsabilidade nao sai nunca das maos do gerente. Eu costumo especificar toda a interface dos usuarios com o sistema: telas e relatorios. Depois de colocar tudo no papel, o gerente deve obter do cliente um de acordo, de preferencia assinado no final do documento em que todas as paginas serao rubricadas com um visto para que ele tome ciencia do que sera feito. Nao ha palavras para expressar a importancia deste planejamento em que as expectativas serao levantadas e moldadas, de forma que, diante do produto final, o cliente nao possa se dizer decepcionado.O terceiro cuidado e definir prioridades. O gerente deve ter a sensibilidade para identificar quais sao os requisitos obrigatorios e quais os desejaveis, marcando cada um segundo com a sua prioridade. Isso evita que alguem arbitre o que e importante no lugar do cliente. Ha gerentes de projeto que vao mais longe e pedem ao cliente para definir o que ele considera sucesso do projeto. Por exemplo, num sistema em que havia desperdicio de 30% da materia-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este numero ainda e alto, diria voce. Sim, mas o cliente considerou que uma reducao de 50% dos desperdicios ja representaria beneficios suficientes que compensariam os investimentos no projeto. Alem do mais, lembre-se de que: o otimo e inimigo do bom.Em suma: definir o escopo, no fundo, e saber o que deve ser feito para atender a necessidade do cliente.4. Conheca os envolvidos e monte seu timeTodos os envolvidos no projeto sao os "stakeholders". Nesse grupo estao nao apenas os membros da equipe, mas tambem os clientes e fornecedores envolvidos. Dentro da empresa do cliente, ha uma pessoa que se destaca por ser a patrocinadora ("sponsor") do projeto. Ela e que cria as condicoes para a contratacao do projeto, mesmo que nao seja ela que va usar o produto final.E importante que o gerente do projeto conheca os interesses de todos os envolvidos. Imagine como e arriscado contar com um membro da equipe que nao esta disposto a colaborar. Ele pode ser um problema mais do que uma solucao dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei por uma situacao destas quando fui destacado para gerenciar um projeto onde havia um colaborador mais antigo e que entendia que ele e quem deveria estar gerenciando. Eu nao percebi seu ressentimento a principio e a medida que o projeto avancava esta pessoa se tornava um problema cada vez maior, na medida em que, nao so ele nao fazia a sua parte, como minava os demais membros da equipe contra minhas decisoes. Um dia, eu o chamei e abri o jogo. Ele entao me explicou o que estava sentindo e fizemos um acordo: ele se enquadraria
para completar o projeto, que gracas a ele ja estava atrasado, e eu o apoiaria junto a direcao para que recebesse seu proprio projeto para gerenciar. E claro que manter um profissional com este tipo de atitude nao e bom negocio para a empresa no longo prazo, porque cedo ou tarde ele vai acabar atirando contra a propria equipe novamente, so para mostrar que as coisas tem de ser feitas do jeito dele.No processo de definicao do escopo, as habilidades necessarias vao ficando mais claras. Nesse momento, e importante formar uma equipe com competencia diversificada e com experiencia nas areas de atuacao do projeto. Em projetos em que ha muito conhecimento tecnico envolvido, surge a figura do "lider de projeto", um profissional com grande conhecimento tecnico e com capacidade de lideranca entre os tecnicos. Em geral e um profissional senior, com credibilidade junto aos demais tecnicos e com muita bagagem. A experiencia desse especialista pode economizar muito tempo e dinheiro no projeto. De-lhe voz ativa, cobre dele insights que voce nao tem e respeite a sua opiniao. So assim ele estara sempre do seu lado, mesmo quando voce errar.5. Desenvolva o cronograma junto com quem poe a mao na massaUma vez que temos as tarefas definidas a partir do escopo, temos de estimar a duracao de cada uma. Procure fazer esta estimativa de tempo de execucao com a ajuda de quem esta escalado para executar o trabalho. Ao mesmo tempo em que essa pessoa e quem melhor sabe quanto tempo precisara, ela estara se comprometendo com um prazo para a sua execucao. Por outro lado, quando se trabalha com consultores externos, o custo sera funcao direta do tempo estimado para a execucao do projeto. Ao fixar o cronograma, o profissional esta dando por tabela um orcamento da sua parte.Veja estas atividades que representam as linhas gerais de um projeto de sistema:Note que alem de saber o que deve ser feito, as tarefas tem tres propriedades importantes: duracao, inter-dependencia e responsavel. A duracao e importante mas se as tarefas podem ser realizadas em paralelo, como e ilustrado neste caso onde ha duas figuras: o analista e o programador, a duracao total do projeto encurta. Dessa possibilidade de trade-off entre tempo e recursos alocados, alguns gerentes acreditam que se o projeto esta atrasado, entao basta colocar mais gente que o problema se resolve. Isso raramente ajuda uma vez que com mais gente, os problemas de comunicacao aumentam e o projeto que ja esta atrasado atrasa mais ainda. Trazer mais gente pode ser util quando se precisa de especialistas em temas que os membros nao dominem. A rigor, se o planejamento foi bem-feito, ja se sabe que esta mao-de-obra sera recrutada em algum momento do projeto. A atitude de simplesmente aumentar a equipe para acelerar a producao e que esta errada e deve ser combatida. So que alguns gerentes de projeto medem seu poder pelo tamanho da equipe que gerenciam. Voce pode imaginar como isso acaba: contratamos mais pessoas, eu fico mais poderoso e temos todas as explicacoes para os atrasos, afinal o projeto era
mesmo muito grande.O gerente de projetos deve trazer sua experiencia para corrigir as expectativas muito otimistas de algum colaborador mais afoito. Sim, ha quem estime 50 horas e depois, com a maior tranquilidade, cobre pelas 120 horas que foram necessarias para realizar a tarefa. Ele so errou em 140% ! Se o preco e fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a qualidade do produto final podem sofrer em decorrencia da pressa. Se a remuneracao ficar vinculada ao tempo de prestacao de servico, o contratante precisa de um mecanismo de controle minimamente confiavel. Eu nao uso uma formula geral, prefiro trabalhar segundo as caracteristicas do profissional mas de todos exijo um relatorio de horas que contem o dia, data de hora e inicio, tempo de trabalho e a(s) tarefa(s) realizadas no dia.Se no planejamento da semana ha tarefas que nao foram realizadas, na reuniao de avaliacao, eu pergunto porque a coisa nao seguiu o ritmo programado e quanto isso impacta na data final de entrega. Procure estabelecer pontos de controle, "check-points", que sao datas onde se medira o andamento do projeto em face do cronograma que havia sido programado. Nestas datas, pode-se estar apenas executando-se uma verificacao do progresso das atividades ("milestones") ou pode haver entrega de produtos ou sub-produtos (deliverables) tais como desenhos, especificacoes, prototipos, modelos, etc...Quem ja reformou ou construiu uma casa sabe que esta tao trivial experiencia de gerenciamento de projeto pode acabar mal. Quantas historias existem de gente que foi pagando o pedreiro sem atrelar os pagamentos a entregas de tarefas determinadas. Nestas historias tristes, o dinheiro acaba antes da obra, e o pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo porque ele nao cuidou de atrelar entregas de tarefas a pagamentos, nao criou pontos de controle que lhe dariam visibilidade do atraso. Sabendo antes que a vaca esta indo para o brejo o cliente pode optar por apertar o pedreiro ou suspender os trabalhos enquanto ainda tem dinheiro, que podera ser usado para pagar uma equipe mais eficiente.E verdade que em projetos de TI nem sempre da para trocar o pedreiro porque ha muito conhecimento e estudo envolvidos. Mas por isso mesmo, temos de ser muito mais cuidadosos na monitoracao para saber em que momento o projeto comeca a atrasar e como fazer para recuperar o ritmo no futuro proximo.6. Monitore os riscos e seja pro-ativoAgora que todos sabem o que devem fazer, e importante mitigar os riscos que podem impedir o bom desenvolvimento do projeto. Desenvolva uma lista de fatores de risco e um plano para lidar com eles. Mas lembre-se de que sao duas coisas diferentes: a monitoracao do risco e controle do risco.A monitoracao dos riscos envolve acompanhar o status de cada risco e as opcoes de acoes definidas para enfrenta-los, caso eles venham a se tornar problemas reais. A monitoracao tambem se preocupa em avaliar a probabilidade de ocorrencia de um risco, qual o seu impacto no andamento do projeto e como contorna-lo. Por exemplo, numa determinada tarefa critica a contratacao de
dois profissionais pode parecer um exagero mas o gerente do projeto sabe que se algo acontecer nesta area do projeto o impacto sera grande no restante. Os profissionais passam a ser um backup do outro dentro da linha de que quem tem um, nao tem nenhum.Voltando ao nosso projeto de exemplo, chamo a atencao para um recurso que o MS Project tem e que deve ser usado para se identificar riscos. Veja a tela do diagrama de Gantt que obtivemos a partir da lista de tarefas que elaboramos acima:Note que ha uma sequencia de tarefas que quando alinhadas compoem o prazo de duracao do projeto todo. Destaquei o inicio e o final so para que voce perceba que se trata de uma serie de processos que devem ser gerenciados mais de perto uma vez que o atraso em algum deles acarretara o atraso do projeto todo. Por isso e que se chama este de caminho critico. Os riscos que estao embutidos nestas tarefas sao os que se deve gerenciar mais de perto, de forma mais pro-ativa.O controle dos riscos e o processo de executar o plano de acoes e divulgar seus relatorios de status. Inclui tambem possiveis mudancas no plano de riscos, e eventualmente ate nos planos do projeto. Essas mudancas sao referentes a recursos, funcionalidades ou cronograma.7. Formalize o inicio e o encerramento do projetoO inicio do projeto e um momento solene. O patrocinador deve formalizar a todos os envolvidos que o projeto esta iniciado e o cronometro esta correndo. Muita gente nao gosta de se preocupar com isso, mas imagine que haja resistencia de setores da empresa que se opoem ao projeto. Sem um documento que atesta que o projeto comecou, o gerente pode nao conseguir apoio algum. Alem disso, este documento funciona como um cumpra-se de uma autoridade da empresa: nao cabe discutir a ordem, o projeto comecou e todos os arrolados devem participar.Outro momento importante e o do encerramento do projeto. E preciso formalizar o final para que fique claro para todos os envolvidos, especialmente para o cliente, que o projeto esta concluido e que novas necessidades serao atendidas em um novo projeto. Qualquer extensao ou alteracao devera ser orcada e todo o ciclo se inicia novamente. Com relacao a manutencao do sistema entregue, nao se pode considera-lo um projeto na medida em que, a principio, trata-se de um processo continuo. O que pode ocorrer e definir-se projetos ao longo da vida util do sistema com o objetivo de melhora-lo. Por exemplo, a atualizacao dos equipamentos eletronicos (avionicos) de um aviao para auxilio ao voo e um projeto que se distingue da sua manutencao rotineira.Ao final faz-se tambem uma reuniao de avaliacao dos erros e acertos da equipe. Chamadas de reunioes "post-mortem", elas servem para se gerar uma lista de "melhores praticas" contribuindo para a formacao de uma base de conhecimento que podera ser muito util em projetos futuros. Da minha experiencia pessoal, posso dizer que tirei grandes licoes quanto as "piores praticas", atitudes e decisoes que se mostraram ruins e que devem ser evitadas em projetos futuros.ConclusaoAcima
de tudo, gerenciar projetos e planejar e acompanhar a execucao com "um olho no peixe e outro gato". O gerente do projeto deve se manter alerta e flexivel com os acontecimentos do dia-a-dia mas deve estar sempre se reportando ao plano inicial para nao perder o controle. A principal qualidade do gerente de projeto e saber se comunicar bem com todos. Ele e o ponto focal das informacoes, nele convergem as informacoes que ele depois devera processar e divulgar para todo o restante da equipe.O segredo e envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente responsaveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, "quando todos empurram na mesma direcao, na ha carroca que nao saia do atoleiro".(*) Fernando C. Barbi (fernando@hexxa.com.br)Fernando e Gerente de Projetos especializado em TI com 18 anos de experiencia na area e colaborador da ADVANCE Marketing empresa de treinamento consultoria em gestao, marketing e vendas (www.advancemarketing.com.br)
partes, o checklist e o glossario. Tambem nesta versao foram introduzidas as secoes relativas a fraudes na Internet, banda larga, redes sem fio, spam e incidentes de seguranca.Na versao 3.0, de 2005, a Cartilha continuou com sua estrutura, mas, devido a evolucao da tecnologia, novos assuntos foram incluidos. Foi criada uma parte especifica sobre codigos maliciosos, expandida a parte sobre seguranca de redes sem fio e incluidos topicos especificos sobre seguranca em dispositivos moveis, como telefones celulares e computadores de mao. Esta versao tambem foi a primeira a disponibilizar um folheto com as dicas basicas para protecao contra as ameacas mais comuns.A versao 3.1 nao introduziu partes novas, mas incorporou diversas sugestoes de melhoria recebidas, corrigiu alguns erros de digitacao e atendeu a um pedido de muitos leitores: lanca-la em formato de livro, para facilitar a leitura e a impressao do conteudo completo.
determinismo linguistico fica exposto ao perceber o modo como o sujeito inicia sua producao no novo ambiente. Muitas vezes nem sequer chega a estuda-lo direito. Simplesmente cata a primeira IDE que encontra e comeca a trabalhar exatamente como fazia no ambiente/linguagem com o qual estava habituado.Armadilha #2: software = banco de dados relacionalO sujeito nao acredita que exista desenvolvimento alem do CRUD. Como detectar alguem que tenha caido nesta armadilha? Simples: mencione qualquer tipo de estrutura de dados diferente de tabela ou indice. Se disser que conhece, va alem: peca para que lhe descreva o funcionamento (alerta: criara inimigos com isto). Ou, pior ainda, pergunte ao individuo se ele consegue programar algo sem um banco de dados relacional por tras.O que ocorre nesta situacao: o sujeito trabalha em um ambiente no qual a esmagadora maioria das demandas consista apenas na criacao de aplicacoes que armazenem e busquem informacoes presentes em bancos de dados (apenas CRUD). No maximo, um relatorio ou outro mais complexo, envolvendo somatorios e agrupamentos. O que se percebe e a armadilha #1, ou seja, o determinismo linguistico. A diferenca e que este e O caso mais comum da armadilha E o que tambem causa os maiores prejuizos.Como o resultado de uma consulta SQL e imediato, o sujeito acredita que seu trabalho terminou na criacao dos formularios de exposicao e cadastro. No entanto, a partir do momento em que o problema se tornar mais complexo a coisa muda de figura.O mais fascinante desta armadilha consiste no fato da vitima conseguir fazer coisas incriveis com SQL, porem falhar miseravelmente quando precisar de qualquer coisa que va alem desta.Neste caso, no entanto, ha uma bomba relogio ativada: esta provado que os SGBDs relacionais nao escalam bem em ambientes paralelizados (mais sobre isto aqui, aqui e aqui(terceiro link particularmente interessante, por apresentar o CouchDB)). Como o numero de processadores por computdor esta aumentando, e o clock de cada um destes tende a diminuir e cloud computing esta crescendo MUITO, veremos problemas imensos de performance nos proximos anos cuja origem se encontra justamente neste tipo de profissional que acredita no mito de que uma aplicacao e composta por um banco de dados relacional apenas.Este tipo de individuo se esquece de algo basico: os dados sao o resultado de um processamento, e nao o contrario!Armadilha #3: ambientes de desenvolvimento RADO sujeito aprende a programar em um ambiente RAD e se atem a este. O utiliza para criar um CRUD simples, sempre utilizando a mesma linguagem (99% das vezes VB, Delphi e Visual Studio). Resultado: armadilhas #1 e #2 engatilhadas com um agravante: a ilusao de que desenvolvimento de sistemas e uma tarefa simples.Nao tenho nada contra estes ambientes (sendo assim, por favor, nao me ataquem), porem tenho contra o seu mal uso. O maior problema aqui ocorre quando se esquece que um ambiente como VB ou Delphi deve ser usado apenas para facilitar a execucao de tarefas repetitivas e tediosas, como por exemplo a criacao de um formulario, e que estas tarefas repetitivas e tediosas sao apenas uma PEQUENA parte do processo de desenvolvimento, e
de sistemas e uma atividade complexa, que requer estudo constante e que poucos conseguem leva-la a cabo com sucesso, ou seja: diminuindo a arrogancia.O artigo original veio do site abaixo, http://www.itexto.net/devkico/?p=292
transbordo Carrega qualquer tipo de nos portos; carga; Distancia dos centros de Menor custo de transporte. producao; Rodoviario . Adequado para curtas e medias Fretes mais altos em alguns distancias; casos; . Simplicidade no atendimento das Menor capacidade de carga entre demandas e agilidade no acesso as todos os outros modais; cargas; Menos competitivos para longas . Menor manuseio da carga e menor distancias exigencia de embalagem;