No início de um projeto, é muito importante reunir todos os participantes para definir vários assuntos referentes ao desenvolvimento e implantação do software. Logo, pode-se dizer que este é um momento de Kick-off do projeto. Se você não conhece este termo, não deixe de ler este artigo!
Introdução
Já jogou futebol nos videogames? Bom, então você deve se lembrar que a partida começa quando a palavra “Kick-off” aparece na tela, não é? Pois bem, é nesse sentido que vamos tratar esse artigo.
Kick-off, em inglês, significa o sinal de início de uma atividade ou evento, e é um termo bastante utilizado em várias ocasiões. Uma reunião de Kick-off na área de Tecnologia da Informação é o momento em que todos os participantes do projeto se reúnem para definir objetivos, recursos, restrições, prazos e cronogramas referente ao projeto em pauta. O evento deve ocorrer em um local separado do ambiente de trabalho para facilitar a comunicação e evitar interrupções.
Essa reunião normalmente tem duração de duas a três horas, dependendo da dimensão do projeto e do compartilhamento de informações para esclarecer as possíveis dúvidas dos participantes. Ao final desta reunião, finalmente dá-se o início ao desenvolvimento do projeto.
Project Charter
A reunião de Kick-off sempre conta com um responsável que irá conduzir o andamento de cada tópico da reunião. Para isso, é necessário que exista um documento principal composto de todas as características do projeto, de forma que todos possam acompanhar a discussão da reunião. Este documento recebe o nome de Project Charter, e deve ser visualizado em um Data Show ou uma cópia deve ser entregue a cada participante.
O Project Charter, Também conhecido como Termo de Abertura do Projeto (TAP), é extremamente importante para a reunião de Kick-off. Normalmente é elaborado pelo Gestor de Projetos, que se encarrega de enunciar todos os itens relacionados ao software que será desenvolvido, desde o planejamento até a fase de implantação e treinamento.
Em linhas gerais, o Project Charter contém a especificação do projeto em geral, envolvendo principalmente os pontos:
- Objetivo, justificativa e propósito do projeto;
- Recursos humanos do projeto (analistas, projetistas, gestores e desenvolvedores);
- Demais stakeholders envolvidos (usuários, gerentes e parceiros);
- Cronograma e prazos de entrega;
- Recursos materiais e investimentos necessários;
- Possíveis riscos que podem ocorrer, bem como um plano de prevenção e/ou recuperação;
- Implantação e capacitação dos usuários (equipe residente, treinamento EaD, etc.).
Bom, como se pode perceber, este documento deve ser bem formalizado. É um artefato importante para que não haja obstáculos no andamento do projeto e não ocorra imprevistos não documentados.
Work Breakdown Structure
No entanto, eis que eventualmente na reunião de Kick-off pode existir mais alguns documentos pautados para discussão. Um deles é o Work Breakdown Structure, abreviado como WBS. Este documento, na verdade, é uma ferramenta que permite a decomposição do fluxo de trabalho em atividades específicas, na forma de um diagrama. Na prática, o WBS pode ser comparado a uma hierarquia. Quanto mais subníveis houver, maior será o detalhamento de uma atividade.
Ficou complicado entender, não é? Talvez com um exemplo fique mais claro.
Considere que em um determinado projeto seja necessário criar um módulo de cálculo de comissão dos vendedores. A partir da descrição dessa atividade-pai, podemos dividi-la em subitens:
- Criar tabela de comissões
- Elaborar tela de visualização
- Desenvolver rotina de cálculo
- Realizar testes e correções
Por sua vez, podemos detalhar a primeira atividade, “Criar tabela de comissões”:
- Avaliar quais colunas serão necessárias para a tabela
- Definir os tipos de dados e os tamanhos
- Definir as chaves (primárias e estrangeiras) e os índices
- Criar a tabela e documentar a estrutura
Observe a ênfase de detalhamento para cada tarefa a ser realizada. Agora ficou melhor, não é? Para melhorar ainda mais a compreensão, clique na imagem abaixo para visualizar um exemplo prático de WBS:
Exemplo de Work Breakdown Structure (WBS)
Imagem retirada do Blog Instituto Fazendo História
Conforme a ocasião, outros documentos ainda podem aparecer na reunião. Se o projeto de software discutido for substituir um sistema já utilizado pelo cliente, talvez seja necessário elencar um documento com as especificações de migração de dados, ou seja, a documentação para o procedimento de cópia dos dados do software atual para a base de dados do software que será desenvolvido. A migração não é uma tarefa simples, e é um pouco mais complexa quando é feita entre sistemas de bancos de dados diferentes, como PostgreSQL para Firebird, por exemplo. Além disso, geralmente a estrutura das tabelas é diferente, exigindo que vários testes sejam realizados antes da cópia definitiva.
Desfecho da reunião
Focando novamente na reunião, quando todos os itens forem abordados pelo responsável, abre-se um espaço para as dúvidas dos participantes e demais esclarecimentos necessários. Neste momento também é importante propor mudanças ou melhorias nas fases do projeto. Se a sugestão for aceita, o Project Charter é atualizado pelo Gestor de Projetos, destacando a parte alterada do documento com outra fonte ou formatação. Isso facilita a visualização das alterações no documento ocorridas durante a reunião de Kick-off.
Por fim, cada participante recebe um documento chamado Roadmap. Este documento contém as tarefas destinadas ao integrante para a fase atual do projeto. Para um desenvolvedor, por exemplo, o Roadmap seria as tarefas de implementação, contendo data de início, término e estimativa de tempo. O Roadmap permite que o colaborador se organize dentro dos prazos e siga um roteiro linear de atividades com a ciência dos superiores.
Bom, pessoal, decidi elaborar este artigo porque participei de uma reunião de Kick-off há pouco tempo e achei interessante compartilhar esse conhecimento aqui no blog. É claro, nem todas as reuniões de Kick-off são da mesma forma. Elas podem ser diferentes conforme a cultura da empresa, tipo de projeto ou quantidade de integrantes envolvidos, mas basicamente o contexto é o mesmo!
E então, vamos jogar futebol no videogame? Haha.
Até a próxima, leitores!
Muito bom! Excelente explicação! Obrigada.
Obrigado, Daniele!
ótimo artigo. parabéns!
Obrigado, Carlos!
Abraço.
Muito bom, parabéns!!!
Obrigado, Josiane!
Ótimo artigo, Muito esclarecedor!
Abraço!
Obrigado pelo feedback, Eduardo!
Parabéns pelo artigo, muito bem elaborado!
Muito obrigado pelo feedback, Bruno! Abraço!
Parabéns mesmo , muito bom!
Obrigado, Rudnei! Abraço!
….Muito esclarecedor.
Obrigada.
Obrigado pelo comentário, Lecy! Grande abraço!
Muito bom o artigo. Claro e objetivo. Parabéns!!!
Fico feliz pelo feedback, Jair! Um grande abraço!
Achei bem legal sua abordagem de projetos amigo. Parabens! Mas tambem gostaria de dizer que alguns documentos como o project charter e a wbs, estao um pouco fora do conceito tradicional. Mas acredito que para uma abordagem mais agil ela funciona bem.
Olá, Diogo!
Obrigado pelo feedback! Os conceitos de Project Charter e WBS, em suas totalidades, são bem amplos e levariam três ou mais artigos para explicá-los. Como prezo pela objetividade nos artigos, apresentei uma visão sucinta destes conceitos, baseados na minha experiência ao trabalhar com estes artefatos no cotidiano. Abraço!
Excelente trabalho!!
Muito bem elaborado e conciso.
Um abraço,
Olá, Karen! Obrigado pelo feedback!
Elaborar um artigo conciso é justamente a minha intenção!
Abraço!
Ótimo texto!
Claro e objetivo!
Opa, obrigado pelo feedback, Marcelo!
Abraço!
Caro Professor André Luis Celestino,
Em primeiro lugar, muito obrigado pelas explicações. Uma dúvida: ao invés da palavra Holdmap, a palavra não seria Roadmap, que significa, em uma tradução livre, “caminho das pedras” ?
Cordiais Saudações.
Olá, Marcus!
Primeiramente, obrigado pela visita no blog e por dedicar um tempo para escrever o comentário.
Em segundo lugar, agradeço pela correção. O termo correto realmente é “RoadMap”. Holdmap foi utilizado erroneamente em uma das empresas em que trabalhei.
Já alterei no texto!
Abraço!
Excelente artigo, parabéns!
Obrigado, Sandro!