DC - DINSMORECOMPASS
  • Home
  • Quem somos
  • O que fazemos
    • Outsourcing
    • Consultoria
    • Educação Corporativa
      • Turmas abertas e EAD
    • Ferramentas
  • TEAL® - Trein. Experiencial
  • Insights
    • Esteiras de Gestão
    • Did You Know?
    • Pesquisa DC
    • PM CASE DAY 2023
    • PM CASE DAY 2024
    • Artigos
    • YouTube
  • Vagas
  • Contato
    • Institucional DC
  • Livro Gerenciamento de Projetos Aplicados
  • Home
  • Quem somos
  • O que fazemos
    • Outsourcing
    • Consultoria
    • Educação Corporativa
      • Turmas abertas e EAD
    • Ferramentas
  • TEAL® - Trein. Experiencial
  • Insights
    • Esteiras de Gestão
    • Did You Know?
    • Pesquisa DC
    • PM CASE DAY 2023
    • PM CASE DAY 2024
    • Artigos
    • YouTube
  • Vagas
  • Contato
    • Institucional DC
  • Livro Gerenciamento de Projetos Aplicados
DC - DINSMORECOMPASS

Liderança Antifrágil: Enfrentando o Caos e Crescendo com Ele

10/10/2024

0 Comentários

 
Fotografia
A ideia de liderança antifrágil surge em um momento de profunda transformação nos ambientes empresariais, sociais e políticos. Vivemos em um mundo onde a incerteza, o caos e os choques externos são constantes. Nesse cenário, como os líderes podem não apenas sobreviver, mas também prosperar? O conceito de antifragilidade, proposto por Nassim Nicholas Taleb no livro Antifrágil: Coisas que se Beneficiam com o Caos (2012), oferece uma nova perspectiva de como os líderes podem transformar a adversidade em um catalisador de crescimento.
 
O que é Antifragilidade?
 
No núcleo do conceito de Taleb está a distinção entre três estados de ser: o frágil, o robusto e o antifrágil. O frágil é aquele que se quebra sob pressão, o robusto resiste às adversidades, mas não melhora, enquanto o antifrágil é o que cresce e se fortalece diante da desordem. Como Taleb afirma: "Algumas coisas se beneficiam com choques; prosperam e crescem quando expostas à volatilidade, aleatoriedade, desordem e fatores estressores." A antifragilidade, portanto, vai além da resiliência, que se contenta em resistir ao caos; o antifrágil prospera em meio a ele.
 
Na liderança, essa característica é crucial em tempos de crises e mudanças abruptas. Um líder antifrágil não apenas resiste aos impactos, mas aprende e se adapta de maneira a se fortalecer com cada desafio.
 
O Líder Antifrágil
 
Liderar em um mundo caótico exige muito mais do que habilidade técnica e visão estratégica. Requer uma mentalidade que abrace a incerteza e veja as dificuldades como oportunidades para crescimento e inovação. Taleb explica que a antifragilidade é a capacidade de absorver choques e se tornar melhor por causa deles, o que significa que líderes antifrágeis são aqueles que veem no imprevisível uma chance de aperfeiçoamento contínuo.
 
Algumas das principais características dos líderes antifrágeis incluem:
 
1. Aceitação da incerteza: Em vez de buscar controlar o incontrolável, esses líderes abraçam a aleatoriedade como parte inerente do ambiente. Como Taleb diz: "A incerteza é a alma de qualquer progresso verdadeiro." Eles entendem que a previsibilidade total é uma ilusão e, portanto, se preparam para o imprevisível.
 
2. Tomada de risco consciente: A antifragilidade envolve a capacidade de tomar riscos calculados. O líder antifrágil não é imprudente, mas também não evita o risco a todo custo. Em vez disso, explora oportunidades onde a assimetria está a seu favor: pequenos riscos com grandes potenciais de recompensa.
 
3. Mentalidade de aprendizado contínuo: Esses líderes estão sempre buscando se adaptar e aprender com seus erros e sucessos. Eles veem cada crise como uma oportunidade para adquirir novas habilidades e conhecimento, o que os torna cada vez mais capazes de lidar com futuras incertezas.
 
4. Descentralização e delegação: Taleb argumenta que estruturas centralizadas são mais frágeis, enquanto organizações distribuídas tendem a ser mais antifrágeis. Líderes antifrágeis promovem a descentralização do poder, permitindo que suas equipes tenham autonomia para tomar decisões e inovar. Essa abordagem distribui o risco e aumenta a capacidade de adaptação da organização como um todo.
 
O Papel da Liderança Antifrágil nas Organizações
 
Uma organização antifrágil é aquela que prospera em tempos de volatilidade, em grande parte devido à mentalidade e às práticas de seus líderes. No ambiente corporativo moderno, cheio de inovações disruptivas e mercados instáveis, líderes que adotam uma postura antifrágil ajudam suas organizações a não apenas sobreviverem, mas a se destacarem em tempos de crise.
 
A adaptação é a chave aqui. Como Taleb afirma, "O antifrágil ama a aleatoriedade e a incerteza, o que significa – crucialmente – amar os erros, uma certa classe de erros." Esse tipo de liderança encoraja a experimentação, a iteração e a aceitação de pequenos fracassos como parte do processo de crescimento. Em vez de temer o erro, o líder antifrágil o vê como uma ferramenta valiosa de aprendizagem.
 
Além disso, a liderança antifrágil promove um ambiente de inovação contínua. Quando uma organização e seus líderes são flexíveis e abertos ao novo, eles são capazes de explorar rapidamente oportunidades que surgem em momentos de desordem.
 
Reflexões Finais
 
Liderança antifrágil é um convite para revisitar a maneira como concebemos o papel do líder em tempos de crise. Não se trata apenas de sobreviver aos desafios, mas de emergir deles mais forte e mais preparado. Em um mundo onde a imprevisibilidade é a única certeza, os líderes que desenvolvem uma postura antifrágil têm uma vantagem distinta.
 
Como Taleb conclui: "Você quer se beneficiar do erro, do acaso, da incerteza. Antifrágil é aquilo que cresce quando exposto ao caos." Esse é o novo paradigma para os líderes que não apenas aceitam o caos, mas o transformam em combustível para o sucesso.
 
Esses líderes não são aqueles que apenas resistem, mas aqueles que, ao se adaptar e aprender com a volatilidade, guiam suas equipes e organizações a um crescimento contínuo. É esse tipo de liderança que se faz essencial em um futuro cada vez mais imprevisível.
 

0 Comentários

Gerenciamento de Requisitos e suas Etapas (3  etapa)

13/9/2024

0 Comentários

 
Nesta terceira e última parte, trataremos da análise, documentação, verificação, validação, monitoramento e controle dos requisitos, e avaliação da solução. (Confira a parte 1 aqui e a 2 aqui)
Uma vez elicitados, os requisitos de um projeto devem ser analisados e documentados. Entre os fatores que contribuem para o sucesso dessa etapa, estão a utilização de pessoas qualificadas, a boa comunicação e a colaboração entre os participantes. Ao se analisar os requisitos elicitados, devem ser definidos atributos que permitam a classificação e posterior rastreamento dos requisitos ao longo do projeto. São exemplos de atributos comuns de requisitos: ​

-Data de criação 
-Fonte (parte interessada) 
-Dono (owner
) 

- Prioridade 
- Versão 
- Status 
- Entrega ou Épico associados ao requisito 
- Critério de aceitação 

 Esses atributos devem ser documentados juntamente com a descrição do requisito num Registro de Requisitos, o que permitirá também sua rastreabilidade, como no exemplo abaixo: 
​
Fotografia
De particular importância é a utilização de um conjunto de status para os requisitos, o que auxiliará no acompanhamento do ciclo de vida do requisito ao longo do projeto, como no exemplo abaixo. 
 
Fotografia

​Uma documentação consistente de cada requisito permitirá um monitoramento adequado e a validação da solução entregue. Uma descrição de requisito bem formatada consiste dos seguintes elementos: 

- Condição (opcional) 
- Sujeito 
- Verbo ativo no futuro 
- Objeto 
- Regra de negócio (opcional) 
- Resultado (opcional) 
 
Exemplo: 

Quando o usuário clicar no novo botão “inserir conta” [condição], o sistema [sujeito] exibirá [verbo ativo no futuro] a nova tela de inserção de conta [objeto] permitindo a criação de uma nova conta [resultado]. 

No caso de projetos adaptativos onde se utilize o modelo de história de usuário, o formato será próprio: 

Como [Determinado stakeholder ou persona], quero [objetivo ou intenção] para poder [valor esperado]. 

Exemplo: 

Como gerente de portfólio, quero selecionar os projetos por departamento para poder tomar decisões de acordo com o perfil de cada departamento. 

Após a documentação, é necessário verificar os requisitos para garantir que estejam propriamente redigidos e livres de erros. Isso pode ser feito por meio de revisão de pares e inspeções. Uma verificação bem-sucedida requer que certas características de qualidade na descrição de requisitos sejam conhecidas e seguidas. As características a seguir estão presentes em requisitos bem escritos: 


  • Não Ambíguo: O requisito tem um significado unívoco e é interpretado da mesma forma pela audiência pretendida. Exemplos: 

- Requisito ambíguo: Quando o empregado passar pelo leitor, o sistema identificará o empregado. 

- Requisito não ambíguo: Quando o empregado posicionar o dedo indicador de qualquer uma das mãos no sensor de leitura de digital, o sistema mostrará a foto do empregado no monitor. 

 
  • Consistente. O requisito não contradiz nem duplica outros requisitos. Quando uma mesma entidade é citada em vários requisitos, as palavras utilizadas para se referir a ela devem ser as mesmas.

Exemplos: 

Linguagem inconsistente entre requisitos: 

3.2.1: O sistema de segurança deverá... 

12.4.6: O novo sistema de segurança deverá... 

17.5.3: O sistema de cartão de segurança deverá... 

25.3.7: O sistema de cartão de segurança de RF deverá... 


Linguagem consistente entre requisitos: 

3.2.1: O sistema de segurança deverá... 

12.4.6: O sistema de segurança deverá... 

17.5.3: O sistema de segurança deverá... 

25.3.7: O sistema de segurança deverá... 


  1. Correto. O requisito representa corretamente a funcionalidade a ser construída conforme definida pela parte interessada ou por outra fonte de requisitos. 
 
  1. Completo. O requisito inclui a informação necessária e condições válidas para que se desenhe, se construa e se teste a solução. Exemplos: 

 - Requisito incompleto: A sessão de login deve ser encerrada após o número de senhas incorretas ultrapassar o máximo permitido. ​  
 - Requisito completo
: A sessão de login deve ser encerrada após três tentativas de senhas incorretas. 
 

  1. Mensurável. O requisito pode ser comprovado ou verificado por meio de análise, teste, inspeção ou demonstração. Exemplos: 

    - Requisito não mensurável: A nova linha de produção deverá ser eficiente.   
    - Requisito mensurável: A nova linha de produção deverá produzir em média 5000 tampas de garrafa por dia. 
 
  1. Viável. O requisito pode ser implantado respeitando-se as restrições conhecidas (por exemplo, custo e prazo) e as capacidades do ambiente (por exemplo, tecnologia e conhecimento da equipe). 
 
  1. Rastreável. O requisito possui um identificador único, pode ser referenciado ao longo do seu ciclo de vida e rastreado em relação a outros elementos do projeto (fonte, entrega, épico, responsável etc.). 

Num ambiente adaptativo, onde os requisitos são tipicamente representados por histórias de usuário, o acrônimo INVEST pode ser aplicado para garantir a qualidade da descrição das histórias. O acrônimo é derivado das iniciais das seguintes palavras: 

  1. Independente. A história de usuário deve ser autônoma, evitando a criação de dependências entre histórias de usuários. 
 
  1. Negociável. A história de usuário deve estar sujeita a negociação em relação a seu conteúdo, prioridade, forma e função. 
​
  1. Valiosa. A história de usuário deve definir características e funções que tragam valor para o negócio e contribuam com a solução de problemas ou captura de oportunidades. 
 
  • Estimável. A história de usuário deve ser clara o suficiente para permitir a geração de uma estimativa válida ou proporcionar discussões que resultem numa tal estimativa. ​

  • Simples (Small). A história de usuário deve ser pequena o suficiente para ser implantada numa única iteração. 

  1. Testável. A história de usuário deve ser verificável de maneira independente. 
​
 
Com os requisitos documentados e verificados, é importante que se faça uma validação com quem gerou o requisito, para garantir que cada requisito reflita de maneira precisa a intenção da parte interessada. 

Tipicamente percorrem-se os requisitos documentados em conjunto com as partes interessadas para confirmar se os requisitos, conforme descritos, são válidos, e se entregarão o valor desejado. 

A etapa de monitoramento e controle dos requisitos pode ser dividida em certas funções realizadas de maneira iterativa ao longo do projeto para garantir que a documentação de requisitos continue válida. As funções do monitoramento e controle são apresentadas na figura abaixo: 
​
Fotografia
Definir Linha de Base de Requisitos. Uma vez que os requisitos e seus atributos associados tenham sido documentados e validados, é crítico que sejam aprovados. O conjunto de requisitos aprovados para um projeto formam a linha de base de requisitos. Quando se usa uma abordagem adaptativa, o processo de aprovação é iterativo e focado no planejamento de cada iteração com a definição de seu backlog. 
 
Monitorar Requisitos
. O monitoramento dos requisitos consiste em acompanhar e manter atualizado o status de cada requisito ao longo do projeto. 

 
Gerenciar Mudanças nos Requisitos
. O processo para gerenciar mudanças nos requisitos deve ser definido de antemão, ao se planejar o projeto. Gerenciar mudanças envolve seguir o processo definido para que os requisitos aprovados só sejam alterados se os protocolos de controle de mudança forem seguidos. No caso de métodos adaptativos, a flexibilidade é maior, e requisitos podem ser inseridos no backlog do produto e repriorizados para cada nova iteração. 

 
Documentar e Comunicar Resultados
. A comunicação do status corrente dos requisitos do projeto deve ser feita periodicamente para as partes interessadas, o que ajudará a gerenciar as expectativas e a manter um bom nível de colaboração. 

 Uma vez que a solução é desenvolvida, é necessário que seja avaliada. A etapa de avaliação da solução determina quão bem a solução atende às necessidades das partes interessadas. 
A avaliação da solução é realizada geralmente ao final do ciclo de vida do projeto (em abordagens preditivas) ou ao final de cada iteração (em abordagens adaptativas) por meio de testes ou demonstrações do produto. 



Este artigo faz parte do Programa Esteiras de Gestão da Academia DC. Clique aqui, faça sua inscrição e acesse gratuitamente vários conteúdos online para aperfeiçoar suas habilidades gerenciais! 


Referências bibliográficas: 
BORGES, Carlos; MERIGUETTI, Cezar; ROLLIM, Fabiano; Gerenciamento de Projetos Aplicado. 2ª ed. Rio de Janeiro: DC, 2024 

PROJECT MANAGEMENT INSTITUTE. Requirements Management: A Practice Guide. Newton Square: PMI, 2016. 
 PROJECT MANAGEMENT INSTITUTE. Business Analysis for Practitioners: A Practice Guide. Newton Square: PMI, 2015. 


 
0 Comentários

Gerenciamento de Requisitos e suas Etapas (Parte 2)

8/8/2024

0 Comentários

 
Nesta parte 2 de nosso artigo, vamos detalhar a elicitação de requisitos e suas técnicas. Confira a parte 1 aqui neste link.

O processo de elicitação é mais do que coletar e reunir requisitos. Os requisitos não estão “prontos” nas mentes das partes interessadas ou em outros documentos, esperando para serem coletados e reunidos. É necessário um esforço para transformar desejos e necessidades em requisitos claramente elicitados.
Alguns fatores contribuem para o sucesso de um processo de elicitação de requisitos, particularmente um bom planejamento e preparação da elicitação, o engajamento ativo dos envolvidos, clareza na definição da necessidade de negócio e conhecimento do assunto por parte dos envolvidos na elicitação.
Uma ampla gama de técnicas está disponível. Essas técnicas podem ser utilizadas isoladamente ou em conjunto para se alcançar o resultado desejado. Algumas técnicas comumente utilizadas são:

  • Análise de Documentação. Várias informações podem ser obtidas por meio de revisão e análise de documentação existente. Essa documentação pode incluir planos estratégicos e de negócios, fluxogramas de processos, termo de abertura do projeto, documento de visão, registros de questões ou problemas, normas, regulamentos, políticas, procedimentos e outros documentos que ajudem a descobrir requisitos. Essa técnica pode funcionar como um ponto de partida na elicitação e uma preparação para aplicação de outras técnicas que a complementem.
 
  • Entrevistas. Uma entrevista é uma abordagem metódica utilizada para elicitar informações de partes interessadas por meio da realização de perguntas relevantes e da documentação das respostas obtidas. Durante a entrevista, perguntas são feitas a partes interessadas do projeto para identificar funções e outras capacidades que deverão estar presentes no produto. A entrevista pode ser conduzida de forma mais estruturada, com perguntas tendo sido preparadas de antemão, ou mais desestruturada, onde perguntas são feitas de maneira mais livre, baseadas nas próprias respostas dadas pelos participantes.
 
  • Workshops com Facilitação. Esses eventos reúnem partes interessadas chaves ou times multidisciplinares numa sessão estruturada conduzida por um facilitador para identificar requisitos, reconciliar abordagens diferentes e obter consenso entre os participantes.
 
  • Grupos de Foco. Essas reuniões envolvem participantes pré-qualificados, como especialistas em certos temas ou no uso de certos produtos, para compartilhar suas expectativas e atitudes a respeito do produto a ser desenvolvido. Os membros do grupo manifestam suas opiniões e esclarecem tópicos específicos.
 
  • Brainstorming. Consiste numa técnica altamente criativa e sinérgica para obtenção de informações (neste caso, requisitos), onde não se impõe qualquer tipo de restrição aos participantes e não se busca qualquer tipo de consenso a priori.
 
  • Questionários e Pesquisas. Essas ferramentas são usadas para solicitar e obter informações rapidamente de um grupo grande de partes interessadas. As questões são preparadas para elicitar dados subjetivos e demográficos dos respondentes. As respostas são analisadas para se extraírem requisitos ou se obterem insumos para outras técnicas de elicitação. Questionários e pesquisas são mais eficazes quando se desejam respostas mais rápidas de partes interessadas geograficamente dispersas.
 
  • Protótipos. A utilização de protótipos é uma forma de se obter feedback antecipado sobre as características de um modelo funcional de um produto, antes de seu desenvolvimento real. O contato do cliente com o protótipo permite a elicitação de necessidades sobre o uso do produto e a posterior documentação de requisitos.
 
  • Observação. Essa técnica, também conhecida como “job shadowing”, permite que se observem pessoas diretamente em seus ambientes de trabalho para que se veja como realizam suas atividades. É particularmente útil para elicitar requisitos tácitos, difíceis de verbalizar.
 
Quem elicita requisitos deve empregar escuta ativa para tentar capturar toda a informação que chega com cada resposta. Escuta ativa é o ato de ouvir completamente “com todos os sentidos”. Uma boa prática é parafrasear ou repetir o que foi dito pelo entrevistado para garantir um entendimento acurado do que foi comunicado. Isso envolve suspender todo o julgamento sobre o que está sendo ouvido, para que a informação possa fluir livremente.
 
Dependendo da área de aplicação do produto que será desenvolvido, vários métodos de modelagem visual podem ser utilizados como auxílio na elicitação de requisitos, tais como, Diagramas de Caso de Uso, Wireframes, Diagramas de Contexto entre outros.

Fotografia
Quando se aplicam técnicas que envolvem interação com as partes interessadas, é importante que o responsável pela elicitação prepare-se adequadamente para a sessão. Essa preparação deve envolver uma definição clara dos objetivos que se pretendem alcançar com a sessão de elicitação, a definição dos participantes e a preparação de perguntas a serem feitas para os entrevistados.

A respeito das perguntas a serem feitas numa sessão de elicitação, é importante notar que não há uma pergunta “certa” que fornecerá a informação exata que gerará a solução perfeita. A pergunta certa não é conhecida até que a pergunta seja respondida e a resposta analisada. Em muitos casos, informações que levam a soluções perfeitas chegam aos pedaços a partir de várias perguntas feitas a vários participantes. De maneira geral, quanto mais questões são perguntadas, maior a chance de se fazer a pergunta certa.

Uma ferramenta interessante para gerar ideias sobre perguntas a serem feitas é adotar uma espécie de “checklist” de espécies de requisitos, particularmente para os requisitos não-funcionais, conforme apresentado adiante.
É importante lembrar que nem todas as perguntas são planejadas. Boa parte da conversa durante uma elicitação de requisitos é espontânea, ainda que direcionada e investigativa por natureza. A seguir é apresentado um exemplo de notas de preparação para uma sessão de elicitação para discutir uma mudança de escritório:
​

Fotografia
Um aspecto também importante durante a elicitação é a consideração dos requisitos não-funcionais (ver definição na parte 1 deste artigo). Estes descrevem certas condições ambientais ou atributos requeridos para garantir que o produto funcione efetivamente, e podem ser subdivididos em várias espécies, como as apresentadas a seguir, que podem servir como um checklist de apoio ao processo de elicitação:
​
  • Requisitos de Desempenho. Requisitos que definem algum desempenho necessário do produto precisam ser alcançáveis, mensuráveis e especificados em termos operacionais, sempre que for possível. Podem ser subdivididos em:
 
  • Requisitos de Níveis de Serviço. Cenários que possam implicar em diferentes níveis aceitáveis de serviço (ex.: se o desempenho do produto em horário comercial será diferente em relação ao período noturno e fins de semana, se as condições de utilização do produto em caso de demanda máxima serão muito diferentes das condições de utilização em caso de demanda média ou mínima).
 
  • Requisitos de Confiabilidade e Disponibilidade. Requisitos de confiabilidade incluem, por exemplo, tempo médio entre falhas (MTBF – Mean Time Between Failure). Requisitos de disponibilidade incluem, por exemplo, percentual de tempo em que o produto estará disponível em funcionamento normal e em funcionamento de emergência.
 
  • Requisitos de Modularidade. Referem-se à habilidade de componentes de hardware e de software serem ampliados ou melhorados sem requerer mudanças em outros componentes além daqueles que estão sendo ampliados ou melhorados.
 
  • Requisitos de Escalabilidade. Requisitos relacionados à capacidade de o produto operar em várias faixas.
 
  • Requisitos Físicos. Referem-se à integração de uma solução no ambiente físico. É muito provável que requisitos relacionados à integração física não se apliquem aos casos em que o produto do projeto seja um serviço, a não ser que equipamentos ou instalações sejam adquiridos para suportar tal serviço.
 
  • Requisitos de Interface. Interfaces necessárias entre o novo produto e processos, sistemas, equipamentos ou instalações, novos ou existentes, com os quais o novo produto terá de interagir, física ou funcionalmente.
 
  • Requisitos de Normas & Regulamentos. Normas ou regulamentos a que o produto precisará atender.
 
  • Requisitos relacionados a Fatores Humanos.
 
  • Requisitos de Interface entre o Produto e o Ser Humano. Tipicamente, esses requisitos servem para garantir que o produto seja apropriado para ser utilizado, operado e mantido por pessoas.
 
  • Requisitos de Segurança e Saúde de Pessoas. Podem se referir a:
 
  • Saúde e segurança daqueles que irão utilizar o produto (ex.: espaço adequado para manutenção, facilidade de acesso a componentes, manuseamento de materiais inflamáveis ou tóxicos, proteção contra queda, descarte de resíduos).
 
  • Ambiente de operação (ex.: iluminação, saídas de emergência, temperatura, ruído, proteção contra incêndio, escadas de emergência).
 
  • Detecção de mau funcionamento e desligamento automático de equipamentos de forma a evitar prejuízos à saúde ou riscos de acidentes com pessoas.
 
  • Requisitos de Capacidades e Habilidades Especiais. Relacionados a capacidades específicas (físicas, de percepção, de conhecimento técnico) daqueles que irão operar, manter ou dar suporte ao produto. Por exemplo, a força de trabalho necessária, assim como suas habilidades requeridas (número de operadores por equipamento, habilidade ou proficiência de operadores/ mantenedores) e necessidades relacionadas a treinamento permanente do pessoal envolvido com o uso do produto.
 
  • Requisitos de Segurança.
 
  • Requisitos de Segurança Física. Relacionados à segurança das instalações durante a operação. A segurança das instalações refere-se à prevenção de acesso não autorizado a instalações (controle de acesso), propriedades e equipamentos, e à proteção contra sabotagem, espionagem e outras ameaças criminosas.
 
  • Requisitos de Segurança da Informação. Relacionados a armazenamento, processamento ou transferência de dados e informações considerados sensíveis ou confidenciais, durante a operação do produto.
 
  • Requisitos de Manutenção do Produto. Indicam necessidades a respeito de quem ou como a manutenção do produto será feita. Por exemplo: a manutenção preventiva não deve ser inferior a “x” vezes ao ano, reparos em garantia devem ser feitos em até “y” dias, a manutenção corretiva deve ser feita dentro de “z” horas.
 
  • Requisitos de Suporte à Operação.
 
  • Requisitos de Pessoal de Suporte. Pessoal necessário para trabalhar diretamente com a operação do produto.
 
  • Requisitos de Material de Suporte. Relacionados à obtenção, catalogação, recebimento, armazenamento e disponibilização de materiais de suporte à operação do produto, como peças sobressalentes, por exemplo.
 
  • Requisitos de Equipamentos de Suporte. Equipamentos e ferramentas necessários ao suporte das operações do produto
 
  • Requisitos de Dados Técnicos para a Operação. Relacionados com o registro de informações, tais como manuais técnicos, especificações e desenhos, necessários à operação do produto.
 
Na próxima e última parte deste artigo, trataremos da documentação e análise dos requisitos elicitados, e de seu monitoramento e controle para entregar uma solução que atenda às partes interessadas.
 
Este artigo faz parte do Programa Esteiras de Gestão da Academia DC. Clique aqui, faça sua inscrição e acesse gratuitamente vários conteúdos online para aperfeiçoar suas habilidades gerenciais!



Referências bibliográficas:
  • BORGES, Carlos; MERIGUETTI, Cezar; ROLLIM, Fabiano; Gerenciamento de Projetos Aplicado. 2ª ed. Rio de Janeiro: DC, 2024
 
  • PROJECT MANAGEMENT INSTITUTE. Requirements Management: A Practice Guide. Newton Square: PMI, 2016.
 
  • PROJECT MANAGEMENT INSTITUTE. Business Analysis for Practitioners: A Practice Guide. Newton Square: PMI, 2015.
 
Créditos das imagens:
  • "Use Case Diagram.jpg" por Liridon, disponível sob a licença CC BY 3.0 em https://creativecommons.org/licenses/by-sa/3.0/deed.en.
  • "Hatley-Pirbhai System Context Diagram.png" por Chrislk02, disponível sob a licença CC BY 3.0 em https://creativecommons.org/licenses/by-sa/3.0/deed.en.
  • “Low-fidelity wireframe.jpg” por Junie Loftesnes, disponível sob a licença CC BY-ND 4.0 em https://creativecommons.org/licenses/by-nd/4.0/deed.no.
 

0 Comentários
<<Anterior
Reencaminhar>>

    Imagem

    Categorias

    Tudo
    DevOps
    Gerente De Projetos
    Phyton
    Power BI

    Histórico

    Abril 2025
    Março 2025
    Fevereiro 2025
    Janeiro 2025
    Dezembro 2024
    Novembro 2024
    Outubro 2024
    Setembro 2024
    Agosto 2024
    Julho 2024
    Junho 2024
    Maio 2024
    Abril 2024
    Março 2024
    Fevereiro 2024
    Novembro 2023
    Outubro 2023
    Setembro 2023
    Agosto 2023
    Abril 2023
    Fevereiro 2023
    Janeiro 2023
    Novembro 2022
    Outubro 2022
    Agosto 2022
    Julho 2022
    Junho 2022
    Maio 2022
    Abril 2022
    Março 2022
    Fevereiro 2022
    Novembro 2021
    Outubro 2021
    Setembro 2021
    Agosto 2021
    Maio 2021
    Abril 2021
    Março 2021
    Fevereiro 2021
    Dezembro 2020
    Novembro 2020
    Outubro 2020
    Setembro 2020
    Agosto 2020
    Julho 2020
    Junho 2020
    Maio 2020
    Abril 2020
    Março 2020
    Fevereiro 2020
    Janeiro 2020
    Dezembro 2019
    Novembro 2019
    Outubro 2019
    Setembro 2019
    Julho 2019
    Junho 2019
    Maio 2019
    Janeiro 2019
    Dezembro 2018
    Novembro 2018
    Outubro 2018
    Setembro 2018
    Agosto 2018
    Julho 2018
    Junho 2018
    Maio 2018

Imagem

Matriz  Rio de Janeiro

Avenida Presidente Wilson, 231 - 9º andar - Centro, RJ
CEP: 20030-021
WhatsApp:  (21) 97541-0548​

Filial São Paulo

Avenida Paulista 726 - 16º andar - Bela Vista, SP
CEP: 01310-910
WhatsApp:  (21) 97541-0548
Fotografia
Fotografia
Fotografia
Imagem
Fotografia
Fotografia
© ​