PCEO Main FormsIniciar, desenvolver ou concluir um projecto de uma aplicação Web, pode ser uma dor de cabeça quando não se seguem os passos necessários.

A metodologia escolhida, essa, já pode ser variável. Mas uma coisa é fundamental para garantir o exito e manter sob controlo um projecto: a disponibilidade de uma boa metodologia estruturada de abordagem do projecto (e o uso das respectivas ferramentas).

Parece estranho? Apenas para quem não sentiu já a dor de ver um projecto falhar ou resultar mal, por falta de planeamento e método na abordagem e desenvolvimento. Ou pior ainda, resultar com custos elevadissimos, que alguém tem que pagar.

O Projecto Falhou?

São tipicos os projectos que falham por

  • Falta de definição clara de objectivos, requisitos e especificações
    (“mas não foi isto que eu pedi” ou “mas esqueceram-se de…” diz o cliente, ou ainda pior, quando internamente membros diferentes da equipa não têm a mesma percepção do projecto e do trabalho a desenvolver), definição de requisitos (“mas isto é necessário ou não?” ou pior “mas com que detalhe vou desenvolver esta funcionalidade?”) ou especificações (“mas isto é para ser clicável ou não?”, “o servidor não suporta essa base de dados? Então e agora que se faz?”) .
  • Alvos móveis na definição do projecto e objectivos
    (o cliente telefona a meio do desenvolvimento: “lembrei-me de mais uma coisa, e se acrescentássemos…”, ou “…e se em vez disto fizessemos assim…”).
    Mas o perigo vem também das tecnologias, definições funcionais e arquitecturas: funcionalidades não suportadas, incompatibilidades, ou inconsistências só descobertas a meio do projecto e que obrigam a mudanças, perda de trabalho, recomeços, etc.
  • Indisponibilidade de recursos ou competências
    O mau planeamento não previu a sua necessidade, ou a data dessa necessidade! Depois a coordenação torna-se impossivel, os atrasos espalham-se como bola de neve por outras tarefas dependentes,  é necessário recorrer a recursos ou competências externas e os custos disparam!
  • Deslizes de prazo
    (funcionalidades definidas com pouco detalhe e que acabam por se revelar imensas no desenvolvimento, falta de recursos suficientes, dificuldades com as competências, deficiente avaliação da carga de trabalho, etc.) e conclusão demasiado tarde, quando provávelmente já as necessidades se alteraram…
  • Custos demasiado elevados
    (orçamentos feitos com base em sub-avaliação da carga de trabalho, novos requisitos que se revelam apenas após a orçamentação, necessidade de uso de tecnlogias não previstas, necessidade de recurso a competências externas ou sub-contratação, etc.)
  • Funcionalidades deficientemente ou nunca implementadas
    (“isso fica para a segunda fase…”,  “quero é isto a funcionar, depois acrescenta-se o resto”, “ninguem vai usar isso, deixem para depois…”) e projectos que por isso deixam de servir os propósitos iniciais ou acabam por o fazer deficientemente.
  • Deficiencias de concepção, impossiveis de resolver após as opções iniciais
    (imcompatibilidades tecnológicas, desadaptações funcionais, opções estéticas, de design, de imagem, arquitectura ou de interface inadequadas, etc.)
  • Deficiente comunicação
    – com o cliente e dentro da equipa, algumas vezes baseada numa deficiente definição do projecto
    (o cliente sabe do que estamos a falar? e o designer entende o que o cliente diz? o analista e designer falam do mesmo site? e quando falamos da funcionalidade X com o cliente sabemos exactamente do que estamos a falar, e o cliente endende exactamente a mesma coisa? Entendemos o negócio do cliente?)

Objectivos a satisfazer

E a metodologia de abordagem deve cobrir uma quantidade de exigências, sem as quais o projecto pode rápidamente resultar em fracasso, nomeadamente:

  • Discussão com o cliente
  • Definição de requisitos, e especificações
  • Definição de funcionalidades e tecnologias
  • Planeamento temporal e de recursos
  • Cálculo da carga de trabalho
  • Orçamentação
  • Organização da equipa
  • Suporte ao design grafico
  • Suporte ao desenvolvimento e programação
  • Controlo de desenvolvimento, resultados, custo e prazo
  • Acessibilidade
  • Verificações de conformidade e qualidade
  • Optimização funcional, grafica e SEO
  • Manutenção futura

Que abordagem?

Pert chart: diagramming how to print your own moneyPensar que uma boa estratégia pode ser partir directamente para a produção, só resulta, como em tudo, com projectos simples, pouco elaborados, pouco exigentes ou muito básicos. Na prática se conseguimos explicar o conceito numa frase simples, bom, talvez consigamos produzir sem preparação metódica. De qualquer modo restará sempre a questão: quão melhor poderia resultar, se tivesse sido mais preparado, pensado, analisado e projectado.

Mas que dizer de projectos com maior complexidade, com multiplas funcionalidades, com relações e interdependencias complexas? E que dizer quando, mesmo em projectos aparentemente simples, pretendemos atingir a máxima eficácia? Planear… planear acima de tudo.

Sobre metodologias, abordagens, estratégias e ferramentas de planeamento para a produção de aplicações ou de sites web já muito se escreveu. Geralmente são metodologias incrivelmente elaboradas, que tendem a apresentar soluções universais, mas rigidas, e tantas vezes retiradas ou extrapoladas de metodologias formais de desenvolvimento de sistemas bem mais complexos. Podem ser uteis, mas apenas em enormes projectos, ou para aqueles com grande suporte de recursos especializados, e fortes orçamentos.

Mesmo os métodos formais de especificação e analise de sistemas, podem ajudar a preparar a gestão de um projecto. E neste campo há muitas alternativas cada uma mais apropriada a um tipo de sistema. Mas todas estas metodologias tem uma certa tendencia a serem complexas e envolverem recursos especializados.

Na prática pouco ajudam, e são imcompreensiveis para o comum dos mortais, ou por nós que trabalhamos com pequenas equipas e prazos e orçamentos limitados. Em engenharia de software, projectos mais elaborados, trabalho com base de dados, raramente se consegue qualidade sem um conjunto de métodos formais e uma feroz gestão de projecto, mas não é o caso no desenvolvimento de pequenos projectos web.

Que fazer então quando tratamos de projectos mais simples, menos ambiciosos, limitados em orçamento e prazo, mas mesmo assim exigentes? Que fazer quando os projectos, como em todos os projectos web, envolvem grande componente de abordagem artistica, de design, de inspiração, não totalmente especificáveis com ferramentas lógicas?

Temos que adaptar. Temos que ser flexiveis, sobre regras bem sedimentadas, temos que ter abordagens bem estruturadas, e usar métodos adaptados. Temos que pensar.

Pode-se simplificar?

Não podemos efectivamente reinventar as metodologias existentes de fio a pavio, sem perda de coerência, e sem perda de informação. As metodologias existentes são matematicas, lógicas, completas em si mesmas, para resolver os problemas a que respondem. Simplifcar tira coerência e funcionalidade. Poderá haver outras possibilidades, mas não terão ainda sido enunciadas de forma sugiciente formal para poderem ser validadas. Há tipicos processos de gestão, aplicáveis também a projecto que não passam por estas metodologias (Kambam, quadro de marcações, calendário de recursos, etc) mas não respondem a todas as necessidades ou têm aplicação apenas em casos particulares e especializados.

Mas as metodologias de gestão de projectos, e as de especificação e analise de sistemas, são simplificáveis e adaptáveis se as compreendermos realmente! E neste campo não estamos a pisar terreno virgem… quantos foram já confrontados com esta necessidade antes de nós! Sobre este assunto veja-se  Gestão do projeto e da criação (do usuário) ou http://www.slideshare.net/arlindosantos/guia-da-gesto-de-projectos-web com algumas boas indicações.

Um bom livro sobre o assunto é também Web Project Management: Delivering Successful Commercial Web Sites.

Neste caso as ferramentas e os métodos têm que ser práticas, flexiveis e entendidas por todos, com diferentes formações e campos de especialização, do programador ao designer, do analista ao tester, do gestor de projecto ao comercial … e ao próprio cliente!

O planeamento tem que ser exacto e claro, mas muito directo e fácil. Diria quase que na maior parte dos casos, soluções bem mais naiv’s resultam melhor. Keep simple what’s simple…

Wireframes by lilit.Há uns tempos atrás li dois artigos de blog Time Tracking on Paper e Designing Web Sites Using Pencil and Paper que me impressionaram quer pelo obvio, quer pela simplicidade, e logo no momento tive a percepção de que em volta de ferramentas deste tipo se poderia desenvolver alguma metodologia simples de abordagem em trabalhos de pequena dimensão. Sobre este assunto veja-se até este extraordinário conjunto de formulários para a execução de sketches e o projecto grafico de um website: A Collection of Printable Sketch Templates and Sketch Books for Wireframing.

Depois descobri uma boa colecção de formulários para registo de tarefas e uso de tempo e recursos, que se encontra em http://davidseah.com/blog/the-printable-ceo-series/. E, é claro, um livro extraordinário que já se tornou um classico, “The One Page Project Manager” (O Gestor de Projectos de uma página”) que descreve o processo simplificado de gestão de projectos, baseado numa unica folha de planeamento e controlo. O livro é realmente extraordinário e vale a pena dar uma vista de olhos :

The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper

Claro que nem tudo fica resolvido e claro que de qualquer modo a metodologia seria bem informal, sem qualquer base exacta ou matemática, mas ainda assim…

Que podemos fazer?

Com base num conjunto de ferramentas artesanais deste tipo, parece perfeitamente viável que cada equipa crie uma metodologia simples e própria, baseada nas mais complexas e rigorosas, adequada à sua cultura empresarial e á dimensão de cada projecto. Claro que há um certo numero de regras que necessitam de ser pensadas e impostas. Mas esse pode ser um dos papeis do gestor do projecto, ou mesmo do analista.

E nesse aspecto, nos longos anos de gestão de projectos de software, aprendi a nunca esquecer algumas regras gerais de projecto (adaptadas, neste caso):

  • Definir claramente os objectivos, antes de qualquer trabalho iniciar (Definição de requisitos)
  • Definir claramente os papeis de cada interveniente (definição da equipa e competências, contactos e responsabilidades, incluindo as do cliente, etc)
  • Avaliar e definir claramente as funcionalidades e tecnologias (Especificações)
  • Dividir para conquistar (Divida-se o projecto em tarefas – use-se uma divisão hierarquica por fases e especialidades se necessários – e faça-se a análise de cada parte/secção, e projecte-se depois a sinteze, articulação e resultado final)
  • Avaliar claramente a carga de trabalho, competências e recursos necessários e respectivos prazos
  • Coordenar… competencias, recursos, tecnologias, prazos, datas
  • Planear e agendar rigorosamente tarefas, recursos e prazos
  • Planear rigorosamente pontos de avaliação do trabalho desenvolvido (milestones de projecto)
  • Controlar rigorosamente o desenvolvimento de prazos, carga de trabalho e produção
  • Avaliar rigorosamente desvios, relativamente ao planeado, no momento em que ocorrem
  • Reagir e avaliar imediatamente as consequencias dos desvios.
  • Acompanhar, coordenar e avaliar resultados parciais e globais
  • Documentar!

Fazer tudo isto de uma maneira informal é quase impossivel, mas com alguma disciplina consegue-se fazê-lo de forma simples sem quebrar as regras formais.

Os métodos formais de gestão de projecto ou de concepção de software podem ser uteis como pista, mas são rigidos e exigem muito trabalho adicional. Seja prático, mas siga regras.

Siga regras, para a gestão de projectos

A experiência ensina que apenas algumas regras são já suficientes para manter o projecto sob controlo.

Antes de iniciar o projecto, lembre-se:

  • Os documentos são meras ferramentas, não são um objectivo em si próprios, e devem ser mantidos ao minimo nivel de complexidade para serem uteis e não implicarem custos extra.
  • Envolver a equipa na gestão do projecto – A unica forma de manter uma equipa em funcionamento para obter resultados, é envolvê-la no controlo do projecto (prazos, especificações, realização de documentação e registo de ocorrências, etc.)
  • O objectivo do projecto é realizar bem o que foi especificado, no prazo util necessário, com o menor custo. E atingir isto é o unico fito do controlo do projecto.
  • O projecto deve servir o seu cliente. Fale com ele sempre que necessário, ouça-o, faça-se ouvir, mantenha-o a par de toda a sua evolução, e consiga a sua compreensão, acordo e validação (assinatura!) para cada opção, e em cada ponto de situação.

Antes de iniciar o desenvolvimento:

  • Comece por entender a encomenda, a espectativa e o “negócio” do seu cliente. Registe-o sintéticamente.
  • Prepare com o cliente um caderno de encargos que funcione como a definição de requisitos (não omita imposições legais, limites da organização, limites de orçamento e prazo, espectativas de resultados do trabalho, etc.)
  • Faça uma pré avaliação e uma estimativa de trabalho e custos.
  • Mantenha num arquivo/dossie único toda a documentação do projecto, incluindo notas/actas de reunião, documentos de definição e documentos de acompanhamento.
  • Prepare o arquivo de projecto para crescer ao longo do projecto (pode ser apenas uma pasta por projecto, ou um arquivo mais completo, dependendo da complexidade).
  • Seccione em três ou quatro partes lógicas: documentos de preparação, documentos de definição, documentos de acompanhamento do desenvolvimento (geralmente a parte mais volumosa) e documentos finais (inclua as validações, aprovações do cliente, documentos de sinteze e resumo de tempos totais de trabalho, de uso de recursos, de custos parciais e acumulados, documentação tecnica para uso futuro, eventuais manuais, e comunicação posterior com o cliente)

Na preparação do trabalho:

  • Prepare com o cliente um briefing de linha gráfica, de imagem e de interface. Não omita informações importantes (o pré-existente, a linha gráfica a usar, as pistas para o que se vai criar, as limitações estéticas, éticas, de marqueting, etc)
  • Faça um documento de analise funcional, que funciona como guia para o desenvolvimento, e aprove-o com o cliente.
  • Prepare um diagramas de arquitectura
  • Prepare os aspectos estéticos, de imagem, design e interface, envolvendo o cliente, e fixe-os em sketchs de wireframe ou mesmo em sketchs digitais
  • Identifique as competências e recursos necessários, carga e tempos de trabalho, tarefas e sua duração previsivel.
  • Orçamente e discuta o orçamento.
  • Feche o orçamento sempre. Nunca deixe que permaneçam indefinições. pode indicar custos horários, diários, opcionais ou custos variáveis, mas indique-os SEMPRE. E defina com o cliente se encomenda ou não as opções.
  • Detalhe e especificidade no orçamento – Seja claro a indicar que parcela de custo cobre que trabaho/serviço/funcionalidade, e vice versa. Assim pode decidir sobre opções, extensões e alterações ao trabalho, e rápidamente recalcular.

Na preparação do trabalho do projecto

  • Identifique todas as tarefas e prazos e fixe-as num documento
  • Prepare um diagrama PERT de todas as tarefas
  • Atribua as competências e os recursos necessários, e avalie a carga de trabalho
  • Prepare um cronograma das tarefas com indicação dos recursos necessários e carga de trabalho respectiva
  • Prepare um grafo ou quadro de carga de trabalhos, com indicação de recursos e competências ao longo do tempo
  • Calcule custos previstos exactos
  • Informe toda a equipa das competências e recursos envolvidos, tarefas, prazos e datas

Durante o desenvolvimento:

  • Registe e contabilize todos os tempos gastos, em que tarefa, por qual recurso.
  • Fiscalize a execução dos prazos e a ocupação dos recursos.
  • Faça pontos de situação frequentes com toda a equipa envolvida, e registe-os  em formulário de acompanhamento (tarefa por tarefa, por cada prazo do projecto, e por cada grande secção do projecto.
  • Detecte desvios, atrasos, erros e dificuldades precocemente, e encontre imediatamente soluções.
  • Registe todos os desvios e avalie custos. Encontre correcções eventuais possiveis (folgas, reaproveitamento, etc).
  • Projecte imediatamente as consequencias futuras (no cronograma e na coordenação de recursos, por exemplo) de atrasos, erros, dificuldades, alterações e omissões
  • Não admita alterações e novos pedidos, sem que fiquem claras (para quem pede e para quem aceita as alterações) todas as consequencias  – prazos, custos, etc.
  • Registe todas as alteração aos requesitos,  especificações, design ou arquitectura, individualmente e em separado (explicando e anotando para ajuda a interpretação futura) .
  • Identifique cada alteração aceite com um código individual e use-o!
  • Reverta todas as alterações aceites para os documentos do projecto, através de adições ou apendices (nunca com alterações aos documentos iniciais; se necessário crie um documento de registo de alteração). Identifique de quem foi a responsabilidade da alteração. Reflita-os em todos os documentos (cronograma, grafo de carga de trabalhos, planeamento de uso de recursos, etc.)
  • Valide TUDO – Use o documento de requisitos, o documento de analise funcional e o briefing e valide todos os desenvolvimentos face a estes (e possiveis documentos posteriores de alteração)
  • Envolva o cliente no acompanhamento do desenvolvimento do projecto: faça documentos de ponto de situação e comunique-os ao cliente, que os aceitará. Seja sintético, mas exacto.
  • Seja critico – SEMPRE (coloque-se no lugar do cliente, do utilizador final, do programador, do responsável pela manutenção do site, do designer). Assim evitará surpresas. Pergunte-se a si próprio o que lhe perguntarão ou o que terá que justificar. E responda.
  • Se nao entender um pedido, uma objecção, uma dificuldades, impossibilidades, atrasos, seja objectivo: pergunte e esclareça! Tome opções de solução ou compromisso, e registe-os como uma alteração. Nunca assuma que sabe do que se trata, ou que será aceite sem problema… esclareça sempre com todos os envolvidos! Comunique.

Após o desenvolvimento

  • Teste, avalie e valide, antes entregar ou disponibilizar. Envolva a equipa na validação.
  • Documente todos os resultados, identifique todas as falhas encontradas e todos os erros ou omissões
  • Resolva os problemas, se possivel, ou planeie de imediato a sua resolução.
  • Contabilize todo o uso de recursos, todos os desvios de prazo, carga de trabalho e custos (parciais e acumulados)
  • Identifique a parte de desvios de custos atribuivel a alterações pedidas pelo cliente (cobráveis) e as devidas ao planeamento, desenvolvimento de trabalho ou erros internos (incobráveis). Calcule a cobertura desses custos pela responsabilidade do cliente.
  • Sintetize o resultado obtido, saliente os exitos, não esconda os erros, omissões e dificuldades, e sintetize tudo num documento simples e objectivo.
  • Discuta o resultado com o cliente

Parece complexo? Não é!!!

Use formulários e documentos tipo

Uma revelação interessante que ao longo dos anos qualquer gestor de projecto tem: o controlo de um projecto pode ser feito com ferramentas informáticas, ou com documentação complexa; mas em projectos pequenos e médios o mais fácil é usar meia duzia de formulários simples, bem pensados e adaptados à tarefa, e uma boa organização de documentação.

Perca tempo a registar, datar, numerar e arquivar.

Projectos Geridos = Resultados

A grande vantagem de manter uma simples mas boa documentação de projecto é a capacidade de reacção imediata e a previsão de necessidade de intervenção, e a capacidade de responder a perguntas que certamente os gestores e o cliente vão querer fazer (há prioridades ainda não cumpridas? vamos usar a mais recursos para cumprir o prazo? vamos reduzir custos atrasando? vamos recorrer a recursos externos? qual a origem do aumento do custo final? qual a origem deste atraso? de quem é a responsabilidade? quem se responsabilizou por esta alteração ao inicialmente definido? porque mudámos de tecnologia a meio do projecto? porque retrabalhámos esta secção do projecto?).

Três ou quatro palavras chave na gestão de projecto:

  • Planear,
  • Acompanhar,
  • Avaliar e
  • Reagir a desvios.

E quatro palavras que simplificam esta gestão:

  • Documentar,
  • Simplificar,
  • Organizar,
  • Ser rigoroso

Sobre estratégias de abordagem de projectos web, veja-se a seguinte lista que reuni de bons recursos na internet:

Gestão de Projectos Web
Planning, Managing Web Sites and Web Site Projects
15 Project Management Apps That Help Make Web Development More Efficient
10 Useful Project Management Tools for Freelancers
SVET: Bringing order to project management chaos
33 Selected Blogs about Innovation, Project Management and 2.0: Vote for the Best!
Project Management 2.0 (Blog)
O que faz uma boa equipa?
ISO 9001 e a Gestão de Projecto.
http://www.slideshare.net/diogo_plta/metodologia-sugerida-para-gesto-de-projetos-web

Organização do projecto Web e do trabalho
12 Steps to Creating a Professional Web Design
The Eight Steps of Webdesign
Creating a web site – a step by step guide
Steps In Designing A Website
Strategic Design: 6 Steps For Building Successful Websites
7 Essential Guidelines For Functional Design
10 Principles Of Effective Web Design
5 More Principles Of Effective Web Design

Ferramentas Práticas Interessantes
Time Tracking on Paper
Designing Web Sites Using Pencil and Paper
A Collection of Printable Sketch Templates and Sketch Books for Wireframing

Métodos formais (software)
Formal Methods Wiki (Excelente!)
Nasa Formal Methodes Site (Contem dois excelentes Guide Books sobre Métodos Formais aplicados a software).
http://en.wikipedia.org/wiki/Formal_methods

euCliquei - compartilhe seus cliques