Gestão de Projetos

Governança, Risco e Conformidade

2011-11-08T11:04:00.000-08:00

Ao longo dos anos, a Tecnologia da Informação se tornou a espinha dorsal para o negócio de muitas empresas e deixou de ser uma opção, tornando-se um diferencial competitivo. Entretanto essa dependência exige muitos cuidados, tais como garantir que os investimentos em TI gerem valor ao negócio, que os processos de TI sejam eficientes e que a disponibilidade das operações seja mantida, além da necessidade de aderência aos processos contratuais, aos mecanismos regulatórios e à legislação vigente.

Para endereçar esses desafios, as empresas recorrem cada vez mais aos modelos e frameworks de Governança, Gestão de Riscos e Conformidade (Compliance) ou simplesmente GRC. Esses termos por muito tempo viveram em “ilhas”, como se cada um observasse o outro a partir da sua respectiva “praia”, e raramente uniam seus esforços, recursos, processos e sistemas para alcançar objetivos comuns. Felizmente isso vem mudando, pois tratar de GRC sob uma perspectiva integrada tem chamado a atenção de muitas empresas.

De acordo com o ITGI (IT Governance Institute), Governança é o conjunto de responsabilidades e práticas exercidas pelos executivos e pela alta direção da empresa com o objetivo de fornecer orientação estratégica, assegurando que os objetivos da companhia sejam alcançados e que os recursos sejam utilizados de forma responsável.

Existem padrões e guias internacionais de boas práticas de governança de TI que podem ser utilizados como referência, tais como: COBIT (Control Objectives for Information and related Technology), um framework de boas práticas de TI; ITIL (IT Infrastructure Library), um conjunto de melhores práticas para o gerenciamento de serviços de TI; ISO/IEC 27001, um padrão de sistema de gestão de segurança da informação, dentre outros.

A definição de Gestão de Riscos do Risk IT Framework, determina que essa atividade deve envolver todas as unidades de negócios da organização para prover uma visão abrangente de todos os riscos relacionados à TI. Uma estrutura corporativa de gerenciamento de riscos (Enterprise Risk Management) proporciona um maior alinhamento com o negócio, eficiência dos processos de TI, maior disponibilidade das operações com uma consequente redução de incidentes, tudo isso gerando valor ao negócio. Em empresas prestadoras de serviços, a gestão de riscos pode representar oportunidades de novos negócios.

Por fim, Conformidade é o ato de aderir e demonstrar adesão a leis e regulamentos externos, assim como a políticas e procedimentos corporativos. Controles internos devem ser implementados para garantir ainda a eficiência das operações e a confiabilidade dos relatórios financeiros. As “não-conformidades” custam caro, podem gerar impacto financeiro e afetar a imagem da empresa.

Uma pesquisa da Advanced Market Research com empresas nos Estados Unidos, estimou os investimentos em GRC, no ano de 2010, em US$ 29,8 bilhões, um crescimento de 3,9% em relação ao ano anterior.

Governança de TI, Gestão de Riscos e Conformidade não devem ser tratados como disciplinas isoladas pois a gestão centralizada dessas atividades é uma tendência irreversível. Além disso, GRC é parte integrante da gestão corporativa e proporciona o alinhamento estratégico com o negócio e a entrega de valor, além de uma melhor gestão dos recursos e do desempenho da TI.

Com a crescente exigência do mercado (interno e externo) por transparência e responsabilidade, as melhorias em GRC representam um diferencial competitivo que pode proporcionar crescimento e abertura de novos mercados para as empresas. É a convergência de três áreas de conhecimento fazendo a diferença. 1 + 1 + 1 nesse caso é muito mais do que 3

Gestão por Competências, é hora do C.H.A.

2011-09-07T08:15:00.000-07:00

Podemos afirmar que gerir pessoas é uma ciência em constante evolução e repleta de desafios. Neste contexto, um modelo que vem se tornando cada vez mais notório nas organizações é a chamada gestão por competências, na qual o objetivo principal é melhorar o preparo dos colaboradores em busca de maior produtividade e adequação ao negócio valorizando assim o capital intelectual da organização.

Com base nesta premissa, gerir competências significa coordenar e incentivar os colaboladores a reduzirem os gaps (necessidades de melhoria), saber o que eles são capazes de executar (competências atuais) e entender o que a empresa espera deles (competências requeridas).

O termo “competência” pode ser representado por três propriedades correlacionadas, resumidas na sigla C.H.A. – Conhecimento, Habilidade e Atitude. O conhecimento refere-se à assimilação de informações que a pessoa cumulou no decorrer da vida e que causam impacto sobre seu julgamento ou comportamento – o saber. Já a Habilidade refere-se à aplicação produtiva do conhecimento – o saber fazer. Por fim, a Atitude refere-se à conduta da pessoa em situações distintas e na sociedade – o agir.

Para exemplificar a aplicação deste conceito em uma organização, vamos imaginar que numa escala de zero a dez, a sua habilidade em “Negociação” seja seis, e, supondo que o grau mínimo requerido pela empresa seja dez, podemos afirmar que você tem um gap de valor quatro nesta competência.

Com base nesse resultado, e, juntando-se os resultados de outras técnicas de análise de desempenho como o Feedback 360º, cria-se um plano de redução de gaps, através do qual a empresa vai sugerir como e quando esses gaps serão trabalhados. O intuito é aprimorar as competências existentes de maneira alinhada aos objetivos estratégicos da organização, através de um plano de desenvolvimento profissional individual.

A implementação da gestão por competências não é complexa, porém requer alguns métodos e instrumentos específicos. Ter a missão, visão, valores, objetivos estratégicos, e processos bem definidos são alguns dos passos fundamentais para a sua adoção.

Cabe ao RH definir a matriz de competências requeridas juntamente aos gestores de cada área. Outro fator essencial é manter a comunicação ativa durante todo o projeto, a fim de esclarecer os objetivos e manter os avaliados informados. É importante, ainda, salientar que a falta de preparo das pessoas para avaliar e dar feedback e a resistência de alguns colaboradores podem dificultar a adoção do modelo. No entanto, tal dificuldade pode ser mitigada através da capacitação prévia e conscientização.

O uso da tecnologia pode ser um acelerador, já que auxilia na identificação e armazenamento histórico das competências, além de permitir a geração de gráficos e relatório para análise.

Seguindo esse modelo a empresa poderá estruturar melhor os papéis profissionais e competências fundamentais para o negócio, aumentar a eficácia na execução das tarefas, identificar talentos e garantir que seus profissionais apresentem os diferenciais competitivos exigidos pelo mercado.

Assim, a gestão das competências é flexível o bastante para ser adotada em empresas de qualquer porte, desde pequenas organizações até multinacionais, mostrando ser viável e eficiente em múltiplos cenários.

Empresas como Coca-Cola, Embraer, IBM, Petrobras e Shell, entre muitas outras, já adotaram medidas voltadas para a gestão por competências e relataram melhorias significativas em termos de eficácia na execução das tarefas, reconhecimento e motivação dos funcionários, entre outros benefícios.

Em suma, cabe à empresa utilizar esses modelos num ciclo de melhoria continua no qual, a cada novo projeto ou ciclo de avaliação, novos indicadores deverão ser criados e os antigos re-avaliados, de forma a mensurar os resultados obtidos e planejar os próximos passos. E é dentro desse contexto que a gestão por competências busca a excelência corporativa e a satisfação daqueles que representam o maior bem de uma empresa: as pessoas.

Project Finance

2011-07-21T16:54:00.000-07:00

Project Finance, em sua tradução literal, quer dizer "Projeto Financeiro" mas não se resume a estruturar a parte financeira de um projeto e sim a estruturar um projeto a partir de suas finanças.

Desta forma, a maior parte da literatura de nossa área prefere adotar o termo em inglês, para evitar o que aconteceu com "Derivatives" que, traduzindo, deveria chamar-se "Derivados" e não "Derivativos" como ocorreu na terra brasilis.

Um projeto torna-se um “Project Finance” a partir do momento em que é criada uma “Sociedade de Propósito Especifico” – SPE. Esta sociedade, juridicamente aparte dos grupos credores, não aparece nos balanços contábeis de seus empreendedores. A garantia dos credores esta no próprio fluxo de caixa futuro do projeto.

As principais vantagens de transformar um projeto em um Project Finance são:

· CNPJ distinto dos sócios

· Recebíveis: fluxo de caixa e ativos do projeto

· Transparência na execução e demonstração de resultados

· Balanço contábil dos empreendedores menos endividado

Já a principal desvantagem é:

· Custo elevado: contratação de equipe especializada de financistas, advogados e contadores

Quando as empresas estão participando de uma licitação cujo resultado será um Project Finance, elas geralmente lançam mão de garantias. Estas garantias incluem:

· Bid Bond: garante ao licitante indenização caso o vencedor não assine o contrato.

· Performance Bond: garantia de que, caso ganhe a licitação, a empresa de fato executará o projeto até o seu final, ou seja, garante-se o desempenho do projeto.

· Maintenance Bond: indeniza o licitante em caso de baixa qualidade do projeto executado, ou seja, ao contratar esta garantia afirma-se a qualidade do que será executado.

Em relação ao fluxo de caixa advindo do projeto executado, temos as seguintes figuras:

· Trustee: banco encarregado pela conta do projeto

· Escrow account: conta a qual receberá as receitas para que sejam acumuladas e para que, posteriormente, seja pago o financiamento.

É um equivoco pensar que um Project Finance, apesar de seus custos, esta restrito a grandes empresas. O Sebrae possui uma cartilha que visa mostrar as vantagens da criação de uma SPE no segmento de pequenas e medias empresas.

Sendo assim, é importante verificar qual tipo de projeto estamos a gerenciar, um Project Finance ou um projeto financiado através de Corporate Finance, devido as características distintas de cada um deles.

Gerenciamento de Projetos em Eventos Culturais

2011-07-19T17:33:00.000-07:00

Tive a oportunidade visitar a Gibicon Nº 0 - Convenção Internacional de Quadrinhos, que aconteceu em Curitiba, de 15 a 17 de julho de 2011. O que mais me impressionou, foi o grande número de palestras, workshops, exposições, sessões de autógrafos e outras atividades ocorrendo simultaneamente, que envolveram nada menos do que 7.000 pessoas. Isto me levou a pensar sobre as dificuldades no planejamento de eventos desta natureza. A própria definição de sucesso já é bastantes complicada, como mapear e gerenciar as expectativas de tantas partes interessadas (stakeholders)? São artistas, patrocinadores, colaboradores, apoiadores políticos, apoiadores culturais e o público em geral, todos esperando o melhor possível.

Gerenciar os outros aspectos do projeto também não é tarefa fácil. Ao definir o escopo, há muitos detalhes que precisam ser muito bem amarrados para que tudo ocorra bem. Desde o fluxo das pessoas de um espaço para o outro até os copinhos de café. Tudo isso gera uma EAP (estrutura analítica do projeto) gigantesca, que precisa ser dividida em muitas áreas de responsabilidade para que possa ser manipulada. O cronograma é um desafio à parte, devem ser previstos muitos deslocamentos, buffers podem ajudar, mas é preciso ter em mente que ele sofrerá muitas alterações, pois há muita dependência de fatores externos.

O controle financeiro é extremamente complexo e os riscos relacionados ao evento indicam a necessidade de reservas de contingência. E se chover? E se fizer sol? E se um dos espaços não puder ser utilizado? São muitas perguntas que geram um plano de gerenciamento de riscos enorme. Do ponto de vista da comunicação, os eventos culturais geram muito trabalho, há muitos interesses envolvidos e que precisam ser atendidos sem que haja conflitos entre os stakeholders, afinal de contas, qualidade significa satisfazer expectativas.

O ponto mais nevrálgico, no entanto, é o gerenciamento de recursos humanos. Em última instância, são as pessoas que fazem a mágica acontecer. Um único indivíduo pode colocar todo o trabalho em risco. Por isso, é importante que haja um organograma claro e bem estruturado. Todos precisam saber exatamente o que fazer, quando fazer e a quem recorrer para resolver problemas operacionais e/ou conflitos.

No encerramento da Gibicon, o que vi foram elogios rasgados à organização, que devo admitir, foi impressionante. Todos os espaços estavam lotados e havia um misto de felicidade e espanto no ar. Primeiro porque havia muitos artistas internacionais e nacionais interagindo diretamente com público. Segundo, porque muitos não esperavam que o festival tivesse tamanho impacto e repercussão no Brasil e até no exterior. As pessoas estavam em êxtase, vendo ao vivo os artistas que dão forma e cor à muitos de seus heróis. Não há indicador melhor do sucesso do evento do que o comparecimento maciço do público e a vontade de "quero mais" que ficou no ar.

Parabéns à toda equipe!!!

Provérbios sobre gerenciamento de Projetos

2010-02-25T15:26:00.000-08:00

Olá amigos redatores e leitores!
Depois de muito tempo distante, resolvi compartilhar um artigo que li em um site e apesar de ser uma mistura de diversão, verdades e nem tantas e não não ser um assunto muito sério, compartilharei da mesma forma com vocês...

Então ai vão alguns "provérbios" vamos tratar assim, sobre gerenciamento de projetos:

01 – Você não consegue produzir um bebê em um mês usando nove mulheres.

02 – O mesmo trabalho, sob as mesmas condições será estimado de forma diferente por 10 diferentes analistas ou por um mesmo analista em 10 diferentes vezes.

03 – A palavra mais útil e menos usada em gerenciamento de projetos é “NÃO”.

04 – Você pode convencer um idiota a assumir um prazo irreal, porém, você não pode obrigá-lo a cumpri-lo.

05 – O prazo mais ridículo é o mais caro e dificultoso de se cumprir.

06 – Quanto mais desesperada a situação, mais otimista ela o é.

07 – Poucas pessoas em um projeto conseguem resolver os problemas – porém muito mais pessoas criam problemas acima da capacidade das primeiras resolverem.

08 – Você pode congelar os requisitos de um sistema, porém não consegue congelar as expectativas.

09 – Congelamento de requisitos e o abominável homem das neves são parecidos – ambos são mitos e ambos se derretem quando calor apropriado é aplicado aos mesmos.

10 – As condições sob as quais uma promessa e feita são esquecidas, porém, a promessa será sempre lembrada.

11 – Aquilo que você não conhece o ferirá.

12 – Um usuário somente falará o que lhe for perguntado – nada mais.

13 – Diante de varias interpretações de um comunicado, a menos conveniente é a mais correta.

14 – O que não está escrito, não existe ou não foi dito.

15 – Parkinson e Murphy estão vivos e muito bem – no seu projeto.

16 – Quem não sabe aonde vai, nunca chega.

17 – Para quem está perdido, qualquer caminho serve.

18 – Para quem está perdido, um mapa não resolve.

19 – Noventa por cento do trabalho em um projeto, equivalem a 90% do planejado, os outros dez por cento, consomem os restantes 90% do trabalho.

20 – Prazo de sistemas e fidelidade são promessas difíceis de se cumprir.

21 – A única situação onde você tem tudo sob controle é quando você está morto.

22 – A demissão de um elemento da equipe, quase sempre é a preservação do emprego do resto.

23 – Depois que passei a estudar mais, trabalhar mais e planejar melhor, minha sorte mudou.

24 – Em projetos, não confunda folga nos prazos, com prazos dos folgados.

25 – Normalmente coisas ruins estão ligadas à palavra “usuário” – usuário de drogas, usuário de ônibus, usuário de álcool, usuário de sistemas. . .

26 – No caso de uma crise total no andamento de seu projeto – melhor do que a presença de espírito é a ausência de corpo.

27 – A logística de um projeto sempre exige àquilo que você esqueceu.

28 – Reunião sem pauta vira happy-hour.

29 – Reunião sem ata, não existiu.

30 – Para o usuário – o que você esqueceu sempre é o mais importante.

31 – Em projetos – quando um cachorro te morde, não é boa política correr e morder a perna do cachorro (porém, você pode sutilmente, colocar veneno na sua comida).

32 – O mérito por um projeto bem sucedido é como o funcionamento de um haras – A égua é um animal tão forte quanto o cavalo, e quando ela entra no cio, se torna violenta e trata o seu pretendente a coices e mordidas durante as preliminares sexuais. Como o cavalo puro-sangue é um animal muito valioso, o haras, para não machucá-lo, mantém um plantel de cavalos de baixa categoria (pangarés), chamados de rufiões e durante as preliminares sexuais, é sempre colocado um ou mais desses pangarés para exaurir a fêmea e esse animal (normalmente menor do que a égua) sofre o diabo nas patas e dentes da fêmea no cio, adicionalmente, esses pangarés têm uma cirurgia em seu pênis de forma a deixá-lo torto para evitar que acidentalmente consiga êxito. Quando a égua está exausta e receptiva ao macho, o pangaré babando é retirado e é substituído por um puro-sangue para a parte final do processo (óbvio a melhor parte). Em projetos de sistemas, sempre existe um plantel de pangarés que sofre todos percalços do projeto, isto é, todos coices e mordidas, e na hora da inauguração são substituídos, isto é, será chamado o puro-sangue de plantão para receber a melhor parte (promoção, prêmios, parabéns, elogios, etc.).

33 – Quando tudo estiver perdido – finja-se de morto. [pelo menos, por enquanto, as pessoas ainda respeitam os mortos (por um dia)].

34 – Equipe muito grande em projetos é como chinês fazendo túnel, eles colocam um buzilhão de chineses de um lado da montanha e outro buzilhão do outro lado. Se tudo der certo eles fazem um túnel, se der errado eles fazem dois.

35 – Equipe muito grande é como dinossauro, você tira um bife da ponta do rabo, até a dor chegar ao cérebro leva dois anos.

36 – Grupo de trabalho – quando você está dentro é equipe ou grupo de trabalho; quando você está fora é panela.

37 – Todo chefe tende a ser incompetente. (Peter, L.J.)

38 – Para tocar o seu projeto, conheça bem: o organograma, o mandograma, o orfacograma, o mafiograma, e fundamentalmente, o secretariograma.

39 – Se tudo aparentemente está andando bem, é porque você não olhou direito.

40 – A empresa só te paga para trabalhar, quando você fica nervoso isso é de graça.

41 – Todo membro incompetente da sua equipe é zelosamente pontual nos horários de entrada, almoço e saída. Porém, sua presença não agrega conteúdo, portanto, atrapalha a pontualidade dos prazos do projeto.

42 – A inteligência total do universo é constante, porém, continuam nascendo mais pessoas.

43 – A proporção de analfabetos de ontem com os de hoje, continua a mesma, porém, os analfabetos de hoje, sabem ler e escrever. (Moravia, A.)

44 – Nem se deita vinho novo em odres velhos; do contrário se rebentam, derrama-se o vinho, e os odres se perdem; mas deita-se vinho novo em odres novos, e assim ambos se conservam. (Bíblia, Matheus 17). Leitura sistêmica, não desperdice códigos novos em sistemas velhos e nem remonte sistemas velhos para ficarem novos.

45 – Quando seu chefe diz que vai colocar alguém para te ajudar, provavelmente você já foi demitido, é só uma questão de tempo.

46 – Quando o teu chefe pede para colocar no papel a sua brilhante idéia, é porque ele nunca vai vê-la.

47 – Reunião com mais de 2 horas, vira big brother.

48 – Não existe conflito quando a hierarquia é diferente.

49 – Quando um funcionário lhe procura para contar sobre uma idéia e você pede para que ele coloque no papel a sua idéia, essa atitude é a melhor maneira de bloquear a criatividade.

50 – Só erra quem esta inovando.

51 – O inferno não é tão ruim quando você é amigo do diabo.

52 – Qualquer que seja o seu projeto, ele nunca andará se a liderança estiver não mãos de um acadêmico, principalmente se o mesmo for doutor.

53 – A melhor maneira de um projeto não sair é designar uma equipe para decidir sobre a implementação do mesmo.

54 – Decisões são processos democráticos (toma-se em grupo), fazer é um processo ditatorial (deve ter um mandando). Adizes.

55 – Respeito aos membros da equipe alem de humano, protege os dentes.

56 – Respeito de forma geral protege os dentes.

57 – Membro canalha da equipe, é como cobra, só não te morde se estiver morto.

58 – “Bandido” em equipe de trabalho não é ser humano é doença oportunista.

59 – Os maus funcionários de uma equipe tendem a cada dia serem piores, pois todas noites de suas vidas eles são obrigados a dormir com um incompetente.

60 – Funcionária incompetente que sabe administrar a “piriquita” estraga a equipe e prejudica a empresa.

61 – Superior que transa com funcionária incompetente dando em troca favores profissionais, atingiu o nível mais baixo de inferioridade que o ser humano pode chegar.

62 – Ver um ser humano julgando a outro, é um espetáculo que me mataria de rir se não me causasse pena. Pitigrilli.

63 – Estola de peles é um animal que trocou de dono. Pitigrilli.

64 – Ninguém engole sapo pelo valor nutritivo do bicho. Veríssimo.

65 – Tirado de uma fonte é cópia, tirado de duas é plágio, porém, tirado de três é pesquisa.

66 – Não importa a qualidade de seu trabalho, a banca formada por acadêmicos só sabe ver a forma.

67 – Para ferrar o projeto da concorrência, indique um doutor para ajudá-los.

68 – Reconhecimento de chefe e coice de porco são parecidos, ambos são raros e quando ocorrem são curtos.

69 – Quando o gerente encontra a equipe feliz, ele fica infeliz, se perguntando onde foi que errou, não entendendo porque as pessoas estão contentes e rindo.

70 – Dize-me do que te gabas e direi o que te faltas. Freud.

71 – Em sistemas deve ser abolido o termo subentendido.

72 – As relações humanas contrariam as leis da física: quando efetivas, o somatório das partes é maior do que o todo; e quando falsas, o somatório do todo é menor do que as partes.

73 – O diabo tem dois nomes: esposa e gerente.

74 – Em projetos para calcular a parábola formada por uma pedra atirada a 30 metros, existem analistas que entrevistam a pedra.

por GUILHERME SILVA

Qual a real função do analista?

2010-02-25T03:21:00.000-08:00

Quero começar compartilhando um artigo de um blog que li, muito interessante.

Qual o verdadeiro papel do analista? O perfil dele deve ser de desenvolvedor como o mercado hoje exige, ou deve ser alguém totalmente independente de tecnologia e focada apenas no entendimento das regras de negócio?

Segundo Philip, o autor deste artigo, o analista deve ser focado nas regras de negócio.

"O analista deve trabalhar em conjunto com os stakeholders para gerar uma visão única do projeto (já que possivelmente cada stakeholder que uma coisa diferente) e transformar isso em algo que possa ser executado (histórias). No meio do caminho eles ajudam a eliminar desperdício, introduzir idéias novas, validar os pedidos, conferir viabilidade e tudo mais que não faz parte do papel de um desenvolvedor e sim de alguém que, de fato, entenda do negócio do cliente."

"Note que o papel do analista de negócios não elimina a necessidade de termos um cliente presente. Não existe mapeamento de requisitos ou coisas do tipo, além de usar seu expertise naquele domínio em específico, o analista de negócios age como facilitador e não como ponte entre cliente e desenvolvedores. Ele também não é um tradutor, os termos de negocio e os processos devem ser entendidos por todos os envolvidos."

Particularmente, eu sou de acordo com a idéia que o analista deve sim ser expert em entender a regra de negócio, ou ainda, ter perfil de negociador, isto é, alguém que sabe como fazer o cliente expor as informações chaves e necessárias para solução do problema dele, e principalmente para convencer o cliente do que ele realmente necessita. Pois o que temos hoje são equipes que possuem desenvolvedores que não entendem do negócio e clientes que não sabem exatamente o que necessitam, resultando em sistemas que vão ao ar não contendo "exatamente o que o cliente necessita, seja por falha de comunicação ou porque ele mudou de idéia e “esqueceu” de avisar aos desenvolvedores".

Para uma metodologia mais ágil de gerenciamento de projetos, essa visão de analista seria muito mais eficaz, uma vez que o analista seria o facilitador para que a equipe pudesse trabalhar de forma mais objetiva e específica, atuando no problema bem definido e não na "lista interminável de desejos do cliente" que só descobre não serem necessários no final, quando já se gastou muito tempo e esforço para o seu desenvolvimento.

Portanto é preciso avaliar cada cenário e diagnosticar qual será a verdadeira função de um analista dentro de cada cenário.

Quem quiser ler o artigo do Philip, acesse: http://blog.fragmental.com.br/2008/11/23/deixa-para-os-analistas-de-verdade/ - Deixa Para os Analistas de Verdade… por Philip Calçado

Coaching – A conquista de Objetivos

2010-02-06T04:05:00.000-08:00

Com certeza você já deve ter ouvido falar sobre Coaching, talvez você saiba o que é ou tenha uma pequena noção desse maravilhoso processo. De uma forma simples e rápida vou explicar para você o que é Coaching e para que serve!

Existem alguns tipos de Coaching, o Coaching Pessoal e ou Executivo, neste momento vou focar no Coaching Pessoal, a principal diferença entre os dois é, que o PESSOAL foca o objetivo individual de uma pessoa, já o executivo é para trabalhar com os objetivos da Empresa.

Definição:

COACHING é um processo interativo e individual que auxilia pessoas a se desenvolverem rapidamente e a produzirem resultados mais satisfatórios em suas vidas pessoais e profissionais.
Uma alternativa poderosa para pessoas que sabem que o sucesso pessoal ou corporativo não é um ponto de chegada, mas um caminho, que necessita de planejamento, superação de obstáculos, excelência pessoal, motivação, equilíbrio e transformação individual.

COACHING é uma assessoria pessoal em que um profissional permanece com você e o ajuda a implementar suas novas habilidades e mudanças. É focado em garantir que seus objetivos realmente se realizem.

Obs.: Curiosidade, Kócs é uma cidade húngara onde a palavra foi utilizada pela primeira vez para designar "carruagem de quatro rodas".

Normalmente as pessoas confundem o processo de Coaching com Terapia, mas a diferença entre COACHING e TERAPIA é muito simples. O COACHING é pragmático, objetivo, planejado, visa um alvo determinado e opera a partir do pressuposto de que as pessoas já possuem os recursos de que precisam, faltando apenas alguém para ajudar a acessar estes recursos.

É importante lembrar que Coaching NÃO É terapia, aconselhamento, psicologia, consultoria ou mentoring, como foi dito anteriormente Coaching é uma abordagem pragmática focada na realização de um ou mais objetivos específicos.

Conhecendo os Nomes:
O Coach, esse é o profissional que conduz a sessão.
O Coachee, esse é o Cliente.
Coaching é o processo entre o Profissional (Coach) com seu Cliente (Coachee).

Contato:
Quer realizar seus Objetivos?
Se SIM, entre em contato comigo, posso te ajudar chegar lá.

Cesar Campos é PERSONAL & PROFESSIONAL COACHING pela Sociedade Brasileira de Coaching.

Reflexão de 2009 – Lições aprendidas

2009-12-30T05:31:00.000-08:00

Chegamos ao final de mais um ano... Para muitos o ano é um projeto no qual as pessoas planejam alcançar objetivos em sua vida pessoal ou até mesmo profissional. Muita gente visualiza um sonho como um projeto, só que poucos efetivamente planejam esse sonho para torná-lo realidade e raramente monitoram sua execução durante o ano.

Este momento do ano é importante para fazermos uma reflexão de tudo que fizemos durante o ano de 2009, respondendo algumas perguntas e analisando se alcançamos aquilo que tínhamos “pensado” e/ou “planejado”.
Algumas perguntas que você pode refletir:

Quais eram as suas metas no início do ano de 2009?
As metas foram as mesmas até o final do ano? Por quê?
Quantas metas você conseguiu atingir com sucesso? Por quê?
Liste quais foram as falhas das metas que você não atingiu. E identifique a onde você falhou e o por quê?
Essa “meta” foi planejada ou era um “sonho”?
Obs.: Lembre-se que sonhos não se realizam, a não ser que se transforme em missão e num ideal... no qual irão traçar sua meta; e que por final deve ser planejada e monitorada.
Você efetivamente planejou, executou e monitorou seu projeto durante todo o ano?

De uma forma simples você pode parar um pouco e refletir sobre essas perguntas, veja se você consegue responder todas claramente. Tente fazer isso e criar uma lista de lições aprendidas de tudo que você falhou ou até mesmo poderia ter feito melhor. E num próximo projeto semelhante lembre-se de consultar esse documento.

Duas ferramentas interessantes que pode ajudar você a desvendar um projeto é, utilizar:

Mapa mental
5w2h

Mapa Mental:
Mapa mental é o nome dado para um tipo de diagrama, sistematizado pelo inglês Tony Buzan, voltado para:

gestão de informações, de conhecimento e de capital intelectual;
para a compreensão e solução de problemas;
na memorização e aprendizado;
na criação de manuais, livros e palestras;
como ferramenta de brainstorming;
e no auxílio da gestão estratégica de uma empresa ou negócio.

Em um próximo artigo falo mais sobre os mapas mentais. Para aqueles que quiserem mexer um pouco com mapas mentais podem utilizar o software free, XMind (http://www.xmind.net). Recomendo esse software!

5w2H
O 5W2H é basicamente um formulário para execução e controle de tarefas onde são atribuídas as responsabilidades e determinado como o trabalho deverá ser realizado, assim como o departamento, motivo e prazo para conclusão com os custos envolvidos.

Recebeu esse nome devido a primeira letra das palavras em inglês:

1 – What (o que será feito),
2 – Who (quem fará),
3 – When (quando será feito),
4 – Where (onde será feito),
5 – Why (por que será feito).

1 – How (como será feito),
2 – How Much (quanto custará)

Com isso fecho esse último artigo do ano de 2009, eu Cesar Campos desejo a você e sua família um ótimo ano novo com muita Saúde e Paz, por porque o resto nós corremos atrás planejando, executando e monitorando nossos projetos profissionais e pessoais.

Feliz Ano Novo.
Faça de 2010 um ano diferente, planeje seu sucesso!

Um Grande Abraço
Cesar Campos

Seleção de projetos – o modelo de pontuação

2009-12-06T16:29:00.000-08:00

Existem algumas técnicas para selecionar um projeto na organização, irei apresentar aqui um modelo bastante interessante e muito utilizado que é o modelo de pontuação.

O modelo de pontuação ou modelo de pontuação ponderada é simples de ser aplicado, vamos imaginar que o comitê de seleção deve primeiro especificar os critérios a serem utilizados no modelo de pontuação – por exemplo:

Observe que para cada critério foi colocado um peso que vária de 1 a 5, ou seja, o peso maior caracteriza ao resultado mais desejável para a empresa e o menor é o “menos desejável”. Com os critérios e pesos definidos, basta iniciar o processo de votação.

Veja a tabela abaixo:

De acordo com nossa tabela o projeto escolhido seria o Projeto B.
Este modelo de seleção também pode ser utilizado para selecionar propostas concorrentes para projetos terceirizados.

O Dogma e o Ateísmo

2009-11-30T03:35:00.000-08:00

Calma, não tem nada a ver com religião. Achei o título apropriado para fazer uma analogia interessante – de pessoas que acreditam que a aplicação de metodologias, modelos, padronizações, e boas práticas é o caminho para o sucesso(o dogmático) e outras que não enxergam nenhum valor prático nisso e que essas coisas só atrapalham seu trabalho(o ateu).

Vamos começar falando sobre o “Ateu”. Ele é presente em todas as estruturas da empresa. É uma pessoa prática e ligada diretamente no resultado do SEU trabalho ou no trabalho de seus companheiros diretos ou sua equipe direta.

Antes de mais nada, e antes de ser descrente, o “ateu” acredita que não acredita em nada, e isso é muito significativo. Isso não significa que os “ateus” são pessoas fechadas a novidades ou inovações na sua forma de trabalho ou mesmo a instrumentos corporativos, o que acontece é que em geral eles eles gastam muita da sua energia para combater ou resistir ao que eles acham pouco produtivo ou errado. E são pouco flexíveis quanto ao que eles acreditam. Não os leve a mal, se você pensar bem, isso tudo é muito coerente não é mesmo?

Em outras palavras se você não conseguir explicar no papel como a ITIL, o COBIT, a ISOxxxx, as leis de trânsito ou qualquer conjunto de regras seja diretamente proveitoso ao seu trabalho direto(agregando algum valor) você terá resistência certa. Isso é especialmente difícil, pois esse tipo de profissional é extremamente competente e sempre se assegura que faz seu trabalho da melhor forma. Aqui está o grande desafio dos “middle managers” que tem o papel de não permitir que idéias diferentes da organização se disseminem*(e inclusive, consequentemente, que todos pensem uniformemente com as diretivas da empresa).

Em contra-partida, o “Dogmático” acredita que o único caminho para redenção é a aplicação de metodologias e boas práticas. Ele estuda isso, tira suas certificações, procura cases de sucesso, veste a camisa mesmo, até briga com quem fala que não funciona. (Mas uma vez, aqui existe um ponto de coerência. Aceitar que estas coisas como algo não-funcional significa que você jogou tempo e dinheiro no lixo e ninguém quer isso não é?)

O “Dogmático” enxerga valor nas boas práticas e em geral é bem relacionado na estrutura funcional da empresa. (Afinal de contas se ele não for, ele passa de chato para maluco!) Não obstante, em geral consegue algum apoio gerencial para a aplicação das metodologias – afinal de contas são boas práticas do mercado, ora bolas!

Existem alguns “pecados” que alguns “dogmáticos ” realizam com freqüência. O principal deles é deixar de lado o fator cultural da empresa, e tentar aplicar melhores práticas que as vezes não são aplicáveis, necessárias, ou que existe a necessidade de um fator intermediário para ser alcançado antes de sua aplicação plena. Infelizmente isso é bem freqüente e tem sido o motivo de alguns “rollbacks” na implementações de boas práticas nas empresas. O fator humano é um deles. Em algumas empresas públicas ou com o “espírito de empresas públicas”, muitas vezes é difícil mudar hábitos, e isso deve ser respeitado e levado em conta nos planejamentos, ou então, como diz nosso amigo Silvio Luiz, é “fechar o caixão e beijar a víuva” para seu projeto de implementação.

Então qual o melhor perfil? A resposta é muito simples, como tudo na vida os extremos em geral são prejudiciais, dessa forma uma atitude equilibrada e adaptável é a melhor opção.

Como gestor, é importante enxergar o valor das boas práticas e apoiá-las. Ao mesmo tempo, é importante assegurar sua aplicabilidade. Muitas das metodologias são genéricas(alguns devem ser utilizadas como “frameworks”) e precisam ser customizadas para sua realidade. NEM TUDO PRECISA SER APLICADO no primeiro momento e E NEM TUDO É APLICÁVEL. Em alguns lugares um nível intermediário de maturidade é necessário para usufruir os resultados desejados. E certamente em alguns lugares não vale apena sua aplicação (pelo menos plena), em especial quando regras duras e inflexíveis prejudiquem a produtividade de seus funcionários.

Resumindo, proteja a produtividade de seus funcionários mas procure mostrá-los o valor de algumas regras e controles.

Bons Projetos e Sucesso.

Leandro Santoro.

*A atribuição do papel dos “middle managers” é de autoria de Eric Raymond, numa palestra que ele realizou no FISL 6.

Comunicação em Projetos – arte de ouvir

2009-11-24T15:30:00.001-08:00

Uma das áreas mais importantes em Gerenciamento de Projetos é a Gestão da Comunicação. E pelo fato de ser uma das mais importantes, também é uma das grandes "vilãs" para o sucesso do projeto.
Todos nós sabemos que um projeto é formado por uma equipe de pessoas, sendo assim vem um grande problema: Como lidar com as diferenças de personalidades dessas pessoas? Como motivar essa equipe? Como gerenciar os conflitos, os interesses?
Esses são alguns dos problemas que encontramos quando trabalhamos com pessoas.

Normalmente em projeto de grande porte, existe um plano de comunicação bem elaborado e também pode haver um membro da equipe responsável para gerenciar a comunicação de todo o projeto.
É fato que em projetos menores muitas vezes a comunicação não é exercitada de maneira eficiente e nem um plano de comunicação existe. Por exemplo, na fase de levantamento de requisitos se não tivermos uma boa comunicação com os stakeholders, certamente não conseguiremos absorver e anotar as suas expectativas. Por outro lado se não conseguirmos sanar as dúvidas de um membro da equipe ou até mesmo deixar claro as suas responsabilidades no projeto, ou seja, o que ele deve entregar e como entregar.
Certamente esses dois casos irão ajudar muito para o fracasso do projeto. [Isso é fato!]

Existem algumas dicas e técnicas que podem nos ajudar:

Para Stakeholders:
* Na fase de levantamento de requisitos, crie uma planilha RTM - Requirements Traceability Matrix, onde você irá listar as expectativas do seu stakeholder e a sua influência no projeto;
* Ouça e escute o que ele tem a dizer, não influencie o mesmo para seus objetivos;
* Esclareça as suas dúvidas em relação às necessidades do mesmo;
* Após identificar o interesse do stakeholder temos que procurar trazê-lo para o projeto para ajudar, ou ao menos, para não atrapalhar o projeto;
* Se você é o líder do projeto, após identificar todas as expectativas do stakeholder converse com o Gerente de Projetos da organização para debater tais itens, esclarecendo todas as dúvidas que surgirem;

Para Equipe:
* Tenha o hábito de anotar suas dúvidas, por mais simples ou complexas que elas possam parecer;
* Determine um prazo alvo para suas dúvidas serem esclarecidas, caso esse prazo chegue ao limite, cobre por respostas;
* Caso precise passar algum pacote de trabalho para um membro da equipe, elabore um dicionário da EAP referente ao trabalho. Seja claro para expor os detalhes e aceitação de tal pacote de trabalho;
* Conversas freqüentes e informais com a equipe ajudam;

Não podemos esquecer que alguns membros da sua equipe serão tímidos, por isso não deixe de convidá-lo para uma conversa, nem sempre o fato de ser calado significa que ele não tem nada para dizer.

Os Líderes e os Gerentes de Projetos precisam ser um bom ouvinte, mas aí vem a pergunta:

Como tornar-se um bom ouvinte?
A habilidade de ouvir bem, como muitas outras coisas na vida, é uma questão de simples treino. Algumas pessoas já aprenderam a ouvir, outras ainda precisam desenvolver essa habilidade. Nunca é tarde, para se desenvolver essa capacidade.

Alguns exercícios:
* Assuma consigo mesmo o compromisso de treinar diariamente por cinco minutos, estipulando a ocasião durante o dia em que pretende praticar;
* Escolha pessoa ou situação que vai proporcionar a oportunidade para o treinamento (subordinado, colega, mulher ou marido, primeira pessoa que entrar em seu gabinete, etc.);
* Procure ficar ouvindo a pessoa em questão durante o prazo já estipulado;
* Evite interromper, acumulando dúvidas eventuais para esclarecer em momento oportuno;
* Observe seu próprio comportamento: como é a experiência de ouvir?
* Você tem muita vontade de interromper ou de completar as frases do outro?
* Você chega a desligar, permitindo que outros assuntos invadam seu espaço?
* Você chega a ficar ansioso, impaciente?
* Repita o exercício diariamente durante três semanas, procure corrigir as disfunções à medida que você as identifica;

A habilidade de ouvir conquista-se por meio do domínio de uma série de pequenas técnicas e atitudes que serão adquiridas com treino e tempo.
Simplesmente a comunicação é fundamental em projetos e o ato de ouvir é uma peça fundamental para um líder ou um gestor. Ouvindo podemos aprender ou perceber algo novo, enquanto o ato de falar nos limita ao processamento de idéias já formadas. Sendo assim vale a pena investir na habilidade de ouvir.
Com uma boa comunicação e com a capacidade de ouvir um membro da equipe, você conseguirá identificar detalhes importantes do projeto para seu sucesso. Além de estar sendo um profissional mais eficaz e, ao mesmo tempo, irá aprimorar sua imagem como pessoa.

Online Project Planning System Tool

2009-11-16T11:51:00.000-08:00

Recentemente publiquei em meu blog um post a respeito de uma ferramenta muito interessante para gerenciamento de Projetos Online Chamada - Tom's Planner.
Esta aplicação permite que você crie e compartilhe gráficos de uma maneira muito simples.
Lógico que não analisei a ferramenta com mais acuidade para testar melhor suas features porém gostei do projeto e acho que pode ser muito útil para os leitores.
segue uma breve descrição da ferramenta em inglês :
"Tom’s Planner is a Intuitive Project Management online enables anyone to easily create, share and publish online planning schedules (Gantt Charts) with drag and drop simplicity.To learn more please visit this site ! "
Como trabalho com Tecnologia da Informação e sou especialista em tecnologias opensource, brevemente estarei publicando algumas análises sobre aplicações para gestão de projetos livres.
Esta foi minha primeira contribuição, espero que tenham gostado. Para quem quiser entrar em contato ou mesmo me mandar email em particular por favor acesse meu blog ( http://pauloamaral.blog.br )

Mapeamento do Scrum para o nível G do MPS.BR

2009-10-28T11:26:00.000-07:00

O nível de exigência por parte dos clientes no que diz respeito à qualidade e complexidade dos produtos aumenta a cada dia (MOREIRA, 2009). E para acompanhar a exigência do mercado, as empresas têm buscado cada vez mais a maturidade nos seus processos de software para atingir padronizações de qualidade e produtividade nacionais e internacionais, que são essenciais para a sobrevivência no mercado de TI (Tecnologia da Informação).

Por outro lado a evolução dos processos de desenvolvimento de software impactou na exigência do mercado, cada vez mais querem softwares melhores e mais baratos, prazos mais curtos e orçamentos mais reduzidos, requerendo equipes menores e mais produtivas. As empresas cada vez mais estão investindo em processos que permitam ganhar produtividade e qualidade, pois nosso dia a dia está cada vez mais dependente de softwares que funcionem de forma segura e precisa (BARTIE, 2006).

Neste contexto, esse artigo propõem mapear as práticas do Scrum aos resultados esperados do nível G do MPS.BR (Melhoria de Processo do Software Brasileiro) para que as empresas tenham a possibilidade de definirem processos que produzam software com alto padrão de qualidade e sejam certificados e reconhecidos nacionalmente, tendo ainda, uma produção de software ágil e eficiente.

Para cada resultado esperados dos processos exigidos pelo nível de maturidade G serão diagnosticados como:

- Satisfeita: quando em Scrum possuir práticas explícitas que sirva como evidência na avaliação do MPS.BR e que cubra completamente o resultado esperado em questão.

- Parcialmente satisfeita: quando em Scrum possuir práticas explícitas que sirva como evidência na avaliação do MPS.BR e que cubra pelo menos parte do que o resultado esperado define.

- Não satisfeita: quando em Scrum não houver nenhuma prática explícita que seja evidência na avaliação do MPS.BR.

Processo: Gerencia de Projetos – GPR
- GPR 1. O escopo do trabalho para o projeto é definido.

- Análise: Em Scrum, o Product Backlog e o documento de visão, criados durante a fase de planejamento, provêem a definição do escopo do projeto. Com esse escopo inicial, é possível estimar a quantidade de iterações e o tempo de desenvolvimento necessário para o desenvolvimento do produto.

- Diagnóstico: Satisfeita.

- GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados.

- Análise: As tarefas e produtos de trabalho são estimados em cada Sprint. As estimativas são feitas utilizando métodos que envolve toda a equipe desde do Scrum Master até o desenvolvedor, e cada Sprint a equipe se torna mais apta a estimar corretamente. Portanto, os métodos para estimar as tarefas e produtos são apropriados.

- Diagnóstico: Satisfeita.

- GPR 3. O modelo e as fases do ciclo de vida do projeto são definidas.

- Análise: Em Scrum, o projeto tem um ciclo de vida iterativo/incremental e que pode ser definido em quatro fases: Planejamento, Preparação e escalonamento, Desenvolvimento e Entrega.

- Diagnóstico: Satisfeita.

- GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas.

- Análise: Em Scrum as tarefas e produtos de trabalho são estimados a cada sprint. Estas estimativas são baseados em dados históricos, isto é, na experiência que a equipe teve em outros projetos e no projeto em questão a medida que avança o seu desenvolvimento. Contudo, Scrum não define que as estimativas devem ser documentadas.

- Diagnóstico: Parcialmente satisfeita.

- GPR 5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos.

- Análise: Com as estimativas de esforço do Product Backlog e uma idéia da produtividade da equipe, estabelece-se um primeiro cronograma do projeto através da divisão em Sprints de trinta dias. esse cronograma é automaticamente atualizado à medida que o projeto se desenvolve e as funcionalidades são re-priorizadas. O orçamento do projeto, no entanto, não está contemplado nas atividades do Scrum e nem sempre pode ser calculado diretamente do cronograma. Os marcos são feitos ao final de cada Sprint, o progresso do projeto e o cumprimento dos compromissos é revisado na reunião de Sprint Review.

- Diagnóstico: Parcialmente satisfeita.

- GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados.

- Análise: No Scrum não há identificação e monitoramento explícito e sistemático dos riscos do projeto, com seu respectivo impacto e probabilidade de ocorrência, como sugere o nível G do MPS.BR. No entanto, riscos são possíveis impedimentos, e, portanto, podem ser levantados durante a Daily Meeting, e anotados na Impediments List, gerando um levantamento iterativo dos riscos.

- Diagnóstico: Parcialmente satisfeita.

- GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo.

- Análise: No começo do projeto é realizada a alocação do time e da infra-estrutura necessária para todo o desenvolvimento. O Scrum Master e o Product Owner são responsáveis por garantir os recursos e a continuação do projeto, através das reuniões ao início de cada iteração e da remoção de impedimentos levantados pelo time. O time, que é um grupo multifuncional e auto-gerenciado, deve, na medida do possível, ser criado contendo os conhecimentos e as habilidades (técnicas e de negócio) necessárias para desenvolver o Product Backlog.

- Diagnóstico: Satisfeita.

- GPR 8. As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados.

- Análise: As tarefas, os recursos e o ambiente de trabalho são planejados na elaboração do Product Backlog e no documento de Visão que são previstos no Scrum.

- Diagnóstico: Satisfeita.

- GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança.

- Análise: Em Scrum não há orientações para verificar se existe um plano para gerência de dados listando todos os documentos gerados no projeto, distribuição dos mesmos e mídia para armazenamento, proteção (segurança e sigilo) e recuperação desses dados.

- Diagnóstico: Não satisfeita.

- GPR 10. Planos para a execução do projeto são estabelecidos e reunidos no Plano do Projeto.

- Análise: Em Scrum, o documento de Visão e o Product Backlog representam o plano em alto-nível do projeto, com os requisitos funcionais e não-funcionais e o porquê do desenvolvimento do projeto. O Time, Scrum Master e Product Owner revisam os planos e compromissos no início e no final de cada Sprint, durante a reuniões de planejamento (Sprint Planning) e revisão (Sprint Review).

- Diagnóstico: Satisfeita.

- GPR 11. A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados.

- Análise: Em Scrum, a viabilidade é definida pelo time em cada Sprint, já que nas reuniões de planejamento de cada Sprint (Planning Meeting) o time define quais das funcionalidades é viável para eles finalizar durante o período do Sprint. Os ajustes são feitos nas reuniões de retrospectiva (Retrospective Meeting) no qual se tem maior conhecimento do time da produtividade e da complexidade do projeto.

- Diagnóstico: Satisfeita.

- GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido.

- Análise: O compromisso com o plano é obtido continuamente no início de cada Sprint quando as atividades a serem desenvolvidas são negociadas com o Product Owner e o time.

- Diagnóstico: Satisfeita.

- GPR 13. O progresso do projeto é monitorado com relação ao estabelecido no Plano do Projeto e os resultados são documentados.

- Análise: Em Scrum, o Product Burndown e as reuniões diárias (Daily Meeting) provêem a visibilidade necessária para monitorar o andamento do projeto e conferir desvios no plano. O Sprint Burndown também contribui para isso, mostrando diariamente a velocidade do time e se as funcionalidades que vão ser entregues ao final do período.

- Diagnóstico: Satisfeita.

- GPR 14. O envolvimento das partes interessadas no projeto é gerenciado.

- Análise: Em Scrum o envolvimento dos interessados é garantido pelo Product Owner (que os representa na definição do escopo e das prioridades) e pelo Scrum Master (que deve garantir o cumprimento das regras do Scrum). Evidências indiretas desta participação, como atualizações no Product Backlog, mostram que os stakeholders estão envolvidos no projeto.

- Diagnóstico: Satisfeita.

- GPR 15. Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento.

- Análise: Ao final de cada Sprint, o progresso do projeto e o cumprimento dos compromissos é revisado na reunião de Sprint Review.

- Diagnóstico: Satisfeita.

- GPR 16. Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas

- Análise: Durante as reuniões diárias, o time reporta e analisa os problemas encontrados, registrando-os em um quadro branco, cartões de papel ou na Impediments Backlog. Além disso, é responsabilidade do Scrum Master identificar e resolver impedimentos o mais breve possível.

- Diagnóstico: Satisfeita.

- GPR 17. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão.

- Análise: O Scrum Master é responsável por resolver os impedimentos assim que eles são identificados. No entanto, não há registro ou evidências do planejamento e monitoramento dos impedimentos, impedindo um acompanhamento dessas ações de correção.

- Diagnóstico: Parcialmente satisfeita.

Observamos portanto, que 70,59% dos resultados esperados são satisfeitos nas práticas do Scrum, sendo que 17,65% são parcialmente satisfeitos e apenas 11,76% não são satisfeitos.

3.2. Processo: Gerência de Requisitos – GRE

- GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos.

- Análise: Considerando o envolvimento dos stakeholders, percebe-se que as práticas de Scrum contribuem para garantir e manter uma boa comunicação e colaboração entre o time e os fornecedores de requisitos. Portanto os requisitos são obtidos com a intensa participação dos fornecedores de requisitos.

- Diagnóstico: Satisfeita.

- GRE 2. Os requisitos de software são aprovados utilizando critérios objetivos.

- Análise: Em Scrum são aprovados os requisitos com os fornecedores de requisitos porem não utilizando critérios objetivos.

- Diagnóstico: Não satisfeita.

- GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida.

- Análise: Em Scrum não há nenhuma prática que prevê isto.

- Diagnóstico: Não satisfeita.

- GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos.

- Análise: Em Scrum revisões freqüentes são realizadas a cada iteração (Sprint Review) e diariamente (Daily Meeting), inclusive com ajuda de gráficos (Product Burndown e Sprint Burndown).

- Diagnóstico: Satisfeita.

- GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

- Análise: No Scrum sugere que os requisitos prioritários para fazer parte do Sprint não sejam alterados depois que o Sprint começou, porem se ver a necessidade de mudança o Sprint é interrompido e é feito uma nova reunião de Planning Meeting, a fim de modificar conforme a necessidade. Esta modificação é registra na nova versão do Product Backlog e do Sprint Backlog.

- Diagnóstico: Satisfeita.

Observamos portanto, que 60% dos resultados esperados são satisfeitos nas práticas do Scrum e apenas 40% não são satisfeitos.

Em conclusão tem-se portanto, que o Scrum atende em 68,18% os processos do nível G de MPS.BR. Portanto, nota-se que é possível obter certificação de qualidade do software utilizando-se as boas práticas de uma metodologia ágil, o Scrum, desde de que adapte as poucas práticas que o MPS.BR exige.

“Desnivelamento de Expectativas” – um grande vilão (Parte II)

2009-10-26T10:36:00.000-07:00

No último post eu falei um pouco sobre o perigo de se ter expectativas desencontradas em qualquer tipo de relacionamento. Neste post, eu falarei um pouco sobre como isso pode ser potencialmente terrível(!) num projeto.

O que significa ter expectativas diferentes para um projeto? Basicamente significa esperar produtos ou resultados diferentes durante ou no final de um projeto - e isso é muito comum. Um dos motivos – você pode dizer – é que o cliente não sabe o que quer. De fato isso às vezes acontece, contudo na maioria das vezes, ele sabe o que quer, só não sabe como – é aí que mora o perigo. Então surge a pergunta, como conseguir realizar o que o cliente quer e da forma que ele quer? Um bom Levantamento de Requisitos é o passo inicial(e fundamental) para isso.

O Levantamento de Requisitos consiste numa etapa em que o Gerente de Projetos (ou um Analista de Requisitos) mapeia e documenta o que o cliente espera do resultado do projeto. Esse mapeamento, e naturalmente a documentação disto, é importante, por que esses dados serão a base para todo o planejamento do que será feito.

Muita informação? Então vamos voltar ao básico, e você verá que faz sentido. O PMBOK apresenta uma abordagem que destaca um projeto como tendo três fatores fundamentais e chama isto de “restrição tripla”. A “Restrição Tripla” é composta de Custo, Tempo e Escopo*. A arte do projeto (e o grande desafio do Gerente de Projetos) reside realizar o gerenciamento, e conseqüentemente, o equilíbrio deles.

Isso é vital, pois uma vez que eles são interdependentes, se mudar um dos três, os outros muito provavelmente serão afetados. Menor prazo pode significar mais recursos. Maior escopo pode significar um projeto com mais tempo e por aí vai.

Agora começamos a entender por que, mesmo com um tempo definido, e o custo definido, se não existir um ESCOPO definido tudo pode ir por água a baixo, não é verdade? Uma verdade simples, mas que nem sempre é notada.

Muitos projetos se encaixam no exemplo acima. Até porquê, para o cliente, os fatores tempo e custo, em geral, podem ser mais facilmente definidos. Então a arte de nivelar as expectativas está, também, no escopo bem definido, detalhado e ACORDADO.

Notaram o destaque no “acordado”? – Pois é, isso é fundamental. Dentro do contexto do Gerenciamento de Projetos o documento que guarda essas informações é chamado de “Declaração de Escopo”. A declaração de escopo é um artefato que guarda TUDO que será realizado no projeto, inclusive as premissas, restrições e entregáveis.

O Escopo é algo tão importante que o PMPBOK na versão de 2004 criou um processo, ainda na fase de iniciação(ou antes do planejamento), chamado de “Desenvolver a declaração do escopo preliminar do projeto”. E ele continua, “Este processo aborda e documenta os requisitos do projeto e da entrega, os requisitos do produto, os limites do projeto, os métodos de aceitação e o controle de alto nível do escopo. Em projetos com várias fases, este processo valida ou refina o escopo do projeto para cada fase.”

E na fase de Planejamento existem pelo menos dois processos ligados diretamente com o Escopo do projeto – o “Planejamento de Escopo” e a “Definição do Escopo”. O primeiro define a regra do jogo, ou “documenta como o escopo do projeto será definido, verificado e controlado e como a estrutura analítica do projeto será criada e definida.” E o segundo processo, define e documenta a declaração de escopo em si.

Não sei se ficou tudo muito confuso, mas apesar desses processos serem importantes, para projetos menores, uma declaração de escopo, bem definida, clara e acordada, pode ser suficiente.

Então ter o escopo perfeitamente definido logo no início é uma garantia de que ele não vai mudar, você poderia pensar. Não necessariamente, por dois motivos básicos – não somos perfeitos e as coisas mudam.

Existem fatores que podem mudar durante a execução do projeto, como questões econômicas(variação cambial, saúde econômica do cliente, etc) e disponibilidade de profissionais habilitados, apenas para citar alguns. Em outras palavras mudanças de escopo, não são incomuns, às vezes podem ser até desejáveis, e o importante é como gerenciar isso. Tal gerenciamento é um esforço necessário que deve ser realizado para que os resultados do projeto ainda sejam vantajosos para ambos os lados. Caso contrário, a melhor solução pode ser cancelar o projeto, e novamente, às vezes pode ser a melhor opção.

Uma forma de se ter certeza de que os resultados estão atendendo as expectativas do cliente, é realizar pontos de controle regularmente e também dividir o projeto em entregas menores e pré-definir que a cada entrega deverá ter um aceite formal do cliente. O primeiro ponto faz com que possa ser identificados problemas e desvios indesejáveis o quanto antes e realizar as devidas ações corretivas. O segundo é igualmente importante, uma vez que se existir um entregável não apropriado, ele pode ser “endireitado” o quanto antes, com uma taxa de retrabalho menor. Imagine se não fosse assim, você só descobriria na entrega que o cliente não gostou – seria um desastre não seria? Seria mais ou menos como você descobrir que sua noiva não quer casar com você no altar. Acho que já deu para entender a importância.

Para concluir, mantenha as expectativas niveladas nos seus projetos. Isso é um processo constante e começa com um levantamento competente, passa por um bom planejamento, um acompanhamento adequado e essencialmente, o comprometimento de seu cliente em cada etapa.

Sucesso e Bons Projetos.

Leandro Santoro.

*(Existem também duas vertentes sobre a questão do fator Qualidade – uma acha que ela é a resultante do equilíbrio dos três fatores, e outra, que é um quarto elemento, contudo isso é assunto para outro artigo ).

“Desnivelamento de Expectativas” – um grande vilão.

2009-10-20T10:11:00.000-07:00

Um Namorado compra um presente caro, achando que vai agradar, contudo a namorada queria apenas ganhar um cartão com uma mensagem personalizada.

Um menino queria ganhar um novo jogo de vídeo game, e o pai leva ao cinema para ver um filme que ele não gosta.

Esse são alguns exemplos de “Desnivelamento de Expectativas”. Apesar de parecer banal, não se deixe enganar, expectativas desencontradas, são a razão de diversos problemas em relacionamentos, sejam interpessoais ou profissionais.

Para entender isso melhor, é importante explicar o que o termo significa. “Desnivelamento de Expectativas”, num relacionamento, acontece quando os envolvidos esperam coisas diferentes do outro. Isso pode ser bilateral ou unilateral, mas quando acontece, não é bom, e às vezes pode ser desastroso.

Para visualizar como isso pode ser desastroso, vejamos um exemplo, sob o ponto de vista de um acordo comercial.

Imagine que você contrate um pedreiro para construir uma casa. Você estipula um valor, mas não define muito bem como quer sua casa, só diz que quer uma casa azul com quintal e janelas. Não é preciso se esforçar muito para descobrir que alguém sairá com algum tipo de prejuízo. Se não se especificar o tamanho da casa, o número de quartos, a qualidade do material desejado, entre muitas outras coisas, os produtos finais podem ser BEM diferentes dos idealizados.

Isso acontece por que,se você não especificou direito, a casa que você imaginou certamente não é casa que o pedreiro imaginou. Talvez você tenha pensado no conforto, conveniência, e o aconchego que seu novo lar poderia lhe proporcionar, enquanto o pedreiro, por sua vez, tenha levado em conta variáveis como menor preço, menor tempo, ou menor esforço.

Situações como essa são comuns, especialmente em locais de trabalho. Já passou por situações em que seu chefe lhe pediu algo, e você fez seu melhor, e então, de repente, ele olha o trabalho e diz – “Não era bem isso que eu tinha em mente…”

Isso aconteceu por causa de uma falha no sistema de comunicação. Vamos lembrar como funciona esse tal sistema de comunicação?

Em primeiro lugar, para uma comunicação é necessário um emissor, um meio, e um receptor. Parece bastante simples, não é verdade? Contudo o perigo mora em banalizar isso, ou ter isso como algo automático – e de fato, não é.

O primeiro trabalho do emissor é codificar corretamente seus pensamentos, para que o receptor possa entendê-lo de forma correta. Depois ele envia essa informação por intermédio de um meio comum e, notem, ele se CERTIFICA, que o receptor recebeu a informação de forma correta. (Ainda existe outros elementos como o Ruído, por exemplo).

Que tal levar isso para a vida real? Vamos utilizar o exemplo anterior, o do seu chefe e você,

No exemplo anterior, o chefe era o emissor, a mensagem, foi passada verbalmente, e você era o receptor. Onde aconteceu o erro então? A menos que tenha acontecido um gesto de imperícia(para ser bem polido), aconteceu um erro de comunicação, ou seja o receptor não entendeu corretamente a mensagem. É isso? Quase . Uma vez que o emissor tem a responsabilidade de se certificar que receptor entendeu corretamente, podemos dizer que o Chefe deveria se certificar que você entendeu corretamente.

Como fazer isso? A melhor forma, é pedir que receptor repita a mensagem, e se certificar, por intermédio de perguntas, o que ele entendeu. Pode-se fazer perguntas como: “O que você pretende fazer, então?”, ou mesmo, “Entendeu, alguma dúvida?” ou coisas do tipo.

Naturalmente, isso não exime totalmente o receptor, ou você, de procurar refinar seu entendimento. Sim, o receptor tem uma parcela de responsabilidade também. Mas como fazer isso? Mais uma vez, por intermédio de perguntas como “Qual o objetivo/encaminhamento/contexto desse trabalho para que eu possa realizar o trabalho de forma mais específica?”, “Não consegui visualizar muito bem esse ponto, poderia completar meu entendimento?” ou mesmo “Existe alguma informação adicional que poderia completar meu entendimento, ou me auxiliar para realizar esse trabalho?” ou coisas do tipo.

É importante dizer que bons relacionamentos, são resultado de uma boa comunicação. Note que nem sempre é necessário um nivelamento de valores, mas sim de expectativas. Isso significa que nem sempre você precisa pensar como o próximo, mas entendê-lo. Conseguiu identificar por que é importante ter(e manter) as expectativas em comum nos seus relacionamentos?

No próximo post, explicarei como o “Desnivelamento de Expectativas” pode ser muito prejudicial no Gerenciamento de projetos, e como se livrar (ou atenuar) esse inconveniente.

Até a próxima.

Leandro Santoro.

Artigo originalmente postado em http://walkingaround.wordpress.com/2008/11/02/desnivelamento-de-expectativas-um-grande-vilao/

Rápido pensamento sobre os processos

2009-10-19T17:03:00.000-07:00

O fato é que um projeto pode acontecer de uma maneira muito mais saudável e agradável desde que os processos da empresa sejam seguidos - e desde que, eles façam todo o sentido para que o fluxo aconteça e ocorra da melhor maneira possível.

Distrair-se de um processo em meio à correria diária é muito fácil. Acabar passando por cima dele para resolver uma questão imediata é coisa corriqueira. A facilidade está aí. E os problemas acabam por vir. Soluções paliativas geram problemas duráveis.

É preciso ter confiança, entendimento e, acima de tudo, postura. Uma coisa não vai bem quando outra atropela e cabe ao GP, no dia-a-dia, conseguir aplicar o tal do processo. E fazer com que todas as partes entendam "onde, quando e porquê".

O quanto você, e as pessoas com quem você trabalha, conhece e aplica a metodologia? Será que é preciso mudar?

Dicas sobre gerenciamento de projetos

2009-10-01T12:12:00.000-07:00

Olá amigos redatores e leitores!

Vi esta semana em um site algo bem interessante para nos ajudar a entender e refletir de forma prática sobre o Mundo do Gerenciamento de Projetos.

Aí vão duas dicas legais de como refletir sobre o assunto de forma divertida para quem gosta de filmes de ação: “O Vôo da Fênix (The Flight of the Phoenix)” e "Uma saída de Mestre (The Italian Job)".

Qualquer um destes filmes são uma perfeita aula de Gerenciamento de Projetos.

Os dois tem uma abordagem e visão gerencial bem interessantes dos projetos, visto que, eles expressam claramente quais os principais objetivos, como é feito o planejamento, quais os riscos, conflitos, motivação e desmotivação, união da equipe, ingerências e tudo que pode cercar uma realidade de um Projeto estão contidas nestas duas estórias.

Para quem gosta vale a pena ver ou rever de forma a pensar baseado nesta área de conhecimento.

Sinopse: O Vôo da Fênix (2004)
Frank Towns (Dennis Quaid) é um piloto de aviões de carga que, juntamente com seu co-piloto A.J. (Tyrese), é enviado para a Mongólia. A dupla tem a missão de retirar do local uma equipe de exploração petrolífera, já que o projeto fora interrompido. Pouco após a decolagem do vôo de volta, quando sobrevoam o deserto de Góbi, o avião enfrenta uma forte tempestade de areia, que arranca suas antenas e destrói o motor esquerdo. O avião sofre uma pane geral e Frank é obrigado a realizar uma aterrissagem forçada em pleno deserto. Com o avião avariado e sem chances de conserto, os 11 tripulantes se vêem presos no deserto e, para piorar, com pouca água e comida. Até que um dos sobreviventes, Elliott (Giovanni Ribisi), propõe uma idéia louca: construir um novo avião com os destroços do primeiro. A proposta é rechaçada por todos de imediato mas, com a situação se tornando cada vez mais crítica, eles decidem arriscar e levar o plano adiante.

Sinopse: Uma saída de Mestre (2003)
Charlie Croker (Mark Wahlberg) é um gênio do crime, que está decidido a recuperar um cofre repleto de ouro que fora roubado por seu ex-sócio Steve (Edward Norton), que o traiu. Para tanto ele conta com uma gangue formada pelo gênio da computação Steve (Seth Green), Handsome Rob (Jason Statham), o especialista em explosivos Left Ear (Mos Def), o arrombador de cofres John Bridger (Donald Sutherland) e ainda a bela Stella Bridger (Charlize Theron). O plano da gangue é recuperar o cofre em plena Los Angeles, criando para tanto o maior engarrafamento que a cidade já viu em sua história.

Espero que gostem desta dica!

Até a próxima um abraço [],

Quero ser gerente de projetos, e agora?

2009-09-30T11:24:00.000-07:00

Olá amigos redatores e leitores!

O assunto que escolhi para aboradar hoje é quando um profissional decide encarar uma carreira como Gerente de Projetos e agora?

Para assumir esta área ou determinada função deve-se acercar antes de algumas estratégias.

Vamos ao questionamento então de qual a melhor forma para que eu possa vir a ser um profissional a ingressar na carreira de gerenciamento de projetos?

Veja bem, não existe uma “receita de bolo” para ser um Gerente de Projetos, mas sim baseado em leituras e depoimentos vistos, pode-se orientar a seguir um caminho na qual muitos já obtiveram sucesso desta forma, pois, muitas coisas não dependem somente do profissional e sim do empregador e das oportunidades.

Iniciando as nossas dicas, primeiramente o profissional que deseja engrenar nesta carreira, deve saber exatamente o que é ser um Gerente de Projetos e mais do que isso, como todo profissional em qualquer outra profissão, deve-se gostar muito do que faz.

Assim como entender a real missão que se propõe um Gerente de Projetos, deve-se identificar quais são os benefícios que uma carreira bem estruturada possa trazer.

De uma forma mais simples, vamos observar a seguinte frase de Confúncio: “Em todas as coisas, o sucesso depende de preparação prévia."

Isto não é nenhuma novidade porém, desde aquela época o homem já sabia que para ser bem sucedido é necessário preparar-se para isto, logo, para Gerenciar Projetos não seria diferente.

Falando em preparar-se é exatamente ter a formação, conhecimento, habilidades e competências atrelados a sua bagagem.
Hoje em dia, existem cursos de especialização, MBA’s e até mesmo cursos temporários com rápida duração, que são uma ótima opção para buscar as competências necessárias para um início de carreira e todos, dão uma visão do que é Gerenciar Projetos.
Este é um passo inicial para aqueles que desejam se consolidar na profissão, visto que, estes cursos abordam muito bem as melhores práticas com base na “Bíblia do Gerente de Projetos mundialmente conhecido como PMBOK”, aliados as técnicas e processos utilizados para Gerenciar Projetos dispondo também, de poder conhecer diversas ferramentas de gerenciamento alinhado a exemplos práticos, cases de sucesso e situações bem próximas da realidade.

Outro ponto interessante a se observar, enquanto fazemos um dos cursos para se especializar principalmente falando em MBA’s e Especialização que possuem um tempo mais longo de duração, são os contatos e relacionamentos (networking), troca de experiências, vivência na prática de muitos profissionais no mercado que agregam um alto valor unidos a própria orientação profissional (mentoring e coaching) e às oportunidades profissionais.

Falando um pouco em oportunidades, isto realmente é uma conseqüência da preparação e ainda assim, muitas vezes é necessário ser habilidoso e ter bons relacionamentos para que possa “abrir portas”.

Muitas vezes quem está almejando um oportunidade como Gerente de Projetos, encontra-a mais facilmente fora da empresa em que atua. Não é uma afirmação, porém é resultado de uma pesquisa baseada na entrevista com alguns atuais GP’s que alegaram ter-se encontrado como Gerente de Projetos mais rapidamente fora da companhia em que trabalhavam.

Lembre-se: Esteja em constante observação ao mercado e a tudo o que for relacionado as oportunidades de projetos, assuma pequenos projetos internamente, coordene uma frente específica de um importante projeto dentro de sua organização, leia, pesquise e conheça os projetos existentes na organização, interaja se possível com eles. Caso esteja envolvido diretamente em algum projeto mesmo que não seja o Gerente deste, ajude no que impactar sua área a definir prazos, custos, riscos e qualidade (que é a maior preocupação dos patrocinadores de projetos) são os caminhos para se ganhar visibilidade, tornar-se referencia e consolidar-se como um profissional de gerenciamento de projetos, que automaticamente será lembrado para assumir posições gerencias quando o assunto é Projetos. Tenha bons relacionamentos, saiba trabalhar e sustentar seu marketing pessoal e principalmente estar disposto a assumir os riscos que esta uma nova função possa trazer para que possa conquistar as oportunidades.

Vale enfatizar que a certificação PMP (Project Management Professional) é um diferencial para o Gerente de Projetos que a possui, porém não deve ser o foco inicial para quem esta buscando consolidar um início na carreira em gestão de projetos, visto que, esta certificação é orientada para profissionais com certa vivência em gerenciamento de projetos assim como mostram os requisitos solicitados para aquisição da mesma. Mas a certificação deve estar no plano de carreira que qualquer gerente de projetos que deseja ser diferencial, para adquiri-la no momento certo!

Espero ter contribuído com o assunto e estou à disposição!

Abraço [],

Nota: Baseado em uma leitura de Marcos Pires, PMP.

Muito além de gerenciar - A função do gerente de projetos

2009-09-23T07:09:00.000-07:00

Primeiramente, gostaria de agradecer a oportunidade de escrever neste blog e pegar a ponta de um assunto que tenho lido muito nas comunidades e pegar a ideia de um artigo que li esta semana.

Vamos a leitura, espero que gostem.

A função do gerente de projetos nos dias de hoje não limita-se mais ao simples fato de gerenciar/controlar projetos. Auxiliar no planejamento do projeto, na criação de propostas e ser a ponte entre todas as áreas são uma das "novas" funções do gerente de projetos.
Muitas pessoas ainda veem o gerente de projetos como uma pessoa que ficava o dia inteiro olhando gráficos, criando relatórios, atualizando cronogramas e fazendo toda a parte administrativa do projeto. Em algumas empresas este profissional não passa de um secretário do projeto, deixando assim suas outras habilidades de lado, mas claro este é o caso de uma empresa que não possui nenhuma maturidade.

Hoje o PMO (Project Management Office - Escritório de Projetos) é dividido em quatro principais categorias que distribui a função do gerente de projetos. No nível mais alto temo o gerente como suporte a decisões e apoio direto a diretor de tecnologia. No nível mais baixo ele está como suporte a equipe de suporte da empresa, ou seja, em um departamento e neste caso o report das atividades é feita para o líder da equipe. Não vou comentar neste post a importância de se adotar um modelo, isso deixo para outra hora.
Voltando a função do gerente de projetos na organização. Hoje muitas empresas tem dado muito valor a este profissional que tem se destacado cada vez mais, não somente pelo fato de ele saber de ponta a ponta o projeto, mas sim por ele ser o grande facilitador de informações. Há uns 10 anos atrás essa situação era bem diferente, pois o gerente era visto como somente o "cara" que criava relatório e nada mais. Reuniões e planejamento nem podia fazer parte do vocabulário e nem podia passar ideias na mente do apenas criador de relatórios.

Ainda não entendeu a função real do gerente? Vamos a uma história que sempre conto a colegas de profissão e como explico para as pessoas o que faço no meu dia a dia.

A empresa x tem um gerente com a função de somente reportar aos envolvidos do projeto como anda o projeto da construção do novo produto, neste caso vamos presumir que seja um carro.

Nota.: os interessados são: gerente de produtos, presidente da empresa, diretores de área de tecnologia, público da classe A.

O gerente todas as manhãs passa no pátio para ver como estão os funcionários. Ele pede um breve report verbal das tarefas desenvolvidas e vai anotando. Ao final da conversa ele coloca o que foi dito em um cronograma, desenha o gráfico de Gantt, calcula o quanto o projeto consumiu de horas e valores, faz o PERT e cria um relatório para apresentar a todos os envolvidos.

Todos olham e analisam as informações, alguns não entendem nada outros entendem algumas coisas e cabe o gerente passar as informações necessárias à todos. A posição de cada interessado no projeto são distintas. O presidente da empresa quer o lucro do projeto, o gerente de produtos quer logo lançá-lo para ser a pioneira, os diretores de tecnologia se interessam pelo lançamento pois isso irá mostrar a tecnologia de ponta que foi utilizada. E o gerente de projetos o que quer? Ele quer garantir que o custo, tempo, qualidade e prazo estejam na base do que foi planejado ou acordado. É nesta parte que entra toda a negociação e entendimento da área que até então era vista somente como de relatórios. É a função do gerente explicar que se o produto for lançado com uma má qualidade o seu lançamento será um fracasso e consequentemente a adesão será muito abaixo do esperado. É função mostrar ao presidente o mercado e falar que o retorno nem sempre é imediato, pois estamos falando de projetos e projetos tem uma curva se aceite e de maturidade. É função mostrar a todos os envolvidos os riscos existentes na adoção de uma nova tecnologia.

Perceberam como a área de administrar projetos se tornou a ponte de informações e dados?

Vamos pensar nessa área que vem crescendo a cada ano como uma área de apoio e não somente de reports. E você já tentou entender um pouco mais dessa área? Se não é gerente converse com o gerente da sua empresa e entenda um pouco mais da arte de gerenciar e fazer.

Abraços a todos,

Patrícia

Entre Porcos e Galinhas, qual sua escolha?

2009-09-22T19:15:00.000-07:00

Saudações Leitores!

Um dia desses ouvi num podcast do Ricardo Vargas a parábola dos Porcos e Galinhas, onde estes se uniram para formar uma sociedade. A Galinha, envolvida no projeto, entrou com os ovos e o Porco se comprometeu em entrar com o Bacon.

Perceberam a diferença?

Enquanto a Galinha apenas se envolve com o projeto o Porco sofre, literalmente na pele, as consequências desta participação. Obviamente trata-se de uma história que ilustra um pouco do nosso cotidiano ao lidar com projetos. Qual a nossa forma de participação em projetos, nos envolvemos ou nos comprometemos?

Acredito que ambos os papéis existam, porém vejo com bons olhos quem se compromete de fato com o projeto. Mesmo que sua participação no projeto seja a certa distância você pode se dedicar ao projeto de forma que sua atuação seja próativa e contribua para o sucesso do mesmo. Ter uma ação próativa num projeto é o que conhecemos por "fazer acontecer" ou "vestir a camisa". O profissional que atua desta forma, inevitavelmente terá sucesso em sua carreira, mais cedo ou mais tarde.

O comprometimento envolve dedicação, superação, muito suor e muitas vezes, muitas lágrimas.
Por mais duro que nosso trabalho muitas vezes pareça, ser "Porco" nos motiva a continuar e fazer um bom trabalho. A mim pelo menos é motivo de inspiração para buscar novas formas de se fazer coisas antigas, inspiração para fazer melhor.

Fiz minha escolha...
E você, é Porco ou Galinha?!

Abraços!

Migrações de Sistemas

2009-09-22T18:47:00.000-07:00

Amigos leitores, vou falar um assunto que sempre atormenta muitos gerente de projetos durante sua vida em tecnologia da informação: migração de sistemas.
Eu atuei em alguns processos de migração como mudança de servidor aonde o código é mantido, alterado, compilado e gerado, como foi o caso do CSP, em alta plataforma (mainframe) para Visual Generator (visualgen-baixa plataforma). Outra forte migração foi a alteração de um sistema da base de IMS (base de dados da IBM mais antiga) para DB2 (banco de dados relacional mais atual) ambos em mainframe. O terceiro foi de COBOL Microfocus (cliente-servidor)para COBOL/DB2 no mainframe, aonde o gerente que atuou no projeto na época (eu era coordenador neste período) aceitou o argumento do cliente que seria somente um "copy/paste", isto é, simplesmente copiar e colar sem ter de alterar nada. Doce ilusão!! ... ou melhor AMARGA ILUSÃO!!!!

Vou descrever abaixo algumas sugestões e dicas utilizando estas situações citadas e reais para evitarmos ou pelo menos mitigarmos as situações citadas.

Definição do escopo

Um dos pontos mais importantes, senão o mais importante, é definir o escopo da alteração. Se faz necessário definir o que será feito, pois nunca é somente um "copy/paste" existem sempre módulos obsoletos, novas necessidades e acertos na migração pertinentes a nova linguagem, novo banco de dados ou interfaces com o usuário.
Deve ser levantado, escrito e aprovado pelo usuário este escopo e é importante deixar claro o que vai ficar de fora do escopo da migração. Desta forma o gerente de projeto fica calçado e com provas do que está aprovado para ser feito evitando o "scope creep", que pelo PMI, significa descontrole na definição do escopo causando atraso no projeto, estouro nos custos do mesmo e insatisfação do cliente. Outra prática importante citada no PMBOK é evitar o "gold plating", isto é, fazer aquele algo mais para agradar o cliente. Evite fazer o que não está no escopo pois este "a mais" custo tempo e dinheiro e não foi pedido.
Outro ponto importante não é considerar somente o escopo do projeto em termos de lógica de programação ou requerimentos solicitados pelo cliente mas também definição de requerimentos físicos como banco de dados, servidores, volume de dados, taxa de crescimento de dados, incompatibilidade de banco de dados ou sistemas operacionais e por ai vai.
Obviamente existem várias outras questões a serem abordadas. E tudo precisa ser feito aqui nesta fase de definição de escopo, que é onde o custo ainda é mínimo e o impacto, se acontecer algo errado, será menor.

Plano de Riscos

Durante a fase de definição de escopo e levantamento dos requerimentos acima é importante iniciar em paralelo o levantamento dos riscos do projeto. Devem ser levantados os riscos de cada requerimento, das alterações e suas possíveis consequências. Alguns riscos que podem surgir:

falta de um especialista nas ferramentas existentes;
usuário não tem a definição clara de suas necessidades;
falta de um usuário dedicado ao projeto em suas fases críticas (por exemplo, levantamento e testes);
falta de um estudo de viabilidade do projeto;
objetivos não estão claros;
time de projeto desconhece o sistema ou ferramentas;

Importante entender o que é risco: ele representa o impacto de um problema caso ele vai a acontecer em um projeto versus a probabilidade do mesmo acontecer.
Os riscos devem ser definidos, qualificados, quantificados e definidos os planos para mitiga-los (antes para evitar que ocorra) e para contingencia-los (caso ocorra, o que deve ser feito).
Toda dependência externa do projeto deve gerar um risco, por exemplo a dependência de um fornecedor externo ao projeto.
Falarei sobre riscos em detalhes em outra oportunidade.

Planejamento da Migração

Faça todo o planejamento necessário para a migração, GASTE TEMPO PLANEJANDO. Evite sair executando. Documente os acordos, busque aprovação dos requerimentos, crie um cronograma, planilha de custos, plano de qualidade, plano de configuração, plano de mudanças, plano de comunicação e plano de recursos humanos. Crie um database estruturado aonde vai manter estes dados, de preferência uma ferramenta já consagrada e execute backup diários dos mesmos.
Em outros posts entrarei em maiores detalhes mas abaixo falo de alguns essenciais e mais específicos para a migração.

Plano de configuração

Deve ser bem controlada a configuração dos módulos que serão alterados, para isso um plano específico para migração deve ser criado com bastante critério, evitando passar para produção módulos incorretos. Utilizar algo como um software próprio, como o Rational Clearcase ou em caso contrário uma planilha. Neste caso deve ter um responsável como o coordenador do projeto (Team Leader) ou um analista de configuração.
Segue abaixo um modelo que já utilizei e serviu perfeitamente:

criar uma versão inicial como 1.0.0, que é a copia do atual em produção
a partir deste criar versões em ambiente de teste da migração como 1.0.1, 1.0.2...
caso exista algum alteração em produção a mesma deve refletir no ambiente de teste da migração e sua versão passaria a ser 1.2.0
a partir deste criar versões em ambiente de teste da migração como 1.2.1, 1.2.2...
quando for passar para produção a verrsão de migração para produção teremos a versão 2.0.0

Cada módulo deve ser controlado e versionado. Devem ser mantidas as versões com final zero durante todo o projeto e se possivel algumas versões intermediárias.
Este é apenas um exemplo. Cada gerente pode criar seu modelo mas ele DEVE EXISTIR E SER BEM CONTROLADO pro um ÚNICO RESPONSÁVEL.

Plano de mudanças

Deve existir um plano claro de mudanças bem estabelecido e aceito pelos integrantes do time do projeto, usuário e principalmente pelo "sponsor", isto é, patrocinador do projeto.
Qualquer mudança no projeto deve ser analisada, avaliada, planejada e aprovada pelo "sponsor" ou pelo ele deve estar ciente da mesma. Todos os planos precisam ser refeitos e os impactos mensurados. Não deve ser aceito aquele famoso: "só vai alterar uma linha!!!"

Faça Backup

FAÇA BACKUP ! FAÇA BACKUP ! FAÇA BACKUP ! Sempre tenha um backup em mãos. Isto pode salvar muitas vidas. É sério !

Antes de começar o procedimento, faça cópia de tudo. TUDO MESMO ! Banco de dados, pasta dos aplicativos, executáveis, TUDO ! De preferência em duas cópias, porque backup é mestre pra não funcionar quando você mais precisa dele.

E não adianta comprar um CDzinho vagabundo na esquina. Ouça: NÃO ECONOMIZE neste ponto ! Os dados que você pode perder são de valores incalculáveis.

E não vale também fazer backup e guardar dentro da própria máquina. Os motivos eu não preciso nem explicar.

Crie uma base de testes

Não faça a migração em plena base oficial (ambiente de produção). Então, simule tudo em um ambiente o mais fiel possível do real. Se for um ERP, Crie um banco de dados de teste, use os executáveis que estão em produção. Assim você terá como corrigir alguns erros que irão ocorrer na sua migração oficial, antes mesmo que ela ocorra, diminuindo assim o tempo em que a empresa ficará sem utilizar o sistema.

Devem ser feitos os casos de teste e plano de testes bem claros. Os Casos de testes devem ser feitos pelo analista e pelo cliente em parceria, pois o cliente tem ciência das funcionalidades e o analista os detalhes do código e da base de dados. O Plano de Teste deve detalhar quais testes serão necessários, quem são os responsáveis envolvidos e suas datas.

Devem ser feitos 4 tipos de testes:

testes unitários, aonde o programador após a terminar o código faz testes básicos porém consistentes, evitando erros definidos nos requerimentos, de ambiente, de banco de dados e por ai vai;
testes de sistemas, aonde é feito os testes dos módulos completos;
testes integrados são os famosos "end-to-end", envolvendo todos os módulos do projeto;
testes de usuário, aonde somente neste momento o usuário é envolvido para testar as funcionalidades a serem implantadas e também devem ser "end-to-end"

Deve ser gerado um log de defeitos encontrados e corrigidos e caso exiga alguma alteração no escopo do projeto, a mesma deve ser submetida a Gestão de Mudanças.

Aceite pelo usuário

O aceite pelo usuário deve ser formal. Após obter o aceite busque o aceite do "sponsor" e certifique para eles que os mesmos são os responsáveis pelo sistema. Somente com este aceite você pode passar para produção.

Passagem para produção

A passagem para produção deve ser feita com muita cautela e se possível em várias ondas, por exemplo, primeiro a criação do banco de dados e carga do dados, segundo rotinas de backup e outras menos essenciais, terceiro módulos on-line. Deve ser separado para o projeto um período de tempo para a estabilização do projeto em produção. Durante este período sempre existe algum stress pois ai estamos trabalhando no mundo real e o cliente precisa naquele momento que o sistema agora em produção esteja funcionando corretamente.
Após estar tudo certo busque o aceite final do projeto com o sponsor e repasse o projeto para o time de manutenção oficialmente, isto é, de forma formal.
Projeto terminado, é a hora de gerar as lições aprendidas e as métricas, ambos coletados em tempo de execução do mesmo. É tempo também das atividades de fechamento de contratos e liberação dos recursos.

Boa sorte e bons projetos!!!

Gerenciamento da Comunicação no Projeto

2009-09-22T10:55:00.000-07:00

Olá amigos redatores e leitores!

Primeiramente queria agradecer aos comentários e a todos que no ajudam direta e/ou indiretamente dando-nos sugestões de temas a serem abordados o que facilita bastante nosso trabalho de redação e na elaboração dos assuntos atendendo as necessidades de cada um.

Li em um comentário postado uma solicitação sobre o assunto “Gerenciamento de Conflito” e achei bem interessante falar sobre “Gerenciamento da Comunicação no Projeto” .

Vamos lá... Boa leitura e espero acrescentar! =0)

Quem não lembra da frase do Chacrinha que dizia: “Quem não se comunica se trumbica”?
Achei muito interessante em um local em que li sobre isto e realmente nos faz refletir que é a realidade natural para nosso dia-a-dia e nossa vivência cotidiana principalmente em cima do tema em que nos propomos abordar neste site: Gerenciamento de Projetos.

Como assim?

Segundo o Project Management Institute (PMI), 90% do trabalho de um Gerente de Projetos está ligado com as atividades através da comunicação pois, ela é a base e essência para o sucesso do Projeto.
A comunicação é fundamental para integrar todas as partes envolvidas os chamados stakeholders e atender as expectativas de cada uma das partes no gerenciamento de um Projeto.

Mediante isto, vamos tratar de um assunto bem relevante no decorrer deste artigo: gerenciamento de projetos dando ênfase na comunicação.

GERENCIAMENTO DA COMUNICAÇÃO NO PROJETO

Falando um pouco mais tecnicamente, esta área de conhecimento o chamado “Gerenciamento das comunicações” emprega os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação final de todas as informações sobre o projeto de forma oportuna e adequada.

Este processo fornece as ligações muitas vezes conturbadas e críticas entre pessoas afim de atender a uma expectativa real em busca do objetivo comum do projeto.

O gerente de projetos deverá ser a pessoa mais comunicativa podendo utilizar-se de um tempo excessivo para isto, afim de alinhar a comunicação através das informações, necessidades e expectativas do seu cliente e patocinador, filtrando e repassando na linguagem comum aos analistas e desenvolvedores, ou seja, ligação direta com todas as partes interessadas.

Todos os envolvidos no projeto devem entender a real importância da comunicação e como ela afeta diretamente o projeto como um todo.
Para isso, vamos citar alguns processos que podem ajudar no gerenciamento das comunicações do projeto, tais como:

:: Planejamento das comunicações: servirá para determinar as necessidades de informações e comunicações das partes interessadas no projeto.
:: Distribuição das informações: atribuir, controlar e disponibilizar as informações necessárias as partes interessadas no projeto no momento adequado.
:: Relatório de desempenho: coletar e distribuir as informações em todo o ciclo de vida do projeto. Isto inclui o relatório de andamento e acompanhamento do projeto, medição do progresso e previsão através de baselines enviados periodicamente.
:: Gerenciar as partes interessadas: principal forma de gerenciamento das comunicações satisfazendo os requisitos das partes interessadas, gerenciando possíveis conflitos no projeto. Lembre-se que o GP deve ser o facilitador e principal comunicador durante o projeto como um todo para obtenção do sucesso do mesmo.

Os exemplo de processos citados acima, estão integrados junto a outras áreas de conhecimento. Cada um deles poderá ter o envolvimento e esforço de uma ou mais pessoas ou grupos baseado nas necessidades do projeto. Cada processo ocorre pelo menos uma vez em todos os projetos unidos a uma ou mais fases caso o mesmo se divida em fases.

Os possíveis eventos baseados na comunicação sendo eles positivos ou negativos são fatores determinantes para o sucesso do projeto.

GERENCIANDO CONFLITOS

A comunicação durante o projeto nem sempre é positiva. Precisamos estar preparados para suportar os conclitos e gerenciá-los quando ocorrer, pois isto é uma prática real e cotidiana que ocorre naturalmente e em inúmeras vezes durante todo o processo de implantação de um projeto e o principal fator resultande de conflitos é a falta de comunicação.

Falando um pouco sobre o gerenciamento de conflitos, para que este seja bem-sucedido deverá ocorrer uma relação de confiança e estabilidade entre os envolvidos para resultar maior produtividade e relações duradouras de trabalho.
Fontes de conflito podem ser iniciadas por qualquer um dos stakeholders e em qualquer momento no decorrer do projeto.
Podemos exemplificar como sendo uma forma de conflito durante um projeto quando ocorre em um dado momento por exemplo, a escassez de recursos do fornecedor (analistas, desenvolvedores) ou em que o próprio Gerente de Projetos esteja envolvido com inúmeros outros projetos e não consiga dar atenção necessária e igual a todos os clientes e fornecedores.
Regras básicas da equipe, normas de grupo e práticas sólidas de gerenciamento de projetos, como planejamento das comunicações e definição de funções, reduzem a quantidade de conflitos. Quando gerenciadas adequadamente, as diferenças de opinião são saudáveis e podem aumentar a criatividade e melhorar a tomada de decisões. Quando as diferenças se tornam um fator negativo, os membros da equipe do projeto são inicialmente responsáveis pela resolução de seus próprios conflitos e o GP deve estar alinhado a todos afim de tentar reduzir por fim a zero estes conflitos que venham a ocorrer. Se o conflito aumentar, o GP deverá entrar em ação e buscar uma resolução satisfatória sem deixar cair no descrédito o projeto. O conflito deverá ser tratado sempre no início e geralmente em particular, usando uma abordagem direta e colaborativa. Se o conflito prejudicial continuar, será necessário usar procedimentos cada vez mais formais, inclusive a possível utilização de ações disciplinares.

Espero ter contribuído com o assunto e estou à disposição!

Abraço [],

Nota: Parte do texto foi extraído e adaptado baseado no PMBOK-2004.

A arte do Relacionamento

2009-09-18T18:44:00.000-07:00

Saudações leitores!

Inicialmente gostaria de agradecer a equipe do gerenciamentodeprojeto.com pela iniciativa de criar mais um canal de comunicação entre os interessados em Gerenciamento de Projetos e pela oportunidade de poder compartilhar informações com outras pessoas.

Relacionamento, segundo o dicionário Aurélio, é "s.m Ato ou efeito de relacionar. / Amizade, intimidade: travar relacionamento com alguém". Talvez alguns de vocês estejam se perguntando o que esta simples palavra tem a ver com o tema Gerenciamento de Projetos. A resposta é: TUDO!

O domínio da arte do relacionamento é essencial para a sobrevivência do gerente de projetos pois todo o gerenciamento de um projeto gira em torno de pessoas e o gerente de projeto deve saber se relacionar da melhor maneira possível com todos os envolvidos no projeto, sejam estes recursos, sponsors, stakeholders ou qualquer outro que interaja com o projeto.

O gerente de projetos tem necessidade de interagir com outras pessoas e para isto acredito que seu feeling deve ser muito apurado para saber lidar com as características específicas de cada um. Saber transmitir uma mensagem para pessoas com conhecimentos diferentes ou mesmo de níveis hierárquicos diferentes é responsabilidade também do gerente de projeto e esta é uma prática que deve ser exercida diariamente. A arte do relacionamento é algo que dificilmente se aprende somente lendo um livro ou artigo. O aprendizado vêm com a experiência e prática!

Minha experiência me diz que se paga um preço muito caro ao não possuir um bom relacionamento com os membros da equipe na qual você atua, portanto, deixo uma dica aos leitores do gerenciamentodeprojeto.com: se relacionem com as pessoas à sua volta! Vale a pena!

Abraços!

Disseminação da disciplina de Gerencia de Projetos

2009-09-18T10:06:00.000-07:00

Neste primeiro post gostaria de começar agradecendo a parabenizando o portal gerenciamentodeprojeto.com pela iniciativa de promover o debate sobre gerenciamento de projetos. Vou procurar em minhas postagens buscar o debate e apresentando propostas com o foco na educação e da disciplina de gestão e como o PMBOK chama: boas práticas de Gerenciamento de Projetos. Precisamos incentivar e disseminar nosso conhecimento sobre o tema e se pretendemos ter sucesso em nossos projetos, precisamos que as pessoas saibam do que estamos falando e o porquê deste controle.

Ao conversar com muitos gerentes que tendem a serem os detentores das técnicas e não pretendem capacitar suas equipes com medo de perder seu posto, sempre tento convencer que para ocupar o cargo de gerente não deve ser levado em consideração apenas conhecimento das técnicas mas as características pessoais de relacionamento, o que na verdade para muitas linhas de estudos é mais importante do que a técnica, mas não acredito que haja técnica para convencer que um Bom Dia seja espontâneo. O relacionamento inter e extra equipe são fatores preponderantes para um gerente bem sucedido, por isso, acabo convencendo alguns dos colegas mais centralizadores.

Espero que este seja o perfil das próximas postagens e que os comentários gerem discussões para que possamos crescer pois a discórdia é propulsora das descobertas.

Um grande abraço a todos.

Ferramentas "livres" para Gerenciamento de Projetos

2009-09-15T10:07:00.000-07:00

Segundo a Revista Mundo Project Management antes de escolher qual a melhor ferramenta para gerir um projeto, primeiramente, devemos conhecer seus recursos tecnológicos, limitaçãoes, custo, se há licenciamento, benefícios que a mesma oferece e por fim analisar as reais necessidades da implementação destas ferramentas.
Não podemos esquecer que estas ferramentas mudam de acordo com as tendências e novas tecnologias do mercado.
Pesquisando dentre as ferramentas livres (gratuitas) para a gestão de projetos pode-se observar que quase todas trabalham no mesmo estilo do Microsoft Project, isto é, feitas para o desktop. Entretanto, existem algumas baseadas na web e centralizam a informação nos servidores web e banco de dados da empresa.
Vale salientar que muitas destas ferramentas podem substituir tranquilamente o Project porém, na sua grande maioria possui recursos bem inferiores e grandes limitações, atendendo desta forma um nicho de projetos menores.

Uma dica valiosa: Não duplique informações! Se fores utilizar uma ferramenta Web elimine a ferramenta desktop.

É necessário analisar e pensar a forma que será utilizada para integrar a ferramenta de Gestão de Projeto com a ferramenta para Gestão de Incidentes. Algumas ferramentas de Gerenciamento de projetos, possuem formas de integração com ferramentas de gestão de incidências e algumas de gestão de incidentes são possíveis gerar até gráficos de Gantt, por exemplo.
Dependendo da necessidade de cada empresa e do próprio Gerente de Projetos por meio das funcionalidades disponíveis, é possível até substituir a ferramenta de gestão de projetos apenas pela ferramenta de gestão de incidentes, tudo dependerá da real necessidade.

Veja alguns nomes de algumas ferramentas para Gerenciamento de Projetos livre e/ou gratuitas:

:: GanttProject
:: Achievo
:: Open Workbench
:: Faces
:: TaskJuggler
:: OpenProj
:: DotProject
:: Mingle
:: ProjectKoach
:: Buildix
:: ScrumWorks
:: VersionOne
:: Rally

Olhando mais a fundo cada uma destas ferramentas, algumas delas possuem funcionalidades para o ciclo de vida completo de um projeto de desenvolvimento de software e, o melhor, integrando com facilidade de uso esses aspectos. Aliado a gestão de projetos há também funcionalidades como:

:: Gestão de requisitos
:: Gestão de testes
:: Gestão de incidências
:: Integração com controle de versões

Nota: Dentre as funcionalidades acima, alguns exemplos dessas categorias mai completas seriam as ferramentas: Mingle, Buildix, VersionOne e Rally.

Classificando as ferramentas de gestão de projetos instaladas via desktop e web podemos fazer a seguinte separação:

DESKTOP: GanttProject, GanttProject, Open Workbench, Faces, TaskJuggler, OpenProj

WEB: Achievo, DotProject

Atualmente o sucesso do projeto de desenvolvimento de software, está aliado está diretamente aliado a gestão de incidntes pois, se você controlar corretamente tiver os fluxos bem definidos, a base de dados da gestão de incidências se tornará a chave do sucesso.
Grandes empresas de software mundialmente conhecidas usufruem da gestão de incidentes para controlar, monitorar e organizar seus projeto de software na qual é um diferencial para que se possa disciplinar, organizar e fazer a governança de sistemas de Tecnologia da Informação.

Deixe seu comentário sobre o assunto e caso conheças mais sobre alguma destas ferramentas, comente!