Como sabemos que os requisitos da solução estão concluídos?

Até onde é que podemos levar a Elicitação (escolha de requisitos) num projecto? Parece-me que, de forma definitiva, ninguém sabe a resposta. Será muito dispendioso capturar todos os requisitos, assunções, regras, relações e ligações escondidas associados à solução em construção. Então temos de ter uma forma de saber quando fizemos o que deve ser feito.

Conforme se elícita, analisa e documenta requisitos, devemos estar atentos à informação que a reunir e determinar o tempo que passa entre a descoberta de novos requisitos ou mudanças significativas aos requisitos existentes. Quando a duração excede um determinado limiar, então termine as actividades de recolha de requisitos – este é o processo de preparação de pipocas no microondas, ou a Via das Pipocas.


Este limiar pode, ainda, ser identificado com base num princípio de confirmação: Se, durante o processo de descoberta de requisitos se chega a um momento em que se continua a acumular informação mas esta não se traduz em novos ou alterados requisitos, então sabemos que devemos ter chegado ao fim.

Esta métrica é a solução melhor para situações em que no analista de negócio tem como propósito elicitar e documentar os requisitos de negócio detalhados quando o projecto possui “um charter definido com razoabilidade e objectivos de negócios claros”. Mas, é ainda útil, durante todo o ciclo de vida do projecto, quando se tenta definir âmbito e estabelecer requisitos de negócio para o projecto.

O desenvolvimento de requisitos é um processo iterativo, que se inicia a um alto nível de compreensão das capacidades requeridas, estas são então decompostas em componentes mais pequenos, que são por sua vez mais fáceis de tratar e desta forma determinar até que ponto estamos «terminados» em cada uma delas. Alguns exemplos do que pode ser tratado como componente independente, incluem:

• Definição do Âmbito – quais as capacidades que serão e que não serão incluídas no âmbito do projecto.
• Regras de Negócio – Regras referente à tomada de decisões operacionais que devem ser tomadas em atenção na solução.
• Modelos de factos – Modelos que representam conexões lógicas (“factos”) entre os conceitos centrais de uma solução e servem como representação do desenvolvimento subsequente de modelos de dados.
• Requisitos funcionais – As capacidades da solução – funções que a solução irá realizar ou permitir que os utilizadores o façam com o software.
• Requisitos não funcionais – Os critérios utilizados para ajuizar a qualidade da solução aparte os seus comportamentos específicos (requisitos de resposta em tempo, capacidade, confiança, usabilidade, etc.)
• Interfaces externos – Os interfaces para outros sistemas e entidades externas dentro do âmbito do projecto.

Esta não é uma sugestão de ordenação, antes a compreensão de que quando se trabalha em requisitos se realizam muitas actividades em simultâneo. Esta regra de economia permitir-nos-á saber com mais confiança qual a linha que estabelece que o trabalho está feito. Os riscos de parar cedo demais e falhar requisitos críticos, ou gastar demasiado tempo num dado conjunto de requisitos (gastando assim tempo valioso) são muito reduzidos quando damos atenção ao «silêncio dos requisitos» (o ponto em que mais informação não está a ajudar a identificar ou refinar requisitos).

Conforme o processo de requisitos se inicia, vai ficando cada vez mais confiante na forma como o problema foi definido quando vai verificando que os stakeholders das diferentes categorias e perfis concordam acerca do que é o problema e como a solução de sucesso irá ser. Passados uns dias e enquanto se vai adicionando e negociando detalhes dos requisitos, pode determinar-se que não houve mudanças no âmbito. Tal permite, por exemplo, declarar que a parte do âmbito do processo de gestão de requisitos está concluída, o que permitirá focar a atenção em outras secções ainda não investigadas.

Saber quando estão concluídos os requisitos para um projecto não é sempre fácil, mas encolher a dimensão dos seus objectivos é uma grande forma de reduzir a luta que sentimos. Ao estabelecer objectivos de menor dimensão e aplicando uma regra de «silêncio dos requisitos» para cada um destes objectivos separadamente, incrementará a capacidade de visão acerca da distância para a meta que se pretende atingir.
Luis Quintino

Documentar Corretamente as Decisões num Projeto de Construção

"Por favor, prossiga com as mudanças."

Essa frase familiar usada por muitos, mas não escrita ou documentada corretamente, pode causar grandes problemas. A documentação das decisões nos projetos de construção não apenas economiza tempo e dinheiro, mas também deve ser uma prática recomendada em todos.

Existem muitas ferramentas e recursos para usar e capturar decisões ou compromissos importantes, mas o que é considerado como tal? Como pode preparar-se para uma reclamação ou situação em potencial que precisa de documentação? Vamos sugerir algumas informações sobre como documentar adequadamente as decisões em projetos de construção.

O que são considerados «documentos importantes»

Para começar, precisamos definir o que podemos considerar como documentos importantes.
 

Plantas, desenhos de engenharia, e-mails, âmbito de trabalho e propostas são itens críticos que devem ser mantidos por muitos anos. Uma ótima maneira de alcançar o processo apropriado de retenção de documentos é usar sistemas para acompanhar as alterações e documentos. No entanto, às vezes é importante acompanhar e entender o contexto do diálogo. As cópias folha de pagamento e as coberturas do seguro também podem fazer parte dessa lista e as cópias originais das mesmas devem ser mantidas por um período maior de tempo.

Documentar as decisões

Em primeiro lugar, é imperativo estabelecer um plano de comunicação para garantir que as partes interessadas certas estejam conscientes e sejam notificadas das decisões. A decisão simples, como pequenas alterações no âmbito, é capturada por meio de comunicações informais, como cartas ou e-mails, antes de serem formalizadas e é assim, evidenciada-
 

Os ajustes do contrato precisam seguir a proposta e o âmbito é esclarecido, debatido e aceite por todas as partes, entre outros itens-chave relativos ao seu projeto. São todas estas coisas que se repetem e que devem ser documentadas.

Documentação de proposta e de Âmbito

Durante o processo de pré-licitação e pré-construção, muitas decisões são tomadas. São recebidos e-mails ou participará em teleconferências sobre quais novos âmbitos ou esclarecimentos são feitos e, assim que possível, precisará adicionar essas alterações ao âmbito e compartilhar essas informações com o dono do projeto ou o seu representante.

O processo de documentação deve conter estimativas, orçamentos, retiradas, informação de preços unitários, ofertas de fornecedores e encargos de trabalho que suportam os ajustes necessários.
 

Documentar as datas de quando você recebeu aprovação para emitir um pedido de compra é importante se precisar comprovar atrasos no material ou nos pedidos de compra associados às decisões. A documentação correta exigida para materiais e compras deve incluir a data de aprovação do material, pedido de compra e um documento com a data de entrega que o fornecedor está a indicar.
 

Para documentar essa decisão, o pedido de compra deve referenciar ou estar vinculado a uma seção específica do contrato e da especificação. Certifique-se de que o aprovador recebe e assina uma cópia, assim como o proponente, com anotação da data de aprovação e da data de entrega.
 

Isto merece uma atenção especial. Toda a vez que uma decisão importante é tomada, é imperativo registar ou produzir um instantâneo do cronograma real, documentando em que momento a decisão foi tomada.
 

Esse instantâneo pode servir como referência para documentar quaisquer mudanças no cronograma que são necessárias após a decisão. Neste ponto, o cronograma deve ser estabelecido e guardado em conjunto com a documentação exigida que fez parte do processo de decisão. Além disso, capture uma comparação entre a programação de pedido de proposta e a programação atual. Recomenda-se documentar duas semanas de antecedência e adicioná-las ao arquivo de mudanças.

Comunicações Diárias

Esta é outra questão importante a considerar durante o processo de documentação. Designe uma pessoa que possa armazenar e acompanhar os registos diários do projeto, notas de campo, condições climáticas, entrega, visitas oficiais do governo e conversas informais.

Esses arquivos devem ser mantidos e devem estar associados a datas e negociações afetadas pelo processo de decisão. Para cada questão, deve ser criado um registo separado e arquivado. Os registos de pedidos de mudança também devem ser mantidos e o registo deve incluir datas de vencimento, responsável, data de aprovação, especificações referenciadas e data de envio. Informações semelhantes devem ser registadas para desenhos, RFIs e especificações de projeto atualizadas.

Os carimbos de tempo normalmente são gravados na maioria dos documentos e os nomes legíveis são necessários para identificar quem recebeu ou assinou o documento, arquivo e / ou material. A hierarquia da equipe do projeto é importante para decidir se um gestor de projeto pode autorizar mudanças ou se precisa obter a aprovação de alguém superior na cadeia de comando.

Todos estes documentos devem ser mantidos e compartilhados com a equipe do projeto por meio de meios eletrônicos, desde que estejam disponíveis no futuro e sejam armazenados e documentados em ordem cronológica e por assunto.

Evidência Física

Com a mais recente tecnologia, recomenda-se gravar uma imagem aérea usando drone junto com fotos e outros vídeos, capturando recursos visuais sobre o status do projeto. Tire fotos em cada local antes do início do trabalho e continue o trabalho concluindo com uma revisão final após a conclusão do trabalho.

Essas fotos devem ser tiradas pelo menos uma vez por semana ou, de preferência, com mais frequência. Certifique-se que revê os documentos do contrato para se certificar de que seguiu o processo contratual para documentar as comunicações do projeto.

A delegação em Projeto

O sucesso na delegação de actividades é essencial para o êxito na gestão de projeto. Contudo, muitas das pessoas envolvidas como líderes em gestão de projeto têm medo da delegação. Eles receiam que, se delegarem, o trabalho este não seja correctamente realizado, que os prazos não sejam alcançados. Eles não confiam na colaboração e no trabalho de equipa e habituaram-se a fazer a maioria das coisas e controlarem directamente tudo o resto.

Mas o problema está na forma como fazemos a delegação – esta tem de ser feita de forma efectiva. A gestão de projetos depende simplesmente da delegação por força da lei da divisão do trabalho: uma pessoa ou equipa focada em uma ou duas atividades específicas é mais eficiente e produtiva que uma pessoa que tenta realizar simultaneamente uma multitude de atividades. Uma pessoa não pode ser todas as coisas para um projecto ou um negócio. Se a delegação for feita de forma adequada com facilidade se conclui que quanto mais de fizer o «laissez faire» em gestão de projeto melhor. No fundo que o melhor gestor é o que gere menos.


O sucesso da gestão de projeto depende da colaboração e do trabalho de equipa e a delegação bem-feita faz com que estes elementos em surjam com sucesso. Quais os cuidados que devemos ter para delegar quando gerimos um projecto?

Não seja vago – se está a gerir um projecto e se vai delegar actividades, deve ser bastante específico acerca do que se espera realizar com a actividade, quando é que deve ser realizado e o que se espera pela realização da actividade. As descrições vagas conduzem a resultados duvidosos e à falha em cumprir os prazos.

Garanta que estabelece prazos realistas – os prazos devem ser realistas e executáveis dentro do tempo pelas pessoas seleccionadas para a actividade. Obviamente, que a delegação envolve escolher as pessoas certas para as actividades certas de acordo com os seus talentos e competências, mas deve ainda assegurar-se que as pessoas que vão ser atribuídas às actividades não terão conflitos ou problemas de agendamento.

Fornecer toda a informação necessária a cada delegação – forneça aos que receberam a delegação uma direção para alcançarem os recursos que possam ser necessários para os tornar mais aptos a concluírem o trabalho em tempo. A colaboração e o trabalho de equipa podem estar entre estes recursos.

Garanta que está disponível como líder da gestão do projecto – os seus delegados devem ser capazes de lhe colocar quaisquer questões ou preocupações acerca do projeto ou das suas atividades. Adicionalmente, deve garantir que eles prestam contas o que exige relatórios periódicos. Contudo, não pressione demais. Um relatório semanal de status deve ser suficiente, desde que o projecto leve mais de uma semana a completar.

Está assumido que se delega actividades em gestão de projeto porque não temos tempo para fazer tudo por nós – Pode até ser que estejamos tão afogados que seja difícil dar instruções explícitas para as atividades. Se é este o caso, deve assegurar-se de delegar numa pessoa como o contacto directo e o gestor do projeto. Será responsabilidade desta pessoa ser o seu «braço direito» e quem terá a responsabilidade de fornecer as especificidades para os outros envolvidos para que possa haver êxito na colaboração e trabalho de equipa. Algumas vezes até a coordenação de uma parte de um projeto deve ser delegada. Se tal ocorrer, tenha o cuidado de realizar a delegação para alguém com experiência de gestão de projectos ou no tipo de trabalho que o projecto irá realizar.

Depois de ter delegado, lembre-se de manter as mãos fora do trabalho o mais possível – Permite aos que estão empenhados um espaço criativo no projeto. Deixe-os aparecer com as suas ideias próprias e fazer mesmo sugestões na forma de fazer as coisas melhor. O fundamental é que se obtenha os resultados desejados e o objetivo do projeto. Claro que a palavra final é sua na aprovação das mudanças às coisas, mas, ao mesmo tempo, não há necessidade de ser autoritário.

Para além dos relatórios de status mensais, implemente um processo de relatórios sobre o projeto – É muito importante ter acesso constante a informação sobre a forma como estão a realizar-se as coisas. Faça isto mas monte um sistema com pro-actividade em que as pessoas envolvidas no projecto se sintam confortáveis a actualizar os registos sem necessidade de marcar uma reunião.

Mantenha um registo pessoal sobre quem está a fazer e que atividade – registe todos os relatórios de status e detalhes de progresso. A manutenção destes registos mantém o seu pensamento sobre o projecto e garante uma dupla verificação dos seus detalhes.

Não se esqueça de louvar e mostrar o crédito quando as actividades são concluídas bem e em tempo ou quando se regista um bom progresso na atividade – os membros da equipa precisam de receber um feedback positivo quando estão a fazer as coisas certas. Não só merecem isso como esse reconhecimento ajuda-os a manter o foco, mantém-nos motivados e ajuda-os a compreender o que devem fazer.

Estes são alguns cuidados a ter quando delegamos actividades em gestão de projeto. A delegação não é uma coisa simples. Exige consideração, compreensão dos requisitos de projecto e um entendimento das capacidades e competências dos que colaboram connosco 
O trabalho de equipa e a colaboração conseguem-se se for feita uma delegação correcta desde o início. Através da delegação conseguimos guiar um projeto até aos seus resultados desejados, sem dores de cabeça, sem excesso de micro-gestão e com todos os envolvidos muito mais contentes e o projeto alcança o que todos desejam – o sucesso.