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
Mostrando postagens com marcador comentários. Mostrar todas as postagens
Mostrando postagens com marcador comentários. Mostrar todas as postagens
Segunda-feira, 8 de Outubro de 2007
Terça-feira, 2 de Outubro de 2007
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.
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.
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.
Quarta-feira, 29 de Agosto de 2007
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!
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!
Segunda-feira, 27 de Agosto de 2007
Comentando os comentários - PARTE I
Topico "Apresentação"
CMilfont disse...
-----------------------------
Topico "Analogics B.C. (before change)"
-----------------------------
Topico "Primeira proposta de mudança - Daily Meetings"
-----------------------------
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!
CMilfont disse...
Legal a iniciativa Flávio, assinei o feed para acompanhar essa batalha :)
- 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
-----------------------------
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.
- 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
- 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 - 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
-----------------------------
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.
- 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.
-----------------------------
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!
Assinar:
Postagens (Atom)
