Gestão de um projeto de Intranet em SharePoint

1. JoaoB
Start
Project
Joao Manager
Beltrao SharePoint
IT Pro
Innovagency @joaobeltrao
www.joaobeltrao.com
jb@joaobeltrao.com

2. Intranets em SharePoint
Anatomia de um Projeto
SharePoint User Group

3. Gestão de Projeto - O que é
Project Management is the application of knowledge, skills, tools,
and techniques to project activities to meet the
project requirements.
A project is a temporary endeavor undertaken to create a unique
product, service, or result. The temporary nature of projects
indicates a definite beginning and end. The end is reached when
the project’s objectives have been achieved or when the project is
terminated because its objectives will not or cannot be met, or
when the need for the project no longer exists.

4. Gestão de Projeto - O que é

5. Gestão de Projeto - O que é

6. Gestão de Projeto – O início da viagem
Sou um “Consultor SharePoint”, trabalho numa
empresa de IT que presta serviços a outras
empresas, e o cliente acaba de adjudicar a
proposta para a criação de uma Intranet em
SharePoint.
O que fazer?
Instalar de imediato o SharePoint e começar a
criar sites e listas?
PLANEAR!!

7. Gestão de Projeto - Metodologias
Agile / Scrum vs Waterfall
A proposta que o cliente adjudicou é uma
fechada” definido.
proposta “fechada” de âmbito definido.
Para usar Scrum teríamos que vender “user story
points” ou horas/homem.
horas/homem.

8. A equipa
Customer Project Business Designer
Manager Manager Analyst
SharePoint SharePoint SharePoint SharePoint
IT Pro Senior HTML Code
No-
Admin + No-code
solutions Developer Developer Developer
(Architect)
Tester Usability Copy Editor Information
Specialist / Metadata
Architect

9. A equipa
Vamos usar todas estas pessoas em todos os
projetos? Não.
projetos? Não.
Adequar a equipa ao projeto.
projeto.
Adequar a equipa à fase do projeto.
projeto.
Uma só pessoa pode desempenhar mais que uma
função

10. O projeto
Vamos dar início à nossa viagem. O projeto está
dividido em 4 fases
Initiating Planning Monitoring &
Controling não é uma
fase do projeto mas
"process
sim um "process
group"
group" e os seus
Executing Closing processos ocorrem
em todas as fases

11. O projeto
Vamos fazer uma viagem pela lista de atividades.
Uma gantt-chart mostra normalmente um WBS
gantt-
(Work Breakdown Structure) e pode, ou não, chegar
Structure)
ao detalhe da atividade.
Atenção à diferença entre Work Package e Atividade:
Work Package é o deliverable ou output, que por sua
requer uma ou mais atividades para o produzir.

12. Initiating
Confirmar adjudicação da proposta
Preparar site de projeto e timesheets
Receber documentação de proposta adjudicada
(âmbito, calendário, maquetes, orçamento)

13. Initiating
DOC: Project Charter
O Project Charter é um documento que formaliza a existência do
projeto e inclui informação de alto nível sobre o seu âmbito,
stakeholders.
calendário, recursos, objetivos e stakeholders.
Reunião Gestão de Cliente /Gestão Projeto

14. Planning
Formar Equipa para fase "Planning"
É necessário contar com o Customer Manager, o Business Analyst, o
Analyst,
Designer, o SharePoint IT Pro e o SharePoint Senior Developer.
Developer.
Kick-
Kick-off Cliente
• Apresentar os membros da equipa que vão falar com o cliente
(Customer Manager, Project Manager e quando se aplica o
Business Analyst, o SharePoint IT Pro e o SharePoint Senior
Analyst,
Developer).
Developer).
• Apresentar os documentos da proposta adjudicada para assegurar
que todos têm o mesmo entendimento (Caderno de Encargos,
Maquetes iniciais, Calendário Proposto, Metodologia de Projeto).
Projeto).
• Definir Contactos.

15. Planning
DOC: Stakeholder Register
sharepoint)
Um documento (ou lista de sharepoint) que regista os nomes e
stakeholders,
contactos de todos os stakeholders, bem como a sua relação com o
projeto.
DOC: Communications Plan
Quem recebe os status e quando. Reuniões de acompanhamento…
Kick-
Kick-off interno de Planning
Depois de termos "acertado agulhas" com o cliente e de termos um
entendimento mútuo sobre o que vai ser feito podemos dar início ao
planeamento.
Reunimos a nossa equipa, apresentamos o projeto, esclarecemos
dúvidas….

16. Planning
DOC: Planeamento Preliminar (Âmbito, Custo,
Recursos, Calendário, Riscos…)
Este documento marca o momento crítico da definição de Âmbito: se
as principais dúvidas sobre âmbito não estiverem esclarecidas e
devidamente definidas neste documento podemos ter sérios
problemas mais à frente.
Custos, Recursos e Calendário estão normalmente espelhados num
ficheiro de Microsoft Project.
A lista de riscos não deve ser descurada, e não é nenhum "bicho
papão" - basta um parágrafo.

18. Planning
Reunião Cliente - Demonstração de SharePoint -
out-of-the-
Cenário Intranet out-of-the-box
Muito útil para balizar expectativas do cliente e para tornar mais
produtivo o levantamento de requisitos. Para além dos ambientes
internos podemos usar: http://mssalesdemos.com/ e
http://www.cloudshare.com/

19. Planning
Reunião Cliente - Maquete/Design
“Gostámos muito das maquetes da proposta. E agora queremos algo
diferente.
completamente diferente.”
Abordar as maquetes apresentadas na proposta adjudicada (ou
apresentadas logo após a adjudicação da proposta) para discutir
eventuais alterações. De preferência depois de uma demonstração de
sharepoint out-of-the-box para cliente perceber algumas nuances
out-of-the-
Ribbon.
como os menus e o Ribbon.

20. Planning
Reunião Cliente - DSI - Levantamento de
requisitos técnicos
Analisar integração com a AD e outros sistemas (Proxy, Identity
Manager, SAP Outsystems…) e definir plano de trabalhos no caso da
, Outsystems…)
instalação de SharePoint estar incluída. Discutir ambientes (DEV,
Qualidade, Produção) e metodologias (deploy por features, site
(deploy features,
collection backups/restores, content deployment…).
backups/restores
restores, deployment…).

21. Planning
Reunião Cliente Sponsor - Levantamento de
requisitos
Esta é a reunião que marca o início do levantamento de requisitos,
onde se definem os requisitos "macro" bem como o calendário e as
ações de levantamento de requisitos.

22. Planning
Reuniões Cliente - Levantamento de requisitos de
negócio
Conjunto de reuniões e atividades de levantamento de requisitos.
Crítico para o sucesso do projeto.
Como fazer um levantamento de requisitos eficaz?
• Reunir com o responsável/representante de cada área da empresa.
• Perceber as principais dificuldades na partilha de informação e na
produção colaborativa de documentos.
• Usar questionários quando é necessário obter feedback de um
número muito grande de pessoas.

23. Planning
Reuniões Cliente - Levantamento de requisitos de
negócio
• Analisar o nível de maturidade na produção colaborativa de
informação e documentos:
• Envia documentos por mail
• Usa file-shares
file-
• Usa partilha de documentos numa intranet atual
• Já usa SharePoint

24. Planning
Reuniões Cliente - Levantamento de requisitos de
negócio
• Recorrer a Serious Games / Innovation Games
Em projetos de grande dimensão faz sentido dada a quantidade
de pessoas envolvidas e, muitas vezes, o desalinhamento entre os
interesses de todos. Apesar de ser um conjunto de técnicas
associadas a Agile / Scrum encaixa perfeitamente numa
metodologia Waterfall.
Waterfall.
http://www.slideshare.net/21apps/innovation-games-knowing-
http://www.slideshare.net/21apps/innovation-games-knowing-
://www.slideshare.net/21apps/innovation
whats-important
whats-
• Juntar todos os stakeholders numa reunião final para discutir os
requisitos
Esta sessão poderá ser uma das mais produtivas já que permite
confrontar interesses que por vezes colidem, e assegurar um
entendimento global sobre os requisitos.

25. Planning
DOC: Requirements Traceability Matrix
Quando há muitos intervenientes é importante manter um registo de
onde surgem os requisitos.
DOC: Arquitetura de Informação Proposta
DOC: Âmbito proposto
Masterpages, page layouts, webparts, workflows, desenvolvimentos,
asterpages, webparts, workflows,
instalações, formação, documentação…
DOC: Arquitetura Hardware/Software
Template:
Template: SharePoint 2010 - Planning Worksheets
http://tk5bpsweb01.partners.extranet.microsoft.com/en/sdps/Pages/
http://tk5bpsweb01.partners.extranet.microsoft.com/en/sdps/Pages/
conducttheengagement.aspx

26. Planning
DOC: Governance Plan + Staffing Management
Plan
Estes dois documentos estão interligados, e podem ser um só
documento.
Governance Plan indica quem é responsável por fazer o quê:
• Inserção de Conteúdos
• Aprovação de Conteúdos
• Criação de Sites
• Administração "Rotina" do SharePoint
• Updates de SharePoint e SO
• Instalação de WSPs / Desenvolvimentos Futuros
• Gestão dos ambientes de DEV / Qualidade
• (…)

27. Planning
DOC: Governance Plan + Staffing Management
Plan
Staffing Management Plan indica necessidades de recursos humanos
Plan:
para garantir o Governance Plan:
• Um editor de conteúdos a 25% FTE
• Um SharePoint IT Pro a 50% FTE
• (…)

28. Planning
DOC: Permissions Plan
Define Grupos de SharePoint, uso de Grupos AD e Níveis de
Permissão.
Alterações a Maquetes/Design
Em função do feedback do cliente relativo às maquetes iniciais, e em
função do levantamento de requisitos, apresentar novas maquetes.

29. Planning
Reunião cliente Sponsor
Apresentação de Arquitetura de Informação, Âmbito, Wireframes e
Maquetes/Design.
Alterações
Alterações a Arquitetura de Informação
Alterações a Wireframes
Alterações a Âmbito
Alterações a Maquetes/Design
Alterações a outros docs

30. Planning
Reunião cliente Stakeholders
Reunião com os stakeholders para apresentar o resultado do
levantamento de requisitos e do planeamento.
Reunião DSI - Aprovação de Arquitetura
Hardware/Software

31. Planning
Aprovação
Aprovação formal de Arquitetura de Informação, Âmbito, Wireframes
e Maquetes/Design.
Cruzar os dedos. Este é um projeto fechado, o cliente não nos
comprou "horas" ou "user story points", o cliente comprou um
"user points",
produto final, por isso é muito importante obter a aprovação final e
inequívoca.
É muito importante sensibilizar o cliente para esta questão: se o
cliente quisesse um projeto "scrum" com a possibilidade de mudar de
"scrum"
scrum
ideias a cada momento, então teria que comprar um projeto
diferente, definido em horas/homem.

32. Planning
Definição de Equipa para Desenvolvimento e
Implementação
Este é o momento de definir a equipa para a próxima fase. Na fase
executing"
"executing" costumamos consumir mais tempo de:
• SharePoint IT Pro
Architect)
• SharePoint Senior Developer (Architect)
• SharePoint HTML Developer
• SharePoint Code Developer
Quanto tempo gastámos até aqui?
É comum gastar 20% a 30% de horas/homem e 30% a 60% do
tempo de calendário

33. Executing
Formar Equipa para fase Executing
Depois de definidos os "roles" necessários no final da fase de
planeamento, e porque pode já ter passado algum tempo, é hora de
ver exatamente quem está disponível, e determinar se temos que ir
buscar mais recursos.
Kick-
Kick-off interno de Executing
kick-
E quando já temos toda a equipa, o kick-off interno serve para
apresentar o projeto e todos os pressupostos e documentos
existentes.

34. Executing
DOC: Desenho Técnico
O SharePoint IT Pro (Admin + No-code solutions) e o SharePoint
(Admin No- solutions)
Architect)
Senior Developer (Architect) produzem o desenho técnico. Tendo em
conta que muito do trabalho de um projeto de Intranet pode ser
"no-code"
"no-code" é importante rever os métodos de deploy do trabalho
"no-code" Studio".
"no-code" e do trabalho "Visual Studio".
*Em SharePoint 2010 muito do trabalho "no-code" pode ser
"no-code"
WSPs.
exportado para WSPs.
"No-Code":
Code vs. "No-Code": Exactly Who Gets to Call Themselves a
Developer?
SharePoint Developer?
http://northamerica.msteched.com/topic/details/2012/BOF09-
http://northamerica.msteched.com/topic/details/2012/BOF09-DEV

35. Executing
DOC: Planeamento Revisto (Calendário, Recursos)
Depois de feito o Desenho Técnico há que atualizar as tarefas do
Planeamento e definir exatamente quando e por quem vão ser
executadas.
Instalação de SharePoint em ambiente Qualidade
no Cliente
Validação do servidor DEV e máquinas DEV
internas

36. Executing
DOC: Arquitetura Hardware/Software - Rever
Incluir Service App configs e mais detalhe.
Dado que já temos arquitectura de informação, desenho técnico e
informação mais detalhada sobre o que vai ser parametrizado e
desenvolvido, podemos detalhar a configuração das Service Apps
(Search, User Profile, Managed Metadata, BCS…).
Search, Profile, Metadata, BCS…).

37. Executing
DOC: Content Responsibility Matrix
A Content Responsibility Matrix é construída a partir da Arquitetura
de Informação e detalha, para cada site/lista quem lê e quem edita.
Desenvolvimento: HTML
Desenvolvimento: MasterPages e Page Layouts
Desenvolvimento: WebParts e outro código

38. Executing
Testes de BCS / Web Services / Outsystems em
DEV
Deploy de Masterpages, Page Layouts, Webparts
e outro código para DEV
Configuração de Service Apps em DEV

39. Executing
Implementação da Arquitetura de Informação em
DEV
no- solutions.
Criar sites, listas, formulários - no-code solutions.
Enquanto as web parts, event receivers, e outros desenvolvimentos
parts, receivers,
em código são "obrigatoriamente" deployed via WSP as ,
"no-code"
parametrizações e desenvolvimentos "no-code" podem ser deployed
de várias formas, seja por codificação destes elementos em Visual
Studio,
Studio, por export de SharePoint Designer para WSP por site
,
collection backup, entre outros.

40. Executing
Inserção de Conteúdos
Testes em DEV
Desenvolvimento: Correções
Configuração de Service Apps em Qualidade no
Cliente
Testes de integração com a AD em Qualidade no
Cliente

41. Executing
Testes de BCS / Web Services / Outsystems em
Qualidade no Cliente
Deploy em Qualidade no Cliente
Criação de Grupos SharePoint e revisão de
permissões em Qualidade
Uma vez que os ambientes de DEV estão, muitas vezes, em domínios
diferentes dos de Qualidade/Produção, a questão da definição de
Grupos de Sharepoint e respetiva inclusão de users e grupos AD é
feita em Qualidade.

42. Executing
Testes pelo Cliente
Correções
E agora o grande momento….

43. Executing
Aceitação
MOMENTO CRÍTICO
O cliente vai querer sempre alterações ou dizer que "afinal não tinha
percebido que ia funcionar assim". Este é o ponto crítico que opõe
Agile/Scrum Waterfall.
muitos defensores de Agile/Scrum aos defensores de Waterfall.
Apesar de estarmos a funcionar com um projeto em Waterfall de
âmbito fechado nada impede a implementação de sprints. Aliás, é até
recomendável que o cliente tenha acesso a deploys intermédios.
A criação de um documento de âmbito que seja suficientemente
detalhado mas ao mesmo tempo sucinto e legível é outro ponto
crítico para minimizar os danos que possam surgir na altura de
aprovação dos trabalhos em Qualidade.

44. Executing
Instalação de SharePoint em Farm Produção
Configuração de Service Apps em Produção
Testes de integração com a AD em Produção
Testes de BCS / Web Services / Outsystems em
Produção

45. Executing
Reunião Cliente Sponsor – Dinamização e Gestão
de Mudança
Preparar campanhas de divulgação e gestão de mudança.
Assegurar que os utilizadores aderem à nova Intranet e mudam
alguns dos seus hábitos (deixar de usar file shares, deixar de enviar
documentos por e-mail…).
e-mail…).
Preparação das ações de formação
DOC: Manual de Utilização da Intranet

46. Executing
DOC: Manual de Normas Gráficas
Formação ao Cliente
• Edição de Conteúdos e Admin Editoral
• Edição de Conteúdos (equipa alargada de contributors)
contributors)
• Admin SharePoint (DSI)
DOC: Plano de divulgação e gestão de mudança
Deploy para Produção
Testes em Produção

47. Executing
Go-
Go-Live
Pós-
Apoio Pós-Produção

48. Closing
Reunião de Fecho de Projeto com o cliente
DOC: Feedback e Inquérito de Satisfação
Reunião Interna de Fecho de Projeto
DOC: Lessons Learned

49. jb@joaobeltrao.com
www.joaobeltrao.com
@joaobeltrao