Pensando em projetos baseado nos relatórios de acompanhamento e no resultado final pode-se afirmar que existem apenas dois tipos de projetos:

1. Os que dão certo até dar errado e…
2. Os que dão errado até dar certo…

Parece uma visão muito pessimista, e apesar de você provavelmente não concordar… essa é uma visão tremendamente otimista (rsrs).

Todos que já trabalharam em projetos sabem que o ambiente de projeto é um ambiente complexo, por mais simples que seja o projeto existem dezenas de fatores que influenciam positivamente ou não cada elemento, e fazer com que todas essas variáveis estejam sempre de acordo não é um trabalho simples…

Mas voltando ao início, vamos analisar o primeiro caso:

Os que dão certo até dar errado
É aquele projeto onde tudo corre as mil maravilhas, mês a mês o percentual de completude do projeto evolui exatamente como previsto, sem nenhuma ocorrência, nenhum dos riscos se confirma, não existe mudança de escopo, não existe atrasos em atividades intermediárias… O Mundo perfeito, até… que o projeto chega nos seus 99% de conclusão…?Nesse momento, alguma coisa acontece, talvez um encosto, inveja ou olho gordo de alguém, mas o projeto trava nesse 99%, e nada faz com que ele ande…?Quando muito vai para 99,01, 99,02%…?Então se descobre que o projeto não teve apoio do Sponsor, que o usuário mudou 5 vezes o escopo, que o fornecedor atrasou, que um dos profissionais alocados saiu da empresa e não foi possível substituí-lo, que alguém dimensionou errado, enfim, o projeto em que deu tudo certo, dá errado.

Os que dão errado até dar certo
No segundo tipo de projeto, já no primeiro relatório, o Gerente de Projetos aponta que o usuário quer mudar o escopo, atividades atrasam e ações precisam ser tomadas para recuperar o tempo perdido, o fornecedor atrasa, como demonstra os reports diários de atraso do GP. Os riscos ocorrem, surgem novos, novas ações de resposta aos riscos são definidas, enfim, nada dá certo, até que se aproxima a data de entrega do projeto e, MILAGROSAMENTE, o projeto acontece, e o projeto dá certo…

Sorte? Azar? Ou competência? O que você acha?

Você provavelmente não saberá como será seu próximo projeto, mas há duas coisas que você sabe: O Escopo vai mudar, e algo vai dar errado.

Isso não é pessimismo, não é fatalismo… Como dizia uma música dos anos 1970; ” Hope for the Best, but expecting the Worst…”  (Esperando pelo melhor, mas se preparando para o Pior, numa tradução livre), esse deve sempre ser o comportamento do Gerente de Projeto, ao apontar desvios, que para muitos é um erro, ele força as ações que dirigem o projeto para o sucesso.

Já se nada é apontado, nada é feito, e no final…

Mas ai aparece aqueles que dizem, mas e se realmente nada acontecer e der certo no final? Bom um projeto desses não precisaria de um Gerente de Projetos… E como não acredito em projetos sem Gerentes de Projeto, não consigo acreditar em projetos assim… É mais ou menos como Papai Noel… todo mundo sabe que existe, mas ninguém nunca o viu (rsrs).

Luis Edmundo

No related posts.

A busca pela atração de talentos tornou-se uma constante preocupação das empresas. No entanto, de tanto olharem para “fora” dos seus portões, há organizações que se esquecem de pensar em como reter os profissionais que formam suas equipes e fazem o diferencial para o seu negócio. Ao contrário do que muitos pensam, não é apenas um salário tentador que motiva o colaborador a vestir a camisa da companhia. Hoje, os profissionais estão mais seletivos e não querem ser considerados apenas números na folha de pagamento. Confira abaixo alguns fatores que listei, a partir de inúmeras conversas que já mantive com profissionais que atuam na área de Gestão de Pessoas.

1 – A empresa precisa ter ciência dos seus pontos fortes como também dos processos que precisam ser melhorados. Dessa forma, poderá atender tanto às suas necessidades quanto às expectativas dos colaboradores. Para isso, uma ótima ferramenta é a aplicação periódica da pesquisa de clima organizacional.

2 – Quem deixa de falar e de se expressar, nunca será entendido. Da mesma forma que ocorre com as pessoas, as organizações devem saber se comunicar tanto com o público externo quanto o interno. Uma boa política de comunicação interna faz com que a empresa ganhe credibilidade junto aos funcionários e esses, por sinal, darão preferência a escutar os canais de comunicação da empresa do que se deixarem levar por boatos.

3 – O processo de feedback, desde que conduzido corretamente, torna-se um recurso valioso para a Gestão de Pessoas. Isso porque através dele, o colaborador sabe o que a empresa espera dele e quais as competências que precisa desenvolver ou aperfeiçoar para ter um bom desempenho e até mesmo superar as expectativas desejadas.

4 – Não há talento que deseje manter-se parado e é por esse motivo que, cada vez mais as empresas investem no planejamento de carreira, uma vez que esse dá um norte, um direcionamento à ascensão do profissional.

5 – Trabalhar sentindo-se isolado é jogar um banho de água fria, melhor, geladíssima em qualquer um. Quem possui detém conhecimento precisa disseminá-lo e adquirir novas competências, sejam técnicas ou comportamentais. Isso requer trabalhar num local onde as pessoas valorizem o espírito de equipe.

6 – Tudo em excesso torna-se veneno. Isso também vale para o trabalho. Pessoas que se tornam workaholics – viciados no trabalho tendem a cair no grau de estresse perigoso. Não é à toa que as empresas investem em ações focadas na melhoria da qualidade de vida dos profissionais.

7 – A abertura para apresentar novas ideias é um fator motivacional que proporciona um efeito que, por vezes, surpreende. As companhias que dão abertura para seus funcionários arriscarem, estimulam o potencial criativo das pessoas e colhem bons resultados.

8 – Muitas vezes, as organizações oferecem benefícios para seus colaboradores e quando valiam os resultados, se surpreendem porque os índices de satisfação não são os esperados. É bom ressaltar que uma cesta de benefícios, por exemplo, deve atender às necessidades dos funcionários. Caso contrário, não agregarão grande diferencial.

9 – As condições de infraestrutura colaboram para a performance de uma equipe. Sem os recursos adequados, limita-se a capacidade de desempenho das pessoas por mais que essas se dediquem a uma determinada atividade.

10 – Como falamos sobre desempenho, os profissionais de talentos são ávidos por novas conquistas, por superação de metas. Isso requer que a empresa sempre ofereça desafios.

11 – Muitos profissionais deixam a empresa não por desistiram dela, mas sim porque não suportam mais a convivência com superiores que se denominam de líderes. O papel da liderança não é o de delegar ordens. Investir no desenvolvimento dos gestores é um diferencial para quem deseja reter talentos.

12 – O estímulo ao desenvolvimento não deve ficar restrito apenas às lideranças, deve ser uma prática que precisa ser estendida aos demais níveis.

13 – Não menospreze a concorrência. Esteja sempre atento às tendências do mercado e às inovações que estimulam as empresas a captar e reter profissionais diferenciados.

14 – O relacionamento entre empresa e colaborador se fortalece quando há um canal aberto e isso se apresenta na divulgação da cultura corporativa.

15 – Todas as ações citadas acima pedem uma participação ativa da área de Recursos Humanos. Acreditar que a atuação do RH é apenas burocrática não cabe mais junto a empresas competitivas e de visão.

Patrícia Bispo

No related posts.

O CMMI nos pede para “extrair as necessidades dos clientes, então… como podemos realizar esta prática?

Por vezes, os clientes acreditam que estão nos passando os requisitos do sistema ao fato de apresentar uma lista simples de necessidades. Um requisito é uma coisa específica (clara, rastreavel, testavel, etc) e muitas vezes os requisitos que recebemos tem algumas destas coisas (mas não todas). A prática RD SP 1.1 começa como “extrair as necessidades” e nos pede pra executar um processo de identificação das necessidades dos requisitos.

Há muitas formas de “extrair” as necessidades de um cliente pois há empresas. Cada um com suas próprias características e estilos, mas há tópicos semelhantes e podemos oferecer alguns exemplos:

- Sessões de levantamento de dados entre o cliente e analistas de sistemas (ou requisitos) onde as necessidades são mapeadas e discutidas através de um simples quadro branco. Certifique-se de trazer sua câmera ou ter um celular que tire fotos visíveis. E sim, as fotos podem ser colocadas sob controle de configuração (e que podem “contar como prova” se adequadamente gerenciados e usados).

- Sessões de Brainstorming que são estruturadas através de uma ferramenta de mapas mentais como mind node (meu preferido) ou mindjet, mas se não tiver nada disso, faça no quadro branco também (e não esqueça da foto). Uma boa prática é começar o mapa pelos principais requisitos e ir detalhando-os o tanto quanto for possível. Use canetas de cores diferentes para destacar o que é crítico ou regras mais complexas. Abordagens gráficas normalmentente fazem um processo dito como “chato” (por seu cliente) em algo diferente e mais produtivo.

– Workshops de priorização onde o cliente apresenta ao pessoal de análise (ou engenharia de requisitos) o que é mais importante para ele. O que ele não pode viver sem? Esta abordagem diferente é muito boa para reduzir o escopo (e retirar perfumarias).

- Uma especificação de requisitos detalhada como uma RFP enviada em um processo de licitação. Isso é muito comum no governo e em grandes projetos. Normalmente elas passam as linhas gerais, mas… ajudam muito. O que você deve lembrar aqui é que o fato de você ter recebido um documento de 400 páginas de requisitos não te exime de fazer seu trabalho. Sempre há falhas.

- Em abordagens agile, protótipos, exemplos de telas ou até rascunhos são o primeiro insumo para o trabalho. Um material preliminar como esse vai ajudar muito seu cliente a definir o que estará mesmo no escopo (e o que ele quer). Este método, claro, é iterativo porque o cliente raramente sabe como passar o que ele realmente quer.

Interpretando literalmente, o CMMI nos diz para “extrair as necessidades”, mas lembre-se que o esforço real pode ser de horas, dias, semanas ou até mais e pode acontecer várias vezes ao longo do tempo de um projeto – O que resulta normalmente em vários releases.

Por fim… faça este trabalho ser algo divertido ao seu cliente… utilize sessões de brainstormind e mapas mentais e… divirta-se.

No related posts.

Talvez… Atitude, seja a palavra que mais traduz esta cena.

No related posts.

Pergunta: Vemos um monte de discussões sobre desenvolvimento Ágil e por vezes fanáticos se envolvem e acrescentam um monte de neblina a essas discussões, tornando o assunto mais nebuloso ainda.

O “Manifesto Ágil” explica um pouco mas não existe uma definição clara que possa ser usada para esta tag, ou seja, continua um mito para a maioria de nós. Eu, por exemplo, acredito que Agile é uma palavra qualitativa que não deve ser usada para definir uma metodologia.

Resposta: Não á espaço suficiente para escrever algo que dê um pouco de sentido sobre o assunto, há muita coisa, mas vamos tentar passar um pouco.

“Agile” é um termo genérico que se refere a um conjunto disperso de métodos que incluem SCRUM, XP, Feature Driven Development e outros modelos iterativos e incrementais. Você esta correto quando fala que “nao é uma metodologia em si”.

Você frequentemente ouve descrições muito soltas como “confiança”, “iterativo”, “sem documentação” (essa é a mais comum), etc. Estes são os termos mais comuns para se “falar” sobre Agile, todavia como podemos perceber, são bastante nebulosas. Para ser mais preciso:

1- Métodos Agile são iterativos, onde o ciclo de vida completo do projeto (planejamento, requisitos, design, testes, código) acontece em ciclos de tempo de menor duração, tipicamente 30 dias ou menos. Essas atividades são geralmente não lineares, mas empíricas, e nem sempre ocorrem em uma sequencia específica.

2- Métodos Agile são incrementais, onde um pequeno conjunto de requisitos é desenvolvido, seguido pelo refinamento ou outro conjunto de requisitos. Os métodos Agile são contra o “Big Bang” e defendem o desenvolvimento de pedaços menores de cada vez (Dividir para conquistar).

3- Métodos Agile negociam escopo, não tempo e custo. Um projeto “cascata” geralmente tem um escopo fechado, orçamento definido e um prazo. Se uma grande alteração é solicitada, o cronograma e o orçamento são negociados. Os métodos Agile esperam mudanças, mas negociam cada release (ou iteração) para conter uma certa quantidade de features (ou funcionalidades). Se não tudo não estiver pronto, executa-se outra release.

4- O usuário final ou cliente tem “autoridade no caixa” em projetos ágeis, pois os tipo de negociações não é conduzido por TI ou engenharia de software, é para as necessidades de negócio.

Os diferentes métodos Ágeis tem outras especialidades (Pair Programming XP é utilizada como uma forma de validação real time e SCRUM tem reuniões em pé e Sprints por exemplo), mas estes são ornamentais, não essenciais ao conceito de Agile.

Para mais informações (e para uma discussão sobe métodos ágeis e CMMI), você pode ver os seguintes artigos:

• Cinco meios para incorporar CMMI em métodos ágeis
• Aprenda SCRUM em 10 minutos
• Agile e CMMI: Os opostos se atraem
• PMBOK X Agile Software Development
• Aderência do CMMI com métodos ágeis (SCRUM, XP e FDD)

Veja também:

1. Agile e CMMI: Os opostos se atraem Apesar da percepção de que as melhores prática do CMMI...
2. Dilbert descobre o Agile Momento de descontração: Dilbert encontra o Agile Share this on...
3. Cinco meios para incorporar CMMI em métodos ágeis Há um equívoco em achar que CMMI e métodos ágeis...
4. PMBOK X Agile Software Development Já ouvi muita gente colocar o Agile Software Development como...
5. Aderência do CMMI com métodos ágeis (SCRUM, XP e FDD) O Scrum é compatível com o CMMI? Sim e não....

Pergunta: Nós não temos nenhum processo definido para DAR. Queremos atingir o CMMI 3, mas para isso temos que começar do zero. O que fazemos para dar certo? Podemos ter uma política e um processo orientando no uso de DAR e integrar este processo ao desenvolvimento do produto? Que ferramentas podemos usar para facilitar o uso de DAR?

Resposta: DAR, ou mais especificamente a área de processo Análise de Decisão e Resolução, é uma área de processo do CMMI 3 e seu objetivo é nos ajudar a tomar decisões complexas durante períodos de estresse ou caos. É um processo estruturado, que utiliza orientações e critérios para a tomada de decisões que poderiam ser impulsionadas pela emoção, custo ou favores de fornecedores (como “presentes”, ingressos ou até mesmo dinheiro).

DAR é iniciado através das diretrizes que determinam quando usar DAR. Então, existem critérios e métodos definidos para ajuda-lo na tomada de decisões.

Como as outras áreas de processo do CMMI, é perfeitamente possível (e fácil) integra-lo em seus processos de desenvolvimento de software. Na verdade, a PA TS – Solução Técnica consegue obter benefícios de DAR logo nos primeiros estágios. Não apenas TI tem vantagens de DAR – ela pode ser utilizada em praticamente todo procesos de decisão crítico.

Você pode iniciar com simples planilhas com padrões de orientações e critérios, e a partir desta definição, pontuar e selecionar a maior. Com o tempo, mais maturidade será alcançada e seu processo evoluirá e no futuro você terá uma biblioteca de de Decisões para que você possa reutiliza-las em seus projetos.

Veja também:

1. Usando a PA de decisão formal (DAR) de uma forma prática Vamos falar de uma área de processo pouco compreendida: DAR...

Apesar da percepção de que as melhores prática do CMMI e do Agile são opostas um com o outros, recentes pesquisas apontam justamente o oposto. O fato é que as organizações podem se beneficiar de ambos os modelos e melhorar significantemente o desempenho.

No final de 2008, o SEI publicou um artigo intitulado “Agile ou CMMI: Por que não abraçar os dois?. Este relatório foi escrito pela equipe do SEI e industria. Como sabemos, CMMI e Agile usam métodos diferentes para se realizar o mesmo trabalho, e como já era de se esperar, ambos tem suas comunidades e seguidores. Mike Konrad, um membro senior da equipe do SEI, concorda e afirma que a tendência natural é formar “novos feudos” ao redor de método diferentes (e normalmente novos). No entanto, de acordo com o relatório, esta ação não é saudável para a profissão de Engenharia de Software.

“Como ambas as comunidades continuavam a aumentar, parecia ser o momento certo para abordar esta questão”. Explica Konrad. “Além dodisso, foi uma excelente oportunidade para nós do SEI dissipar alguns mitos e ajustar nosso entendimento.”

O aumento na adoção de CMMI e Agile aconteceu através de diversos fatores. Por exemplo, a adoção do CMMI normalmente vem de uma necessidade de negócios (como aumento de qualidade e produtividade), ou seja, vem de cima pra baixo, enquanto no Agile as coisas acontecem de forma mais flat. Desta forma, era inevitável o cruzamento de ambos os modelos já que a aprovação vinha aumentando.

Enfim, ambos os modelos podem se beneficiar muito um do outro, entretanto, há um entrave para isto acontecer na comunidade Agile, pois, para abraçar plenamente os benefícios do CMMI, a comunidade Agile precisa aprender mais sobre CMMI. Vale lembrar que como um dos princípios do Agile é “abraçar a mudança”, em pouco tempo poderemos ver esta mesma comunidade se adaptar e se beneficiar do CMMI. Esta, é uma ação que já esta acontecendo pois muitos dos “Agilistas” que a dois anos atrás torciam o nariz com o CMMI, hoje, estão tentando unir os dois.

No nível do projeto, o CMMI foca mais em fazer o projeto enquanto o Agile foca mais em desenvolver o produto.

Em outras palavras, o CMMI fornece as práticas de engenharia de sistemas que ajudam a ativar uma abordagem Agile sobre projetos maiores. Já os métodos Agile fornecem os “how to” em desenvolvimento de sistemas, que estão faltando no CMMI.

Konrad também comentou que algumas abordagens Agile não funcionam bem em todos os contextos, e alguns detalhes solicitados pelo CMMI podem ser considerados “um exagero” em um ambiente mais simples. No entando, existem algumas lições importantes para ambos os processos que realmente devem ser considerados, acrescenta Konrad.

Com o tempo, veremos veremos ambos se unirem mais e mais, e um dia serão chamados apenas de “melhores práticas de engenharia de sistemas” e provavelmente ninguém masi se lembrará desta rivalidade.

Veja também:

1. Dilbert descobre o Agile Momento de descontração: Dilbert encontra o Agile Share this on...
2. Cinco meios para incorporar CMMI em métodos ágeis Há um equívoco em achar que CMMI e métodos ágeis...
3. PMBOK X Agile Software Development Já ouvi muita gente colocar o Agile Software Development como...
4. Aderência do CMMI com métodos ágeis (SCRUM, XP e FDD) O Scrum é compatível com o CMMI? Sim e não....

O que são mapas mentais

Mapa Mental (Mind Map) é um diagrama usado para representar palavras, idéias, tarefas ou outros itens ligados a um conceito central e dispostos radialmente em volta deste conceito. É um diagrama que representa conexões entre porções de informação sobre um tema ou tarefa. Os elementos são arranjados intuitivamente de acordo com a importância dos conceitos. Eles são organizados em grupos, ramificações ou áreas.

Pela representação das informações e suas conexões de uma maneira gráfica, radial e não linear, o Mapa Mental estimula a imaginação e o fluxo natural de idéias livre da rigidez das anotações lineares (listagens).

O Mapa Mental explora o fato de que nosso cérebro:

• Não trabalha de forma linear, mas pula de uma idéia para outra, de forma aleatória, seguindo as associações que vai descobrindo;
• Processa melhor, memoriza e relembra mais facilmente informações que combinam palavras, números, ordem e seqüência com cores, imagens, dimensões, símbolos e ritmo visual.

Quando usar mapas mentais

O Mapa Mental é usado para gerar, visualizar, estruturar, e classificar idéias e como uma ajuda na pesquisa e organização de informações; planejamento de projetos, campanhas, cursos, livros, artigos e outras tarefas; solução de problemas e tomada de decisão, etc.

Apresenta muitas vantagens sobre as anotações na forma de listas:

• A idéia principal é definida com mais clareza. Ela é colocada no centro do gráfico.
• A importância relativa de cada idéia é claramente indicada; quanto mais perto do centro, mais importante.
• As conexões entre conceitos são imediatamente reconhecidas.
• As revisões são mais efetivas e mais rápidas.
• Fácil inclusão de novas informações.
• A natureza aberta do gráfico estimula o cérebro a fazer novas conexões.

Mapa mental feito na ferramenta Mind Node

Como usar um Mapa Mental em 6 passos

1. Comece pelo centro. Pegue uma folha de papel e desenhe no seu centro uma palavra ou imagem que represente o assunto sobre o qual você irá pensar.

2. Em volta do assunto central coloque os principais temas ligados ao tema central.
Estes temas podem ser comparados aos títulos dos capítulos de um livro. São as idéias ordenadoras que definem os focos do Mapa Mental.

3. Use linhas para ligar estes temas ao assunto central.

4. Desdobre cada um destes temas principais em temas secundários e os conecte ao tema “mãe”.

5. Se necessário, desdobre estes temas secundários em novos temas e os conecte ao tema de origem.

6. Prossiga com os desdobramentos até atingir o nível de detalhamento necessário.

As regras e técnicas do Mapa Mental

Enfatize e evidencie

• Sempre use uma imagem central.
• Use cores variadas.
• Use imagens, símbolos, formas, texturas, etc.
• Use variações de tamanho das letras, linhas e imagens.
• Mostre a hierarquia entre os diversos níveis de informação.

Não interrompa o fluxo de idéias

• Anote as idéias imediatamente, como ocorrem.
• Não pare para fazer julgamentos, continue pensando.
• Deixe para mais tarde os julgamentos, modificações e melhorias.

Mostre as associações

• Use setas para mostrar conexões dentro e entre ramificações.
• Use cores.
• Use símbolos.
• Use formas como triângulos, círculos, retângulos, etc.

Seja claro

• Organize o espaço e deixe áreas em branco para futuras inserções.
• Somente uma palavra chave por linha.
• Use letras de imprensa, pois são mais fáceis de ler e lembrar.
• Escreva as palavras ao longo das linhas.
• Comprimento da linha igual ao comprimento da palavra ou imagem.
• Linhas centrais mais grossas; a espessura diminui à medida que se afastam do centro.

Desenvolva um estilo próprio

• Defina um layout personalizado.
• No uso de recursos gráficos para mostrar hierarquia, semelhanças e conexões.
• Na combinação própria de cores, imagens, formas, dimensões, etc.
• Use sua criatividade e torne seus mapas mais alegres, coloridos e artísticos.

Recursos usados

Setas: podem ser usadas para mostrar como conceitos que aparecem em diferentes partes estão conectados. As setas podem ser simples ou com ramificações e podem apontar em qualquer direção.

Pontuação e símbolos: asteriscos, pontos de exclamação e de interrogação, cruzes e muitos outros símbolos podem ser agregados às palavras para mostrar conexões ou evidenciar alguma informação.

Formas geométricas: triângulos, círculos, elipses, retângulos, etc. podem ser usados para marcar áreas ou palavras que têm alguma semelhança.Por exemplo: triângulos podem ser usados para mostrar áreas de possíveis soluções para o problema analisado.

Objetos tridimensionais: cubos, cilindros, esferas, pirâmides, etc. para destacar alguma idéia ou informação.

Imagens criativas: para ressaltar a natureza ou especificidade de um tópico. Use as imagens disponíveis em seu micro ou na internet. Melhor, crie você mesmo as suas próprias imagens.

Cores: as cores são particularmente úteis para ajudar a memória e a criatividade. Podem ser usadas, como as setas, para mostrar como conceitos localizados em diferentes partes do gráfico se conectam ou se relacionam.
Elas também podem ser usadas para delimitar as fronteiras entre as grandes áreas do gráfico.

Marcio Krüger

No related posts.

O Carnegie Mellon Software Engineering Institute ou simplesmente SEI é (podemos dizer) um centro de pesquisa e desenvolvimento com sede no campus da universidade Carnegie Mellon em Pittsburgh nos Estados Unidos. O SEI também tem escritórios em Arlington, Virginia, e Frankfurt na Alemanha. A maior parte dos recursos recebidos do SEI vem do departamento de defesa dos Americano.

O SEI também tem uma relação estreita com a industria e meio acadêmico através de pesquisa e colaborações.
As três principais áreas de atuação que são:

• Práticas de gestão
• Práticas de engenharia de software
• Práticas de aquisição

História do SEI

Desde 1984, o SEI tem por objetivo servir como um provedor global em engenharia de software e melhoria de processos como um todo. Com o tempo o SEI se tornou a maior autoridade mundial em práticas de engenharia de software através de seu principal programa (CMMI) que permitem as organizações melhorar seus processos e com isso conseguir mais qualidade com um custo menor e com previsibilidade.

Nos últimos anos a importância do software nas organizações tem se tornado maior e mais crítica, desta forma não apenas os Sistemas de Defesa precisam de softwares mais precisos e com qualidade como também empresas de transporte, finanças, medicina, entretenimento, enfim, praticamente todas as áreas de negócio.

O SEI têm contribuído com este crescimento em várias áreas, incluindo:

• Melhoria de processos de software
• Segurança de rede
• Arquitetura de software
• Linhas de produto de software
• Aquisições
• Atendimento a serviços
• Qualidade
• Desenvolvimento pessoal
• Previsibilidade

Áreas de trabalho

O SEI define iniciativas específicas destinadas a resolver os problemas que impedem a maturidade e capacidade das organizações para adquirir, construir e desenvolver sistemas previsivelmente no prazo, dentro do custo esperado, atendendo os requisitos e sem vulnerabilidade.

Práticas de gestão

As organizações precisam gerir de forma eficaz as aquisições, desenvolvimento e evolução dos sistemas de software. O sucesso nas práticas de engenharia de software de gestão ajudam as organizações a predizer e controlar a qualidade, atendimento a prazo, custo, tempo de ciclo e produtividade.

O exemplo mais conhecido do SEI é o Capability Maturity Model (CMM) para software (agora conhecido como CMMI – Capability Maturity Model Integration).

A abordagem do CMMI é composta de modelos, métodos de avaliação e cursos de formação para melhorar o desempenho do processo.

Em 2006, a versão 1.2 da suite CMMI para desenvolvimento foi lançada. O CMMI-DEV foi a primeira das três constelações definidas na versão 1.2. As constelações CMMI para Aquisições e CMMI para Serviços foram lançadas posteriormente.

Práticas de engenharia

O trabalho do SEI nas práticas de engenharia aumenta a capacidade das pessoas na análise de sistemas, predizendo e controlando os requisitos funcionais e requisitos não funcionais dos sistemas de software.

As principais ferramentas e métodos o ATAM – SEI Architecture Tradeoff Analysis Method, o SEI Framework for Software Product Line Pratice e o SMART – SEI Service Migration and Reuse Technique.

Práticas de aquisições

Melhorar as aquisição de sistemas de software que “funcionem” em sua primeira implantação é um desejo global. O objetivo do SEI no apoio a aquisições é ajudar as organizações a melhorar seus processos de aquisição e minimizar os riscos (Além de adquirir software de qualidade).

Práticas de segurança

O SEI também mantém o CERT/CC (CERT Coordination Center) que tem como principais objetivos garantir que as tecnologias e práticas de gestão de sistemas são utilizados para resistir a ataques externos, limitar os danos e garantir a continuidade dos serviços críticos.

O CERT desenvolveu um método para ajudar as organizações a construir sua segurança nos estágios iniciais do ciclo de vida de produção, que é o SQUARE – Security Quality Requirements Engineering.

Programas especiais

SEI Partner Network
Programa que ajuda o SEI a disseminar as melhores práticas de engenharia de software e gestão. Organizações e indivíduos no SEI Partner Program são selecionados, treinados e recebem autorização do SEI para oferecer seus serviços, que incluem cursos e consultoria de melhoria de processos. Este programa tem mais de 200 organizações afiliadas ao redor do mundo.

Conferências
O SEI patrocina conferências ao redor do mundo, workshops e grupos de usuário. A maior delas é o SEPG Conference, que normalmente possui quatro eventos em países distintos.

Capacitação
Os cursos do SEI ajudam na capacitação de organizações e indivíduos nas em cursos que vão do básico até alta maturidade. Estes cursos são ministrados normalmente por SEI Partners.

Membership Program
O SEI Membership Program fornece aos líderes na comunidade de engenharia de software a oportunidade de aprimorar seus conhecimentos, fazer network e contribuir com o SEI e outros membros. Atualmente existem mais de 2.000 membros ao redor do mundo.

Programa de afiliados
Através de seu programa de afiliados as organizações podem trabalhar em conjunto com o SEI para desenvolver, aprimorar e demonstrar as melhores práticas em engenharia de software

Publicações
O SEI publica diversos livros sobre engenharia de Software.
Veja algumas publicações do SEI:

No related posts.

Quem acha que o SEI fica de olhos fechados para escorregões….
Dê uma olhada nos resultados de auditorias recentes efetuados pelo SEI Quality Team for CMMI.

Audit Status

• 40 Audits initiated
• 8 HM audits initiated
• 2 High Maturity Appraisals resulted in a rating below high maturity
• 2 High Maturity Appraisals rejected
• 1 Lead Appraiser Certification suspension
• 1 Lead Appraiser HM decertification
• 2 Lead Appraiser revocations
• 13 Lead Appraiser warnings

Dados do primeiro semestre de 2010

Bom… acho que não restam dúvidas agora sobre quão sério as avaliações CMMI são encaradas pelo SEI.

Veja também:

1. Quais os treinamentos necessários para “fazer” CMMI? Esta é outra pergunta recorrente, e a resposta é: “Depende...
2. Quem pode realizar um SCAMPI? Um Lead Appraiser autorizado pelo SEI. É necessário demonstrar profundos...

Um líder de verdade sabe…

Ser objetivo: Como direcionar o progresso do negócio? Com metas claras e pré-estabelecidas. Muitos empreendedores desperdiçam dinheiro, tempo, mão-de-obra e equipamentos por não ter objetivos a curto, médio e longo prazo.

Somar competências: É importante ser visto pelos seus conselheiros, investidores e funcionários como um expert na sua área de atuação e no comando do negócio. Se a equipe não o achar capaz de liderar e nem preparado para assumir a gestão, dificilmente você será admirado, respeitado e seguido.

Montar um time forte: Todo empreendedor, por mais capacitado que seja, tem pontos fracos. Por isso, é importante montar um time com pessoas credenciadas, de diversas áreas e capazes de inovar. Também é fundamental o gestor reconhecer que não sabe tudo. Ele deve estar aberto a novas ideias e jamais desconfiar da capacidade da equipe.

Comunicar bem: Especialistas em liderança são unânimes em afirmar que a comunicação eficiente é a alma de qualquer empresa. Se o chefe não se comunica bem com seus funcionários, ele não é capaz de coordenar. A conversa face a face ainda é o melhor meio de evitar ruídos na comunicação. Jamais trate temas sérios por e-mail ou telefone.

Ter bom relacionamento: Líderes de sucesso são, em geral, acessíveis, amáveis, extrovertidos, confiantes e agregadores. Eles se sentem confortáveis em suas posições. Sabem decidir e delegar tarefas. Essas características os ajudam a motivar pessoas a fazer um melhor trabalho e obter resultados satisfatórios.

Inspirar a equipe: Não raro, os funcionários precisam de alguém para se espelhar e ser uma fonte de inspiração. Este é mais um dos papéis do líder. Mesmo quando o trabalho vai bem, é fundamental manter as pessoas estimuladas. Apoie sempre a iniciativa e a criatividade.

[saia do lugar]

Veja também:

1. As características de um líder – A teoria dos 9 C’s O texto abaixo foi escrito originalmente pelo Lee Iacocca, o...

O esquecimento de um “detalhe” (requisito) em projetos é mais comum do que se imagina. Normalmente alguém lembra: “Ops… faltou colocar isso no sistema… e agora?”. E o pior de tudo é que o mais comum é que isso aconteça próximo da entrega do sistema. Isto acontece normalmente por causa de um processo de especificação ineficaz ou até mesmo pela simples vergonha de perguntar um pouco mais de detalhe sobre um requisitos.

Quanto mais tarde se encontrar um defeito, mais caro ele será.

O gráfico abaixo é a melhor forma de se ilustrar isso:

Repare que, quanto mais tarde, o custo vai aumentando exponencialmente, e este é um dos motivos que devem levar as empresas a investirem mais e mais em planejamento, controle e engenharia de software em geral.

Vamos a um cenário hipotético. Imagine que você esta fazendo um sistema que usa um índice para reajustar os custos de diversos produtos, este índice é praticamente o coração do sistema e você fez sua correção através do dolar. Porém, quando você começa a validar o mesmo com seu cliente você “descobre” que este índice deveria ser composto pela cotação do dolar, euro e mais quatro moedas. Qual impacto isto trará ao seu projeto? Bom… se você tivesse descoberto isto no início do projeto, o custo seria praticamente nulo, mas agora no final… imagine quanto você precisará gastar para ajustar este pequeno detalhe.

Quanto mais se investe em planejamento e especificação, menor será o tempo de desenvolvimento e você acabará montando mais do que desenvolvendo.

Enfim… pense nisso e aproveite e comente suas experiências em situações como esta.

No related posts.

Brainstorm é uma palavra inglesa que, em uma tradução livre, significa “tempestade mental”. É uma técnica onde todas as idéias de uma equipe podem ser expostas sem um julgamento precipitado. Todas são avaliadas e levadas em consideração e servem para muitas coisas, como criar uma marca, um produto ou solucionar um problema.

Existem algumas dicas que podem ser adotadas para que o brainstorm seja feito de forma eficiente. A primeira delas é que se tenha um líder para dirigir a dinâmica e mediar os questionamentos e possíveis conflitos entre os participantes. Ele também é quem vai incentivar a discussão e fazer com que a equipe mantenha sempre o foco no objetivo proposto.

Outra dica é que as idéias sejam anotadas, sem filtro, de forma que todos possam lê-las. Pode-se usar para isso quadro branco ou flipchart, ajuda aos participantes na organização das idéias e pensamentos, facilitando os questionamentos e promovendo a melhoria contínua.

A terceira e última dica é que tenha-se um tempo determinado para a realização. Geralmente é uma dinâmica rápida, que leva pouco tempo, questão de minutos. O limite de tempo estimula os participantes a doarem-se durante aquele período e é preciso ser rígido com isso.

Ao final do brainstorm a melhor idéia é selecionada e espera-se que o objetivo tenha sido alcançado ou ao menos tenha-se chegado próximo a ele.

Quer ver como é um Brainstorm na prática? Assista qualquer episódio do seriado House, ele pratica isso muito (e é uma série excelente).

Esta técnica por muitos é considerada boa oportunidade para o surgimento dos talentos, pois é uma forma que todos conseguem expor suas idéias e isto faz com que todos vejam o potencial existente em cada um.

Durante a elaboração deste artigo participei de um brainstorm para definir detalhes de um grande projeto da agência onde trabalho. Veja como aplicamos:

Definimos um objetivo e um limite de tempo, reunimos profissionais de diferentes funções, tínhamos programadores (eu era um deles), designers, gerente de projetos, animadores e o presidente da empresa.

Em um ambiente totalmente descontraído, sentamos em puffs e almofadas e começamos a discutir sobre o projeto. Quando as idéias já estavam pré-formuladas partimos para a sala de reuniões e começamos a formalizá-las no papel.

Nosso gerente de projetos foi líder e fez questionamentos importantes e por muitas vezes se colocou na posição de nosso cliente. No final do brainstorm tínhamos em mãos um excelente escopo inicial de nosso projeto.

Não existe uma regra para a técnica e cabe a cada situação definir a melhor maneira de se aplicar o brainstorm. O mais importante é gerar idéias e chegar ao objetivo.

[Minha Carreira]

Veja também:

1. 101 dicas para implementação do CMMI nível 3 – Parte I DAR – Análise de decisão e resolução 1. Crie um...

O timeline (linha do tempo) é uma demonstração gráfica dos acontecimentos. É uma ferramenta muito boa para demonstrar os grandes marcos de um projeto ou acontecimentos. É muito usada pela astronomia, biologia, geologia e principalmente história, normalmente nestas áreas, o timeline é utilizado para demonstrar acontecimentos passados, mas ele também pode ser utilizado para demonstrar eventos futuros.

No gerenciamento de projetos, o timeline pode ser utilizado para demonstrar a equipe os principais marcos do projeto. Por ser uma ferramenta gráfica onde as pessoas conseguem facilmente entender seu funcionamento e ele é mais fácil de compreender do que o bom e velho cronograma.

Vamos mostrar como utlizar um timeline e responder duas perguntas, a primeira é “o que é um timeline?” e a segunda é “Como implementar o CMMI 2?”

Em um timeline sempre colocamos os marcos (milestones) em uma ordem cronológica e estes marcos deve ter nomes de fácil compreensão. Você até pode explicar um elemento em um timeline, mas ai seria um outro tipo (diferente deste que vou mostrar).

Nosso exemplo trata de uma implementação CMMI 2 e tipicamente, este tipo de implementação leva 12 meses e contém estes marcos:

• Gap Analisys
• Planejamento
• Capacitação
• Processos & áreas
• Templates & Guias
• Revisão e ajustes
• Data de corte
• Novo processo
• SCAMPI B
• Ajustes
• SCAMPI A

Então, o seu timeline seria assim:

Quando da apresentação do timeline, você deve explicar cada elemento para que não haja entendimento equivocado sobre os mesmos. Neste nosso exemplo, vamos entender o que significa cada coisa.

Timeline de uma implamentação CMMI 2

Gap Analisys: O Gap Analisys (também conhecido como SCAMPI C) é uma análise preliminar da situação da organização em relação ao atendimento ao CMMI 2. Esta análise deve ser realizada por um especialista em CMMI verificando qual é a aderência da organização a cada área de processo do CMMI 2 e busca mostrar ao sponsor quais áreas devem ser trabalhadas. É uma atividade primordial para qualquer programa de melhoria de processos.

Planejamento: O Gap Analisys mostra o que deve ser trabalhado para ficar aderente ao CMMI 2 e com este “mapa” a organização deve elaborar um plano para este programa. Este planejamento deve conter recursos e fundos, envolvidos, milestones, análise de riscos, objetivos, etc. Nem é preciso dizer que este programa deve ser acompanhado e gerenciado.

Capacitação: A equipe que irá trabalhar no programa de melhoria de processos deve primeiramente conhecer o que é o CMMI, e para isso é muito importante a participação em um Curso de CMM.

Processos & áreas: Bom… já sabemos o que deve se trabalhado, já temos o planejamento e a equipe já foi treinada, então, mão a obra. A equipe deve analisar o processo atual e identificar ajustes para deixa-lo aderente ao CMMI. Também podem ser necessários ajustes na estrutura organizacional como por exemplo a criação de novas áreas, mas isso acontece normalmente nos níveis posteriores (OT, Medições, Qualidade, HM e outras)

Templates & Guias: Já que os processos já estão definidos, vamos elaborar os templates! Tenha templates para tudo e quanto mais explicativos os templates, melhor. Os templates nada mais são do que guias. Um template bem elaborado aumenta a compreensão do que deve ser feito e as chances de um produto bem feito.

Revisão e ajustes: A revisão deve ser realizada por um especialista em CMMI. Esta revisão visa verificar se a implementação esta boa e qual o risco em uma avaliação oficial. Após esta análise, muito provavelmente ajustes serão necessários.

Data de corte: A data de corte é um marco para a organização. A partir desta data todos devem utilizar o novo processo. Não se esqueça que todos devem receber treinamento no novo processo.

Novo processo: O novo processo é um marco simbólico para a organização e vista informar a todos que “Agora vamos utilizar o processo CMMI 2”. Este processo deve ser praticado por um certo período para sua institucionalização e aumentar a amostragem antes de uma avaliação formal.

SCAMPI B: O SCAMPI B é como se fosse uma avaliação oficial, mas não gera rating (não gera o nível). Ela é quase tão detalhada quanto o SCAMPI A e é uma excelente oportunidade para verificar se a empresa passaria em uma avaliação oficial. Com o SCAMPI B será possível verificar áreas de processo que ainda devem ser trabalhadas.

Ajustes: É muito difícil não ter ajustes após uma avaliação SCAMPI B, então, é bom reservar um período para realiza-los.

SCAMPI A: O SCAMPI A é a avaliação oficial CMMI propriamente dita. Ela irá dizer se a organização é ou não CMMI 2 e assim como o SCAMPI B, ela deve ser realizada por um Lead Appraiser. Apesar do resultado sair no final da avaliação, a mesma só poderá ser divulgada ao mercado após a auditoria do SEI. O resultado da avaliação poderá ser divulgado no site do SEI se a organização autorizar esta divulgação.

Enfim, neste exemplo você pode entender como utilizar o timeline e como é um programa de implementação CMMI 2. Recomendo o uso de timelines em gerenciamento de projetos pois será fácil para todos terem uma visão geral do que é o projeto.

Veja também:

1. 15 dicas sobre gestão (e como decidir melhor) Não suponha. Pergunte Não acredite cegamente… Verifique Analise os fatos...

Achei muito bom o podcast do Max Gehringer sobre gerência de projetos e decidi fazer comentários a respeito.

A história narrada era mais ou menos assim:

Uma empresa com muitos projetos mas a maioria não dava resultados. Certo dia decidiram availar o porquê. Dentre as principais razão estavam:

• As pessoas envolvidas mudavam muito de opinião;
• As pessoas se omitiam;
• As pessoas estavam mais interessadas em discutir com outros membros da equipe.

Diante disso um problema claro de liderança foi identificado, decidiram nomear um lider para cada equipe e elaboraram o manual do nunca.

1. Nunca peça exatamente a mesma coisa para duas pessoas
Isto parece óbvio, mas na prática acaba acontecendo. Duas pessoas podem ter entendimentos diferentes sobre a cerca da mesma atividade e isto pode gerar impasses, ou mesmo a execução incorreta de atividades.

2. Nunca acredite que uma pessoa que estudou mais que a outra sabe mais que a outra
Isto é um dos preconceitos que vez ou outra podemos nos deixar seduzir. Em minha opinião o que o autor quis dizer é: questione sempre se a pessoa escolhida é realmente a melhor opção para realizar aquela tarefa, averigúe, observe o que diz o histórico daquela pessoa.

3. Nunca de uma tarefa urgentíssima para um funcionário que sempre tem tempo livre. Dê para um que esteja super ocupado
Novamente aqui vai a minha visão: desconfie do funcionário que sempre tem tempo livre no tocante ao comprometimento. Pra mim, desconfiar significa estar sempre atento. Neste caso, acredito eu, o comprometimento é que é a palavra chave.

4. Nunca acredite que um problema já atingiu seu ponto Máximo. Tudo sempre pode piorar
Isto pode parecer exagero, mas é bom estar vigilante. Problemas em projetos podem ser um poço sem fundo. Nunca é demais se cercar de medidas para resolver problemas e para monitorar de perto

5. Nunca acredite na opinião de quem não pode tomar a decisão
Aqui não se trata de não ser sincero pura e simplesmente. A questão é: quem não tem o ônus de tomar decisão dá uma opinião “não comprometida com o projeto”, ou seja, não alinhada com os objetivos do projeto. É comum ver gente dando opiniões nas quais eles acreditam ser o melhor tecnicamente, mas não estão alinhados com os objetivos do projeto

6. Nunca delegue coisas que depois só você terá que explicar
Essa é uma das afirmativas que concordo em gênero, número e grau. Esta é bem direta e realmente é NUNCA. Quando se trata de colocar sua pele em jogo você delegaria a responsabilidade? Aquilo que você terá explicar caso dê errado jamais pode ser delegado.

7. Nunca tente convencer se você pode mandar
Esta pra mim é uma das mais controversas. Confesso que me chocou um pouco, pois sou favorável a sempre tentar convencer antes de mandar. Ou seja, usar sempre o convencimento como primeira alternativa. Acredito que isto ajuda a manter a equipe motivada. No entanto, tenho que concordar que mandar deixa as coisas mais rápidas. Para quem pensa assim a questão é saber se você tem ou não o poder de mandar. Já para quem pensa como eu (primeiro tentar o convencimento depois dar ordens) a questão é saber quando já se gastou tempo demais tentando convencer e que a hora é de decisão.

Gostou? Acesse o site da CBN e ouça outros comentários deste mestre.

[Fonte: Dia a dia de um Gerente de TI]

No related posts.