Video YouTube, Workplace: Introduction to DiSC Video

DiSC é um modelo baseado no trabalho do Dr. William Moulton Marston (1893-1947) para avaliar o comportamento dos indivíduos num determinado ambiente.

A teoria DiSC é a base de algumas das ferramentas de assessment mais confiáveis disponíveis no mercado.

Um padrão comportamental não é melhor do que outro.

Conceitos DiSC

D Dominance indica como se lida com problemas e desafios. É decidido, directo, orientado para resultados
I Influence indica como se lida com pessoas e as influência. É confiante, inspirador, optimista, popular, sociável
S Steadiness indica como se lida com mudanças e estabelece o próprio ritmo. É agradável, bom ouvinte, paciente, sincero, constante, membro de equipa, estável
C Compliance indica como se lida com regras e procedimentos estabelecidos por outros. É preciso, analítico, perfeccionista, cuidadoso e minucioso


A combinação destes factores prevê o comportamento de um indivíduo face aos outros e face às tarefas do dia-a-dia.


De seguida apresentam-se diapositivos que explicam mais em detalhe cada uma destas dimensões:

Exemplo de perfil DiSC

Apresenta-se, a título de exemplo, um relatório para o perfil supportive Driver, um Decisor dentro das organizações:











fonte: DISC, discprofile

Segundo a IDG, em 2017 o cloud computing deverá ser dominado pelas plataformas de serviços e bases de dados suportadas por infra-estruturas híbridas.

Implementar mais serviços híbridos (36%) foi a opção mais escolhida pelos inquiridos, ultrapassando o quociente da preferência por serviços privados (32%) e por serviços na cloud pública (17%).

A adopção da cloud privada está no bom caminho, com quase dois terços das empresas (60%) a revelarem ter alcançado níveis intermédios ou maduros de adopção. Até 2017, a Oracle prevê que esta situação cresça para os 82%. Neste âmbito, o Software as a Service (SaaS) é encarado como o aspecto mais importante, ultrapassando a Database as a Service (DaaS) (61%) e a Platform as a Service (PaaS) (57%). Mas a Oracle prevê que este panorama se altere nos próximos anos com a DaaS a converter-se na forma mais importante de cloud privada, ultrapassando a PaaS (26%) e os SaaS (23%).

A principal barreira à cloud privada permanece a segurança, referida por 55% dos inquiridos, à qual se juntam novas preocupações como a integração com as aplicações existentes (47%), com as ferramentas e os recursos disponíveis (45%), e com os custos do hardware (44%). Estas novas preocupações ajudam a explicar por que estão as empresas a optar pelos modelos híbridos nas suas estratégias de cloud computing.

Os inquiridos consideraram que os aspectos mais relevantes para garantir a implementação com sucesso de uma infra-estrutura de cloud privada são: níveis de controlo da governação bem definidos e operacionais (34%); standardização das TI (27%); capacidade de obter o apoio dos principais decisores (25%); e capacidade de assegurar uma gestão eficaz das mudanças nas TI (17%).



vide Classificação do cloud computing por casos de uso
vide HP aposta na cloud privada




Referências:
Casos de uso de Cloud Computing
Four Hybrid IT Environments: It Is Not Just About Hybrid Cloud!






fonte: ITChannel

O requisito é a condição ou função necessária para um sistema alcançar um determinado objectivo. O objectivo de qualquer sistema, seja software ou um processo de negócio, é atender a um conjunto de requisitos – as necessidades que o sistema deve satisfazer.

Os requisitos podem ser funcionais ou não-funcionais.

Os requisitos funcionais reflectem as necessidades do cliente que devem ser satisfeitas para alcançar os objectivos do negócio.

Os requisitos não-funcionais são os que reflectem as características do sistema ou do ambiente em que está inserido. São requisitos não-funcionais os requisitos de interface, usabilidade, desempenho, operacionais, segurança, legais e manutenção e suporte.

Segundo o IIBA International Institute of Business Analysts, estas são as melhores práticas na definição de requisitos:

• Os requisitos são completos. São fechados e sem azo a depreensões.
• Os requisitos são testáveis. Há que fazer prova de que os requisitos estão implementados.
• Os requisitos são coerentes entre si. Não há conflito ou contradição entre requisitos.
• Os requisitos são independentes do design. Os requisitos indicam o que o sistema faz ou não faz, cabe ao design especificar como é que o software o vai fazer.
• Os requisitos são claros. Têm uma única interpretação.

Os casos de uso capturam e modelam os requisitos funcionais, servindo como contrato entre as partes envolvidas. Portanto, definem uma solução de negócio como resposta à visão do cliente que depois vai ser implementada em termos técnicos.
Um caso de uso descreve uma série de interacções entre o utilizador e o sistema em que o objectivo é indicar como o utilizador usa o sistema e está, portanto, orientado ao utilizador. O caso de uso é constituído por um fluxo principal e fluxos alternativos que podem por sua vez tornar ao fluxo principal. O caso de uso define as interacções detalhadamente reflectindo as regras de negócio da funcionalidade, assim como as opções que o actor pode tomar para a realizar.

Tanto os requisitos como os casos de uso estão mais centrados na especificação de documentos do que na colaboração.

As user stories centram-se no valor que o sistema entrega aos utilizadores. O objectivo não é especificar detalhadamente na fase inicial, é fornecer uma framework em que o detalhe vai sendo adicionado à medida que é necessário. Vai havendo uma conversação à medida que o projecto avança promovendo a colaboração entre as partes.

Cada user story descreve trabalho que traz mais valia para o utilizador. User stories que levam mais do que uma iteração a implementar são os chamados Epics e são decompostos em user stories de uma iteração. Constroi-se, assim, um story map com os epics em sequência e decompostos em peças de trabalho mais pequenas que indica as funcionalidades que satisfazem os objectivos do negócio. A prioridade e a sequência no story map identificam o MVP (Minimum Viable Product ).



Bill Wake criou uma mnemónica para as melhores práticas na definição de user stories:

I Independent Não há dependência entre user stories. Elas não dependem umas das outras.
N Negociable Podem ser sempre alteradas enquanto durar a iteração
V Valuable Tem que trazer valor ao utilizador
E Estimable É possível de estimar (tamanho) caso contrário não é possível planeá-la e mapeá-la em tarefas
S Small Têm de ser pequenas de modo a poderem ser planeadas com um certo nível de certeza
T Testable A sua descrição tem que ter informação suficiente para poder ser testada

Exemplo

Necessidade do cliente: Encontrar todos os analistas especialistas em SOX que existem num raio de 50 km de Bruxelas


Requisitos

O sistema permite pesquisar candidatos por função, especialidade e região geográfica.

A função de um candidato pode ser uma entre analista, responsável técnico, programador e web designer.

A especialidade de um candidato pode ser uma entre SOX, Agile, UX e Microsoft.

A região geográfica de um candidato é a cidade e, opcionalmente, num raio medido em kms da cidade indicada. O raio é de 50 kms por omissão.


Caso de Uso

Fluxo Principal:
1.O actor selecciona a pesquisa de candidatos
2.O sistema apresenta o ecrã de pesquisa de candidatos com a lista de funções, a lista de especialidades, a lista de cidades e o raio 50 km.
3.O actor selecciona a função, a especialidade e a cidade e submete o pedido de pesquisa
4.O sistema apresenta a lista de candidatos
Fluxos alternativos:
1. passo 2 - O actor indica o valor do raio
              a. O sistema executa o passo 4
2. .passo 4 - O sistema não encontra candidatos que satisfaçam o critério de pesquisa
               a. O sistema devolve a mensagem “Não foram encontrados resultados”


User Story

Título:
Pesquisar candidatos por função, especialidade e região geográfica.

Descrição:
Enquanto utilizador que pesquisa candidatos, quero pesquisar candidatos por especialidade, por forma a fornecer recursos aos clientes.

Critério de Aceitação:
A pesquisa de candidatos permite pesquisar por função.

A pesquisa de candidatos permite pesquisar por especialidade.

A função e a especialidade são seleccionadas a partir de listas.

A pesquisa retorna uma lista de candidatos ou uma mensagem indicando que não há resultados




fonte: CMCrossroads, BATimes

SMART é um método interessante e poderoso para criar objectivos no seu trabalho ou na sua vida em geral.

De acordo com essa metodologia, um objectivo deve ser:

• S – eSpecífico (Specific) 

O objectivo deve ser específico e não generalizado. Ou seja, deve ser algo que pode ser claramente atingido. Um bom exemplo é "inscrever.me num ginásio e exercitar 3 vezes por semana"

• M – Mensurável (Measurable)

Deve ser possível avaliar que ele foi atingido. O exemplo típico é óptimo: "perder 5 quilos".

• A – Atingível (Attainable) 

O objectivo tem que ser alcançável. Tem que se propor a realizá-lo e tem que compreender suas dificuldades.

• R – Realista (Realistic) 

O objectivo tem que ser realista. Não adianta querer perder 50 quilos em uma semana.

• T – limitado no Tempo (Time Bound) 

Tem de dar um prazo para o objectivo acontecer. Por exemplo "Perder 5 quilos em 3 meses".

Aqui encontra-se um modelo de aplicação do método SMART para definição de objectivos.

Exemplo de aplicação: Gestão da mudança








fonte: PLURIVALOR - Soluções de Gestão