Business Inteligence..

Business Intelligence

View more documents from Cristiane Rocha.

Um critério para saber se o meu projeto vale a pena

Meu projeto vale a pena?

Por MarcoGomes em 2009-Mar-04. 

Generalizando ainda mais, você pode se perguntar: – Devo continuar tentando resolver este problema desta maneira?

É muito comum que desenvolvedores passem batido por esta questão. O piores programadores acham que a primeira abordagem que encontram é a única maneira de resolver um problema.

Se você já se fez alguma das perguntas acima, ótimo. Não sei se há resposta definitiva, mas vou mostrar como eu me respondo.

Estabeleça um prazo e trabalhe com toda a sua energia até lá, depois faça uma estimativa da distância que se encontra do objetivo final, e se vale a pena continuar trabalhando no projeto.

Prazo claro e inadiável

Durante o desenvolvimento dos meus projetos de uma madrugada (insoniaware), eu seto uma meta: às 8 am vou parar de trabalhar neste projeto. Não importa o que estará pronto, eu vou parar. Se houver algo funcional, vai pro ar, se não é útil ainda, vai ter seu desenvolvimento interrompido por algumas horas pra que eu reflita um pouco.

Você pode estabelecer um limite de um mês para tocar profissionalmente um projeto pessoal, ou uma semana trabalhando diariamente com o futuro sócio. O prazo não precisa ser 8 am e a madrugada não é o único período produtivo do dia

Não empurre com a barriga

A maior importância desse prazo é estabelecer um momento exclusivo de reflexão; ele vai evitar que você vá “empurrando com a barriga”.

Empurrar com a barriga, porque já estava assim, fui fazendo e quando vi já estava todo enrolado são situações que sempre me deixaram frustrado. O item PPOG (Princípios da Programação Orientada a Gambiarras), da Desciclopédia define essa situação como “Faca nos dentes – O famoso vai fazendo aí!”.

Definir um prazo inadiável foi a maneira que encontrei pra não deixar meus projetos saírem do controle.

Getting Real

Projetos como o Wallpapr, Busica, Wallpapr for iPhone e Webriga (que fiz com o @mauricio) eram funcionais já nessa primeira parada obrigatória e foram pro ar, com bugs, mas foram.

O protótipo da boo-box, ImageDolly e AdBird não estavam funcionais neste primeiro checkpoint. O trabalho neles foi interrompido pela manhã (lembro como se fosse hoje) e era o momento de fazer uma reflexão se o projeto realmente valia a pena, e se aquela era a melhor maneira de resolver o problema.

Como você pode imaginar, tenho alguns outros projetos que nunca foram continuados. Achei que não valiam a pena ou que existiriam outras maneiras de abordar o problema.

 

Fases de Projeto

 

1. Fase de INICIAÇÃO – É a fase onde ” damos partida” oficialmente ao projeto através do Termo de Abertura, processo que, como todos os demais 43 do Guia, pressupõem Entradas, Ferramentas e Saída. Aqui, todos os envolvidos nesta fase reconhecem que um projeto ou fase deve começar e se comprometem para executá-lo.

2. Fase de PLANEJAMENTO – É a fase responsável por detalhar tudo aquilo que será realizado pelo projeto, incluindo cronogramas, interdependências entre atividades, alocação de recursos envolvidos, análise de custos, etc., para que, no final dessa fase, ele esteja suficientemente detalhado para ser executado, sem dificuldades e imprevistos. Nessa fase, os planos auxiliares de comunicação, qualidade, riscos, suprimentos e recursos humanos também são desenvolvidos.

3 – Fase de EXECUÇÃO – É a fase que materializa tudo aquilo que foi planejado anteriormente. Qualquer erro cometido nas fases anteriores fica evidente durante esse processo. Grande parte do orçamento e do esforço do projeto é consumida nessa fase.

4- Fase de CONTROLE - É a fase que acontece paralelamente as de Planejamento e Execução. Tem como objetivo acompanhar e controlar aquilo que está sendo realizado pelo projeto, de modo a propor ações corretivas e preventivas, no menor espaço de tempo possível, após a detecção de anormalidade. O objetivo do controle é comparar a “Linha de Base”, levandada no início do projeto (Estado Inicial), o seu status real no momento (Estado Atual), com o status previsto pelo planejamento (Estado Desejado), tomando ações corretivas em caso de desvio.

5 – Fase de ENCERRAMENTO – É a fase quando a execução dos trabalhos é avaliada através de uma auditoria interna ou externa (terceiros), os livros e documentos do projeto são encerrados e todas as falhas ocorridas durante o projeto são discutidas e analisadas para que erros similares não ocorram em novos projetos e, melhores estratégias são identificadas e selecionadas como “lições aprendidas”. Aqui, se formaliza a aceitação do projeto ou fase e encerra-se de uma forma organizada, o projeto solicitado.

 

Resumindo, diria que para mim, exitem 3 fases de gerenciamento: Iniciação – Planejamento/Execução/Controle – Encerramento.

Inicio da fase de Implantação

Após algum tempo sem novidades no Blog a Corpora TI volta a atividade blogueira com novidades a respeito de projetos. Esta semana foi iniciada a fase de implantação e testes do projeto do programa de Geranciamente para estabelecimentos de educação Infantil. Este sistema consegue gerenciar todas informações pertinentes a rotina diária da escola, com o adicional da tecnologia de Biometria para controle de pontos e presenças tornando o gerenciamento dos alunos e funcionários mais precisos.

Em breve estaremos publicando imagens dos sistema.

Interessou ???

Envie um e-mail para contato@itcorpora.com.br

Especificação funcional – Estrutura do documento (2ª parte)

Bom, depois de um longo tempo, volto a tratar de especificação funcional, agora abrangendo mais o documento em si, já que a nossa última conversa (apesar do adiantar do assunto nos comentários) foi somente uma breve introdução do assunto.

Percebi que muitas pessoas chegaram até aqui pelos mecanismos de busca, procurando informações sobre o tema, então novamente gostaria de informar que a estrutura e o estudo aqui proposto é um conjunto de práticas que, com a minha experiência acadêmica e profissional, entendi que são as mais próximas da realidade de um projeto de software. Conforme o passar dos anos e adquirindo mais experiência com o tema, certamente mudarei alguns pontos de vista, talvez até todos. O aprendizado contínuo derruba alguns paradigmas e isto é natural.

A conversa agora parece supérflua, mas não é. Conversaremos sobre a estrutura do documento de especificação funcional, que deve ser o padrão no projeto. A principio “padrão” e “estrutura” parecem remeter ao mesmo sentido, então vamos tirar as possíveis dúvidas:

• Padrão: quando digo padrão quero dizer que existe um modelo de documento a qual sua empresa ou você irá adotar para especificar funcionalmente todas as necessidades do seu cliente.

  Todos os documentos partem deste modelo, que possui uma estrutura comum, ou seja, todos seus documentos de especificação funcional serão reconhecidos e identificados pela mesma forma.

  Se há equipes diferentes que terão como meta a especificação de documentos funcionais de partes ou módulos diferentes de um mesmo sistema, os documentos de saída de cada equipe deverão possuir a mesma padronização.

  Você deve pensar: “Mas isto é muito lógico para ser explicado”, concordo! Mas geralmente existem diversos tipos de especificação funcional dispostas para um mesmo projeto, principalmente se existem diferentes equipes trabalhando diferentes frentes. É importante que logo no início do projeto este documento seja apresentado como padrão;

• Estrutura: logicamente se é determinado um padrão, a estrutura também é padronizada, ou seja, é padrão para todos os documentos terem a mesma estrutura. Mas a estrutura a ser padronizada deve ser organizada de uma forma clara, objetiva e estruturada para que os processos vindouros após a finalização da especificação identifiquem as soluções propostas deste documento.

A meta então é debater uma estrutura para a padronização do documento de especificação funcional.

Primeiramente é importante definir a formatação da documentação, processo simples para os editores eletrônicos de textos atuais, como a escolha da fonte e o tamanho (recomendo Times New Roman com 12pt), margens, tabulações, cabeçalho e rodapé, títulos e subtítulos. É necessária a paginação, de preferência no formato “página atual/quantidade de páginas”.

Agora vamos falar sobre a estrutura em si, esta estrutura foi pensada com partes básicas de um projeto, porém projetos variam de necessidade, ou seja, um projeto de desenvolvimento de software tem necessidades e particularidades diferentes de um projeto de estruturação de rede, pense neste documento como ele realmente deve ser: uma forma de explicar o que deve ser feito para resolver um problema. Se a estrutura do documento está estruturada de uma forma a gerar dúvidas em seu entendimento que dirá o desenvolvimento da solução.

Esta estrutura pensada está ordenada da seguinte forma:

A capa: Ela deve conter as identificações básicas, porém importantes para o documento, que são: nome e/ou logo da sua empresa, o título do documento: “Especificação funcional”, descrição do projeto, se houver divisão do projeto por partes da solução deve-se colocar a descrição da parte da solução (Exemplo: Projeto: Controle de Locadora, Frente: Controle de estoque), Autor(es) do documento.

Índice: básico.

Controle de versão: deverá iniciar em 0 ou 1, com o nome do autor da versão, data de atualização da versão e motivo da atualização. Cada mudança na especificação funcional deverá conter o registro de versões para nortear as mudanças de escopo dentro do documento de especificação funcional.

Descrição da solução: este é a parte principal do documento, é onde será solucionado o diagnóstico do cliente, nos ateremos em breve a este conteúdo.

Quadro de referências: contém as palavras ou termos utilizados no documento que não são de conhecimento do cliente. Como o cliente deverá assinar este documento ele deverá também entender os termos descritos neste.

Convenhamos que em diversas vezes usamos termos técnicos ou particulares para identificar uma solução ou um processo específico e o cliente não necessariamente precisa sabê-los. É importante então referenciarmos o que significa estes termos quando usados no documento, nesta sessão.

Por exemplo: “O cálculo do valor do aluguel será prorrateado quando da entrega antecipada em número de dias”. O que é prorrateado? Este termo para este caso deverá ser explicado nesta sessão do documento.

Anexos: Algumas vezes utilizamos de outros documentos para diagnosticar e especificar a solução, portanto estes documentos são as bases desta análise. É importante anexar estes documentos nesta sessão para talvez justificar posteriormente alguma lógica de solução. Recomendo o anexo das atas das reuniões no projeto.

Aceite: É o local onde será selado o pacto entre cliente e desenvolvedor.

É a assinatura de ambos que significa: O cliente entendeu o documento e concorda que o quê está escrito resolve seu problema e que o desenvolvedor terá que lhe entregar tudo o que está descrito neste documento. É a aprovação do contrato.

Basicamente (ufa) entendo que estes são as principais divisões da estrutura de um documento funcional, se você entende diferente ou entende que existem mais necessidades a serem citadas como importantes neste documento, não deixe de comentar, lembre-se que esta série de matérias é um bate papo entre eu e vocês sobre algo que temos em comum: a necessidade de entender melhor nosso cliente e fazer melhor aquilo que será a menina dos olhos dele.

Novo dominio da Corpora no ar.

Foi adquirido recentemente o dominio http://www.itcorpora.com.br. Este dominio será o novo endereço da empresa na internet, assim como os e-mails passarão por mudanças. Não deixe de acessar o blog pois aqui todas as informações referentes a Corpora são publicadas e você fica sabendo o que está se passando na empresa assim como pode entrar em contato se o nosso serviço corresponde a solução de sua necessidade. Entre em contato, teremos prazer em atendê-lo.

Especificação funcional – Entendendo o desejo do cliente (Parte 1)

Você trabalha com desenvolvimento de soluções em tecnologia da informação? Então você vai entender direitinho o que eu estou falando!

Com a sua licença pelo trocadilho: cliente é como mulher, você pode até saber do que ele precisa, mas geralmente não sabe o que ele realmente deseja.

Sim, acredite em mim! Não é por maldade ou por falta de vontade que isto acontece. Talvez por uma deficiência na comunicação, talvez por dificuldade de expressão, talvez por falta de conhecimento da necessidade, enfim, centenas e centenas de motivos para que isso venha a acontecer.

Se você está do outro lado, como salvador da pátria, senhor das soluções há muito esperadas ou o responsável em deixar a vida de um monte de gente mais simples, amigo… Você convive com um problema e tanto.

Independente do tamanho do seu cliente (não tamanho físico, mas sim corporativo) ele está pagando por um desejo e você recebendo para realizá-lo. Se você não entende perfeitamente este desejo, provavelmente não entregará a solução correta ou pelo menos completa. E convenhamos, se isto acontecer você realmente está encrencado, pois qualquer que seja sua solução para este problema, será um prejuízo. Seja seu (mais provável), seja do cliente.

Por mais que isto é claro, muitas empresas não dão o devido valor para uma fase do projeto: o levantamento de requisitos para elaboração da especificação funcional.

Se você já é experiente em gestão de projetos ou já participou de alguns, pode pular os três próximos parágrafos, caso contrário, explicarei resumidamente o que seria este levantamento de requisitos na especificação funcional.

Podemos dizer que a especificação funcional é o primeiro documento a ser elaborado quando o projeto e software é iniciado, ou seja, após a sua viabilidade ser aprovada. Para não restar dúvida sobre este conceito, vamos abrir o leque e entender corretamente estes termos:

Projeto de software é uma execução de tarefas exercidas em um determinado tempo por um ou mais pessoas que tem por objetivo um resultado específico. Ele tem início, meio e fim. Envolve tipicamente a análise, especificação, o projeto (design), desenvolvimento, testes e/ou manutenções dos componentes de software e documentação associada.

A especificação funcional é o documento que contém o que o sistema deverá processar quando da sua entrega. Ele é um contrato contendo o que deve ser feito pelo prestador e o que será entregue ao cliente. Este documento é o coração do projeto.

Tendo entendido perfeitamente que é projeto e percebido a importância da especificação funcional, inicio aqui a primeira parte destas matérias sobre especificação funcional.

Adianto logo que os conceitos aqui expressos por mim são baseados em minhas experiências com o tema e não levantarei qualquer tipo de bandeira (CMM, PMBOK, Etc.) por mais que alguns de meus conceitos são graças a estas técnicas. Quero bater um papo sobre esta fase tão importante da vida do projeto.

Gostaria que os leitores deste humilde blog participassem com suas opiniões, experiências e visões sobre gestão de projetos, principalmente na expecificação funcional.