Porque eu escrevo este blog

Por causa do Rogério:

Bom Flavio,

se vc deseja um feedback, aqui vai o meu:
como disse em outro comentário que fizacho o seu blog muito legal, pois vc cita coisas que acontecem no dia a dia de cada um de nos que trabalhamos com tecnologia, e muitas vezes nos faz parar e pensar: "putz, igual ao que acontece aqui comigo!". Comigo me leva a refletir como tenho que melhorar muito ainda, seja profissionalmente ou na vida pessoal mesmo.
Levar na cabeça é normal, embora muitas vezes nós não estamos preparados para lidar com determinadas situações, por mais que nos esforcemos estudando sobre determinado assunto e como reagir a ele.
So posso te desejar boa sorte e que vc consiga ajudar a empresa onde trabalha a melhorar a sua forma de pensar o trabalho e o ramo de mercado que atuam, para que ela possa crescer cada vez mais.

Do Cesar:

Muito, muito, muito bom mesmo! Flavio, vou repercutir este teu post lá no i-scrum.ning.com e botar um link permanente para o teu blog, pode ser? Abraços!

Da Yanina:

Oi,Flávio. Eu sou Yanina, uma argentina que por acaso caiu no seu blog há um tempo e gostou bastante por duas razões: a primeira, meu namorado é gerente de prójetos de uma pequena empresa de desenvolvimento de software aqui em Buenos Aires e foi muito engraçado ler os mesmos problemas que ele tem todos os dias...a segunda razão, e peço desculpas pelo atrevimento,é que eu estou lecionando português nessa e em outra empresa que trabalha para o Brasil e estou utilizando alguns dos teus posts para todo tipo de exercícios...

Talvez não tenha nada a ver, mas estava me sentindo em falta utilizando o teu blog sem te avisar...

Qualquer dúvida, ou se você tem problemas com que eu continue "roubando" os teus posts, é só avisar...

abraços... yan

Da Fabiana:

Essa figura passa com exatidão a diferença entre uma e outra.

Muito show o blog estou sempre passando por aki e lendo os materiais.

Parabéns Flávio!

Do Wili:

Grande Flávio!
Já leu o livro "Seja Assertivo!"?
É de um pouco disso que você tá precisando (todos nós precisamos).
Dá uma lida e depois me fala.

Abraço
Willi

E de tantos outros leitores que deixam sempre o seu feedback aqui. Seja para acrescentar, corrigir, discordar, concordar, observar, refletir... enfim.

Um grande abraço aos leitores e comentaristas :)

E se você lê o blog, não hesite de deixar um alô com alguma experiência sua. Quero ver esse post bater o recorde de comentários. Será que conseguimos?

Vou deixar este post até domingo :)

Quero que VOCÊ, leitor, se apresente e conte algum fato que ocorreu com você recentemente. Vamos lá, duas frases. Não custa nada!

Abraços!

Correções de links

Acabo de descobrir que alguns links para download (principalmente os mais antigos, como os do podcast) estão quebrados. Estou corrigindo todos, mas peço aos leitores que se identificarem algum problema, postem comentários avisando ok? :)

Abraços!

Processos x Informação x Recursos

Este é um post comprido... mas se você tem ou trabalha em uma pequena ou média empresa, talvez você se identifique :)

Estou com um problema no trabalho. Como eu disse, a mudança da equipe para o laboratório de pesquisa iria causar alguns transtornos em relação à produtividade. E sinto que este processo começou: já noto mais conversa, mais MSN... Percebi também que a minha passagem para lá irá minimizar isto, mas não será como era antes. Isso começa a se tornar um fato.

Estou também percebendo que uma das piores situações de uma pequena e média empresa, que ocorre em grande maioria deste universo, está acontecendo: a dependência de pessoas.

Uma empresa, para funcionar de forma aceitável em um projeto, precisa ter diversas características. Eu citaria duas delas como sendo principais: a formalização de processos (mesmo que básicos e iniciais) e a previsibilidade (também em formato básico).

A previsibilidade abrangeria a capacidade do gestor (gerente, diretor ou líder) conseguir enxergar o resultado do projeto em uma linha de tempo razoavel (digamos, duas ou três semanas?). Isto eu estou conseguindo implantar, embora o processo seja mais complicado pois possuo uma diretoria que gosta de mudar o rumo bastante (e isto está na maneira de ser deles, portanto requer uma atenção especial para ser resolvida).

A formalização de processos eu também estou atacando. Notem um pequeno detalhe na relação entre formalizar um processo e burocratizar o sistema: uma pequena empresa não pode criar processos chatos, extensos e detalhistas pois senão irá matar o seu dia-a-dia. Um exemplo típico, que eu costumo citar, é uma empresa pequena implantando o RUP (Rational Unified Process) nu e cru. A empresa morreria em um mês.

Agora a formalização de processos curtos e simples irão auxiliar em muito o dia-a-dia. Foi pensando nisso que eu implantei alguns conceitos do SCRUM, pois vi que eram processos eficazes e simples. Além de dinamizar o processo de desenvolvimento, ainda temos dados que são gerados para posterior análise (o que auxilia, tcharam! ... a previsibilidade!).

Comecei com o conceito bem simples e estou agregando novas coisas à medida que vão surgindo. Hoje, por exemplo, surgiu uma atividade que havia sido cancelada ou abandonada. O que fazer? Tivemos que criar um "pseudo-status" pra ela, ou seja, só colocar um "Abandonado" ao lado do post-it. Posteriormente iremos analisar isso com mais calma. Mas notem que mantive a simplicidade do sistema.

Outro conceito que eu praticamente rasguei, inicialmente. O cronograma do em formato Gantt (Project). Como o meu projeto possui diversas mudanças, eu já havia criado 3 ou 4 cronogramas diferentes. E a equipe tinha dificuldade em acompanhar o cronograma, pela dificuldade que ele apresenta. O nosso cronograma passou a ser o painel de atividades. Nossa previsibilidade passou a ser de 2 semanas, o tamanho do nosso ciclo de desenvolvimento (ou sprint, na terminologia do SCRUM).

Vejam como eu mudei bastante os processos, tornando-os mais simples e eficazes... algumas vezes indo até contra o recomendado por livros como o PMBOK. Mas estou fazendo o possível para adaptar o gerenciamento de projetos para a minha realidade: que é uma realidade de incertezas, recursos que precisam de coisas simples para se comprometerem, diretoria que precisa de resultados para se acalmar, etc.

O que quero resolver com tudo isso que eu escrevi? A dependência dos recursos.

Evitar que uma empresa pequena se torne refém de seus recursos, é um dos maiores desafios do gestor. O meu irmão possui uma pequena empresa e está nessa situação. A empresa onde estou, possui um cenário parecido. Conheço outras várias que estão neste nível também.

Graças a esta situação, eu estou tendo que ser as vezes um líder mais frouxo. "O quê? Nunca seja frouxo" muitos dirão. Mas o fato é que na altura em que estamos, eu não posso dar um esporro em um recurso, sabendo que ele pode encher o saco e pegar as coisas e ir embora. E com isso, levar todo o conhecimento adquirido durante este tempo em que esteve. Isso é mais crítico ainda no mercado de TI, onde ele pode sair e conseguir algo até melhor no outro dia.

Agora vocês devem estar entendendo a minha preocupação em definir processos. Vejam, a definição dos processos precisa prever também a GESTÃO DA INFORMAÇÃO! Documentar o que se descobre ou o que se desenvolve é FUNDAMENTAL, ou como dizia um professor meu, é condição SINE QUA NON para garantir que a empresa nunca ficará refém do seu funcionário.

E ficar refém de funcionário, meus amigos, é garantir que o líder terá que ser todo cheio de dedos no trato com a equipe. O respeito sempre existe, é claro. Mas a cobrança se torna mais superficial.

Eu atualmente me encontro nessa situação. Estou procurando mudar. E você, caro amigo, já viveu uma situação assim? Poste aí :)

Abraços

Nova enquete

Uma enquete para pensarmos: qual das áreas do PMBOK você costuma dar mais atenção?

Não deixe de responder. Vamos ver o resultado :)

Seja honesto, claro.

Montando a sua equipe...

Não é a toa que existe um processo específico do PMBOK sobre a montagem da equipe. Eu acredito que este é um dos pontos principais a serem considerados em um projeto.

Vamos a uma situação que aconteceu comigo e vocês irão entender...

Ontem na reunião de definição dos objetivos do ciclo de desenvolvimento, o meu chefe comentou da necessidade de colocarmos mais uma pessoa na nossa equipe (somos 3 desenvolvedores + 1 gerente) que ficaria responsável pela documentação, um dos pontos chaves do nosso projeto. Recusei a idéia, pelo menos de forma momentânea, pois acredito que estamos "redondinhos" para as tarefas que temos pela frente. Eu confesso que 4 desenvolvedores seria o tamanho ideal para este projeto, mas não vejo a necessidade de termos uma pessoa só para documentação. Além disso, recém saimos de uma mudança de ambiente de trabalho que já causou um impacto ruim na equipe. Acrescentar uma nova pessoa poderia trazer um impacto pior.

Quando iniciamos este projeto, lá em setembro de 2006, a equipe era composta pelas seguintes pessoas:

- Flavio, gerente de projetos (na época bem inexperiente);

- EB, o patrocinador-especialista-cliente do projeto;

- GP, um dos melhores recursos do nosso projeto. Porém, devido à desorganização inicial, teve sua motivação e produtividade afetadas enormemente;

- VT, outro bom recurso, mas que tem sérios problemas com horários;

- PV, inicialmente sub-avaliado como um recurso para suporte;

- VP, bom conhecedor dos assuntos, mas de personalidade forte e controversa;

- LK, bom conhecedor do assunto, mas visivelmente não estava muito interessado;

- PZ, grande amigo do LK e bom recurso, que também visivelmente não estava muito interessado;

- GA, uma espécie de bombeiro do grupo, sendo chamado apenas em casos de necessidade;

- FS, foi o último recurso a se juntar a nós e tem se mostrado muito bom e fácil de lidar.


Começamos com 7 desenvolvedores, 1 patrocinador-cliente-especialista, 1 bombeiro e 1 gerente. Imaginem uma fase de concepção (muita pesquisa) sendo organizada e dividida entre 7 pessoas? É óbvio que o resultado foi terrível. Não entrarei em maiores detalhes para não perder o foco, mas ficou evidente desde a primeira reunião de kick-off que 7 pessoas era um número muito grande para se administrar, ainda mais em um projeto de grande complexidade como o nosso.

Então, o tempo tratou de reduzir a equipe. Sairam, na ordem cronológica:

- PZ, para fazer intercâmbio no exterior, em dezembro 2006.

- LK, para entrar em outra empresa, em janeiro 2007.

- GA, para fazer doutorado em Portugal.

- VP, por ser o principal causador de conflitos do grupo (o único que foi "demitido"). Foi substituído pelo FS.

- GP, para fazer mestrado na Itália.

É impressionante a diferença entre se trabalhar com 3 ou 4 pessoas. A comunicação flui, a motivação e produtividade crescem... enfim, tudo se torna mais "administrável". Podemos dizer também que a possibilidade de definir de fato quem é responsável pelo quê, tornou as coisas mais simples também (VT é responsável pelo software, PV pelo hardware e o FS pelo middleware... ficou mais ou menos assim).

Tamanho e qualidade da equipe não podem ser avaliadas separadamente. Como disse um palestrante uma vez: "1 mulher faz um bebê em 9 meses, mas 9 mulheres não fazem 1 bebê em 1 mês". É preciso avaliar o projeto e escolher bem a sua equipe, seja em quantidade de pessoas, seja em qualidade.

Eu aprendi as seguintes lições:

a) Lealdade, experiência e relacionamento devem ser essenciais. Ninguém quer contratar alguém sabendo que essa pessoa tem um passado de deixar os outros na mão, ou que essa pessoa não tem experiência na área onde está se metendo (ou se for contratar um inexperiente, certificar de que ele terá suporte). E o relacionamento? Uma pessoa que não consegue conviver ou trabalhar em equipe, não pode ser cogitada para um trabalho em que a comunicação e interação é grande.

b) Avaliar MUITO BEM as necessidades de equipe. Sete pessoas para realizar uma pesquisa na internet? Uma ou duas pessoas para desenvolverem uma tecnologia digna de um mestrado? Quantidade não é qualidade, e vice-versa.

c) Ter pelo menos uma ou duas pessoas de extrema confiança no grupo. São elas que geralmente serão seu braço direito (e esquerdo). Opte por pelo menos uma pessoa com um perfil comunicativo e com bons conhecimentos técnicos. E deixe claro o que você pretende com esta pessoa, para garantir a lealdade.

d) Cuidado com a amizade. Amizade e profissionalismo são diferentes. Se você for muito amigo de seus subordinados, o profissionalismo começa a sumir. Mas isso é um assunto para ser discutido posteriormente...

e) Se você puder, interfira na formação da equipe. Lembre-se de que é você quem irá conviver o dia-a-dia com estas pessoas, não o seu chefe.

Comentando os comentários - PARTE II

Tópico "O que faz o pagamento da caixinha..."

Daniel Wildt disse...

Dê liberdade para dar e receber feedback sobre o trabalho. Mantenha um ambiente real, sincero e de respeito e terás uma equipe motivada.

Uma pergunta que eu faço: R$0,50 motivam a sua equipe a chegar no horário? Eles concordam com isto? Questione isto. Porque preciso pagar multa para me sentir motivado? Será que não está faltando algo?

Lembre-se que a mudança maior da sua equipe deve ser cultural, e não relacionada a mudança de um processo. O processo deve ser modificado pelas pessoas.

29 de Agosto de 2007 09:24

Resposta: Muito obrigado pela participação, Daniel. Concordo com o que tu disseste, um ambiente assim facilita muito a motivação. Sobre a caixinha, isso foi consenso. O valor será revertido a nossa confraternização mensal. Eles aceitaram muito bem a idéia!

--------------------
--------------------

Tópico "Desvirginação: a primeira vez."

Petronio Araújo de Medeiros disse...

É, realmente uma tarefa muito difíl essa de manter todo mundo motivado. Mas, acho que se você fizer com que todos percebam a importancia disso, mostrar que isso realmente funciona, mostrando que, por exemplo, tem gente correndo atrás de resolver os impedimentos afim de deixar seu caminho livre. Acho que isso vai motivá-los.

Boa sorte, e cuidado para não desmotivar, parando de escrever aqui no blog. Isso possívelmente pode acontecer.

Um abraço,
Petrônio.

28 de Agosto de 2007 21:34

Resposta: Muito obrigado pelo comentário, Petrônio! Eu espero que eles percebam que estaremos trabalhando diariamente em cima dos riscos. Porém, me assusta a possibilidade da desorganização da diretoria desmotivar a(s) equipe(s). É este fator que pretendo atacar fortemente.

Daniel Wildt disse...

IMHO, Se o impedimento ainda existe, ele deve ser resolvido. Enquanto não for, ele fica visível para a equipe.

29 de Agosto de 2007 09:28

Resposta: Daniel, obrigado pelo comentário. Então de fato fechou com o que eu imaginava. Valeu!

Marcos Vinícius disse...

Sobre este lance do impedimento acho o seguinte: não adianta muito ficar reportando impedimento só para reportar. Se foi uma coisa que impediu naquele dia, mas depois foi resolvida, parou de impedir e hoje não tem mais sentido nem citar, então nem cita.

Se é algo que ainda atrapalha e precisa ser resolvido, inclusive fora da alçada do desenvolvedor, então tem que falar. Mas também acho que vocês devem encontrar uma melhor forma de lidar com isto. O que for melhor para vocês.

29 de Agosto de 2007 10:37


Resposta: Valeu, Marcos! Acredito que no começo o pessoal vai reportar por reportar. Com o tempo, eles vão pegando o jeito (inclusive eu!). Estou trabalhando dessa forma com eles. Abraço!

--------------------
--------------------

Tópico "Intensive Knowledge Projects ou projetos volúveis?"

Marcos Vinícius disse...

Bom, não sei como resolver este problema específico com seu chefe :-) mas gostaria de falar um pouco sobre os "Intensive Knowledge Projects".

Uma das idéias do SCRUM especificamente é que o Sprint seja protegido contra mudanças. Nós sabemos que mudanças existem e que, dependendo da empresa e do tipo do projeto, elas podem acontecer mais rápido ou não. Então, de acordo com a empresa ou o projeto os Sprints poderão ter duração diferente.

Se o seu chefe não consegue passar 1 semana sem mudar de idéia, então seu Sprint dura 1 semana, qeu é o tempo máximo que você consegue proteger a equipe e o desenvolvimento de interferências externas. Em ambientes e projetos mais estáveis os Sprints podem durar 1 mês, tal qual a metodologia do SCRUM prevê inicialmente.

Mas o importante é que durante um ciclo de desenvolvimento a equipe tenha condição de trabalhar em paz, sem interferências.

29 de Agosto de 2007 10:43

Resposta: Marcos, valeu de novo. Esse esclarecimento foi muito positivo. De fato, eu estou iniciando com um "sprint" ou ciclo (como estou chamando) de 10 dias úteis (2 semanas). Vou me adaptar conforme a necessidade. Como eu disse, preciso plantar a semente para depois aparar os galhos :) Valeu, meu amigo!

Comentando os comentários - PARTE I

Topico "Apresentação"

CMilfont disse...

Legal a iniciativa Flávio, assinei o feed para acompanhar essa batalha :)

27 de Agosto de 2007 04:22

Não possuo disse...

Muito bom Flávio, tbm acompanharei a sua saga e espero poder trocar experiências com você! Conte comigo! Abtraços

27 de Agosto de 2007 05:36

Resposta: Eu que agradeço a presença, meus amigos! Fico feliz que a idéia tenha interessado o pessoal :)

-----------------------------

Topico "Analogics B.C. (before change)"

E.Kautzmann disse...

Olá Flávio.
Legal sua iniciativa quanto a exposição de sua rotina.
Creio que todas pequenas empresas encaixam-se nos problemas que vc reportou, mas uma coisa posso afirmar: enquanto não houver um consentimento geral de TODOS, as coisas ficam bagunçadas.
Para o gerente com perfil flexível demais, suas delegações podem não sofrer um efeito automático. Já o rígido, as ações podem ser interpretadas de imediato, mas gerando um "desagrado" e passa a ser "o carrasco". Tens que achar um meio termo.
Escopo e Comunicação considero os principais processos, devemos dispor mais tempo para o escopo, evitando futuros adendos/alterações no projeto - que neste caso seria um novo projeto.
A comunicação deve ser entendida e executada por todos. Através dela temos uma outra visão dos profissionais e não-profissionais da empresa. Eu centralizei tudo em um sistema básico de controle de tarefas (projeto, tempo de envolvimento, envolvidos, descrição das atividades realizadas) - um suposto "Daily Meetings".
Se quiser, vamos conversar sobre essa questão mais adiante.

Bom começo!
Cordial abraço.

27 de Agosto de 2007 06:30

Resposta: Muito obrigado pelos comentários! Tu abordaste dois conceitos que de fato eu quero me aprofundar MUITO: escopo e comunicação (o outro que eu considero interessantíssimo é de RH). As reuniões diárias irão atacar estes três conceitos diretamente, na minha opinião... principalmente comunicação e RH. Sobre o modo de ser gerente, eu era do tipo "amigão" demais. Estou tentando mudar, mas não quero mudar radicalmente para não parecer MAIS carrasco. Já enviei um email no final de semana avisando que com essa mudança, eu continuaria do lado da equipe defendendo todos, mas que teria que cobrar os resultados solicitados pelos chefes... e não mediria esforços para isso. Acho que eles entenderam o recado. Falta eu mesmo mudar agora :)

Marcos Vinícius disse...

Oi Flávio!
Acho que vou virar fã de carterinha do seu blog e até pensei em fazer um no mesmo gênero, já que agora vou ajudar a implantar um novo processo em uma empresa nova que está vindo exatamente de um grupo de pesquisa na universidade.

Depois posto outros comentários. Vamos em frente e sucesso a você!

Abraços

27 de Agosto de 2007 11:02

Resposta: Muito obrigado pelo comentário! O que tu está esperando?? Cria um também! Nada melhor do que expôr as experiências com os demais. É gratificante ver como tantas outras pessoas vivem na mesma situação em que eu me encontro (iniciando, cheio de dificuldades) e ver que eu estou agregando experiência a outras pessoas, enquanto agrego a mim mesmo. Segue postando que pelo menos duas vezes por semana eu criarei um tópico assim (comentando os comentários).

LuizLH disse...

Flávio parabéns pela sua iniciativa,

Como vc realmente deixa claro existe falta de foco e nenhum produto.
O que eu penso, antes de mais nada, acredito ser necessário listar
o produto ou produtos que a empresa pode construir.
Realizar uma pesquisa de mercado, verificar a sua viabilidade, concorrentes,
valor agregado, etc, e sem dúvida prioriza-los.
Como os recursos financeiros e humanos são limitados não adianta ter um monte
de ideias e construir prototipos e não se chegar em um produto final vendável.

Com os produtos e seus escopos determinados, aí sim focar na construção e
melhoria do mesmo.

Dica, vc pode utilizar o documento de visão do RUP. É um bom ponto de partida
p/ vc delinear o que é um produto.

Até mais e Sucesso...

Luiz

27 de Agosto de 2007 13:29

LuizLH disse...

Olá Flávio,

Faltou incluir no comentário anterior o mais importante.
Mostrar p/ a Gerencia Sênior a necessidade de ter os produto(s) definidos, mapeados e estudados.
Se necessário a empresa pode criar uma área de P&D p/ testar conceitos e protótipos e se falta recursos, determinar que o P&D será realizado X horas por semana e o resto é alocado p/ o produto principal da emrpesa.

Até mais...

Luiz

27 de Agosto de 2007 13:35

Resposta: Muito obrigado pelo comentário! De fato, temos esse problema na empresa. Como eu disse, a empresa foi criada como o braço comercial de um grupo de pesquisa da universidade. Então sofremos com essa crise de identidade (somos pesquisadores ou empresa?). Estou lutando para cortar essa relação ao mínimo necessário. A tua idéia é bastante interessante. Eu tento há algum tempo fechar a WBS, mas estamos com alguns problemas para construí-la. Já tivemos uns três ou quatro cronogramas que foram totalmente mudados ,então tu imagina a minha disposição para começar tudo do zero de novo... mas eu concordo que isso é de EXTREMA importância e SERÁ priorizado!


-----------------------------

Topico "Primeira proposta de mudança - Daily Meetings"

Grispe disse...

Flavio, boa tarde. Primeiro parabens pela iniciativa. Ira aprender muito e tambem ensinar a muitos ... espero poder acompanhar seu diário.

Primeiro comentário (*): voce cita estabelecr "daily Meeting". Dúvida: O seu pessoal, conforme citado, tem problemas de horários ... alguns horários "malucos" devido a faculdade e outros pela distancia ... como voce irá gerenciar esta dificuldade ???

Em caso de dificuldade de "juntar a turma", voce poderia fazer com que todos informassem diariamente, via e-mail, fone ou qualquer outro mecanismo, o andamento das atividades ... nas atividades do cronograma ...

Alias ... voce tem um cronograma ??? as atividades e grupo de atividades estão bem delineadas ??? pelo menos as que exigem ação no momento atual ???

(*) Peço licença ao "meter o dedo na ferida" ... hora irei fazer o papel de "advogado do diabo" ... outros momentos irei questionar apenas com um objetivo: questionar ... mas sempre objetivando ajudá-lo e em conjunto, construirmos uma referencia para ambos.

27 de Agosto de 2007 10:45

Resposta: Muito obrigado pelo comentário! Meu amigo, a coisa que eu mais quero é que tu meta o dedo na ferida!! Não tenha dó :) Aliás, isso serve para todos. Não tenham medo de criticar, opinar ou "meter o bedelho". Eu quero mesmo é que vocês participem. E eu irei responder sempre. Sobre os horários, eu pensei que teria dificuldade... mas todos aceitaram as 14h15. O único que poderá ter problema é o VT, já que ele é uma criatura noturna haha. Nós temos um cronograma. Eu já vinha tentando manter um período de vida dele de aproximadamente 1 mês, mas ainda assim ele sofreu algumas mudanças... então acabei deixando ele de lado. Minha idéia é focar na WBS e o cronograma servir como uma visão geral (macro) do que temos para fazer. As atividades mesmo estarão listadas no painel de atividades. Posteriormente, eu pretendo atualizar o cronograma com estes dados diários, para gerar uma visão de "previsto x realizado". Achas pertinente? Grande abraço!

Marcos Vinícius disse...

Este ambiente de horários caóticos não é o melhor para implementar reuniões mesmo não, mas é preciso combinar um horário com o pessoal que possa ser cumprido.

A "reunião por e-mail" é um problema e deve ser evitada. Inclusive no curso que acabei de fazer de Scrum Master é bem colocado que as reuniões devem ser presenciais e que elas não servem para que a equipe dê feedback ao Scrum Master (ou Gerente ou etcs), mas sim que a equipe se mantenha unida e dê feedback a ela mesma. Seguindo o conceito de equipes auto-gerenciáveis pregado pelo Scrum.

Tente agendar um horário (vai dar errado no começo) e pedir disciplina do pessoal em cumprí-lo.

27 de Agosto de 2007 11:15

Resposta: Boa Marcos! Eu frisei bastante isso na reunião: eles não prestam conta para mim, mas para a equipe. SE E SOMENTE SE eles tiverem que faltar por algum motivo, que prestem a conta através de algum outro membro da equipe (passando o status por ele) ou por email ou telefone. Mas a reunião é obrigatória.

-----------------------------

Ufa! Espero dar conta de todos os comentários :)))

As minhas tréplicas eu darei no próximo "comentando os comentários". Vocês podem responder neste tópico (se quiserem deixarem suas tréplicas!).

Abração!