Gerente e gerente projeto

GUJ Master Membro desde: 15/01/2007 13:31:32 Mensagens: 1266 Offline

"Várias" é dificil de acreditar, ou você se refere à empresas sem cmmi, iso, etc. Já trabalhou para algum banco? Nada nunca muda.

O modelo hierárquico é baseado no medo, pois se você contraria um superior pode ser mandado pra rua. Quem lida muito com o medo, acaba sofrendo muito com ele, de forma que os processos burocráticos se tornam uma "proteção" para essas pessoas.

Modelo "tradicional" nem existe na literatura, mas ficou difundido dessa forma. Acaba sendo usado para se referir ao comando-controle.

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

felipefranz wrote:
Nenhum modelo garante nada na prática, visto que todos são passíveis de pró forma. Se a empresa quer ter a certificação somente por edital ela vai perder uma boa oportunidade de organizar a gestão e dar um tiro no pé a longo prazo por competitividade, embora como eu já tenha colocado, o avaliador tem a liberdade de reprovar a empresa se não sentir confiança que o processo está sendo seguido, seja útil para a empresa e é mantido sem "fraudes".

Mas foi voce quem disse que areas que possuem o CMMI nivel 3 tem processos maduros, nao eu. O meu argumento foi justamente pra dizer que nao tem e agora voce discorda de mim dizendo que nao tem.

E, naturalmente, como todos os que colocam o processo acima das pessoas, voce diz que a culpa é de alguem que nao soube avaliar o processo e nao do processo em si que permite falhas. Tipico. Ah mas voce nao poe o processo acima das pessoas. Poe sim, seu discurso eh obvio, favorecendo os processos pre-estabelecidos.

Nenhum, em nenhum momento eu falei em peao e nem em falta de conhecimento. É uma questão de papéis e responsabilidades, se a empresa tem uma política e não está na sua descrição de cargos alterá-la sem consultar os outros ou fazer as coisas ao seu gosto, você não pode fazê-las, simples assim. O programador pode sim ter um bom conhecimento em métricas, processos, regras de negócio, mas ele deve consultar a pessoa responsável para alterar os processos.

Mais ou menos como as leis em um país, você pode ser a favor da legalização das drogas, mas não pode usá-las enquanto estiver descrito.

Nao disse explicitamente, mas disse nas entrelinhas. E disse de novo agora. "É uma questao de papeis e responsabilidades, se a empresa tem uma política e não está na sua descrição de cargos alterá-la sem consultar os outros ...". Isso nao pode ser lido como: "Faca a tua parte e cale a boca!"?

Veja o micro-gerenciamente sendo evidenciado mais uma vez "consultar a pessoa responsavel". So a pessoa responsavel pode alterar o processo e ela toda-poderosa que é dificilmente vai sequer ouvir os reles programadores reclamando de ter que preencher um documento que para eles meros peoes nao servem pra nada, mas pra mim servem, ah se servem. Ah minhas planilhas coloridas.

Mas esta é a sua opinião. Eu discordo totalmente de você, o software funcionando tem ligação direta com um monte de métricas como densidade de defeitos, satisfação da equipe, próprias métricas de requisitos funcionais e não funcionais implementados, no fim todas as métricas dão suporte para que o software esteja funcionando. Até porque software funcionando é bem subjetivo. Quem garante que os requisitos implementados são de fato aqueles que o cliente queria? Quais são os usuários do sistema, é o cliente que especificou os requisitos? Será que o software não tem bugs desconhecidos?

Densidade de defeitos? Satisfacao da equipe? Entao me mostre exemplos destas metricas? Me diga como voce mede satisfacao da equipe, quais metricas usa?
E como voce mede requisitos funcionais e nao funcionais implementados? Num relatorio no Word? No Project? Sei.

O que pode acontecer é as estimativas terem sido mal feitas ou a pessoa burlar o apontamento de horas, mas se estiverem corretas a tomada de decisão tende a ser correta, ou ao menos melhor que se fosse feita sem estas medidas. E isto não é mutuamente excludente com questões como entregas parciais, por exemplo.

Esta também é sua opinião, discordo totalmente. Todas as outras medidas com medidas em relação a software (defeitos, requisitos implementados, satisfação do cliente) formam um conjunto para tomar decisões, inclusive a satisfação e motivação da equipe. De que adianta um software funcionando se ao final do projeto tá todo mundo insatisfeito, desmotivado e cansado?

Mais uma vez a conversa de equipe motivada. Como voce motiva a equipe? Com palminhas? Bexiguinas? Nao existe nada mais motivador do que liberdade para tomar as decisoes e ver o resultado do seu trabalho. Mais uma vez com software funcionando.

O resto eh conversa pra boi dormir.

JavaTeenager Membro desde: 12/08/2011 12:07:45 Mensagens: 190 Offline

Me desculpe, mas não vou mais discutir com você, e improdutivo e você fica zombando o trabalho de gestão e ironizando com planilhas coloridas, medições em planilhas, falando que não serve pra nada e eh coisa pra boi dormir, colocando entrelinhas que eu não escrevi.

Eu quis dizer que existe uma hierarquia e deve ser respeitada, isso não significa que o principal usuário do processo não possa dizer como ele deve ser melhorado, mas na minha opinião tem que ter uma centralizacao e ser respeitada, se você não concorda tudo bem, agora respeite a opinião alheia, tenha um mínimo de educação e respeito.

Eu afirmo que não coloco o processo acima das pessoas ate porque não faz sentido, são as pessoas que usam os processos, e quanto a motivação, isto e objeto de estudo da administração não e feito com base no senso comum.

Em relação a satisfação a varias formas de medir, depende da cultura da empresa, uma bastante conhecida e o painel com smiles representando humor com diferentes níveis, quando ha um padrão o gestor verifica o que esta acontecendo, esta técnica veio da general eletrica que e considerada uma das melhores empresas para se trabalhar no mundo.

Encerro aqui minha participação no tópico devido a falta de respeito e tentativa de interpretar e distorcer tudo que eu digo.

This message was edited 1 time. Last update was at 09/12/2011 19:59:42

felipefranz wrote:Me desculpe, mas não vou mais discutir com você, e improdutivo e você fica zombando o trabalho de gestão e ironizando com planilhas coloridas, medições em planilhas, falando que não serve pra nada e eh coisa pra boi dormir, colocando entrelinhas que eu não escrevi.

Eu quis dizer que existe uma hierarquia e deve ser respeitada, isso não significa que o principal usuário do processo não possa dizer como ele deve ser melhorado, mas na minha opinião tem que ter uma centralizacao e ser respeitada, se você não concorda tudo bem, agora respeite a opinião alheia, tenha um mínimo de educação e respeito.

Eu afirmo que não coloco o processo acima das pessoas ate porque não faz sentido, são as pessoas que usam os processos, e quanto a motivação, isto e objeto de estudo da administração não e feito com base no senso comum.

Em relação a satisfação a varias formas de medir, depende da cultura da empresa, uma bastante conhecida e o painel com smiles representando humor com diferentes níveis, quando ha um padrão o gestor verifica o que esta acontecendo, esta técnica veio da general eletrica que e considerada uma das melhores empresas para se trabalhar no mundo.

Encerro aqui minha participação no tópico devido a falta de respeito e tentativa de interpretar e distorcer tudo que eu digo.

Repare que eu nao tenho a intencao de te convencer de nada, nem duvido que voce acredita piamente no que escreve. Qualquer discussao aqui tem como foco quem esta lendo, quem nao conhece ainda as grandes empresas, os grandes processos, os grandes projetos. Esses que leem, ao ler textos como o seu podem acreditar que esta sua visao é a unica possivel, é a unica viavel e nao eh.

O grande ponto eh que voce valoriza sim os processos mais que as pessoas, embora insista em dizer que nao. Valoriza porque valoriza um carimbo que de nada vale, apontando este carimbo como exemplo de empresas com processos maduros. E quando eu falo sobre a minha experiencia com ele, voce imediatamente encontra algum culpado para o processo ser falho. Jamais voce cogitaria a hipotese do problema estar no processo.

Valoriza demais os processos quando fala da importancia da burocratizacao. Burocracia so serve para se proteger, eu ja trabalhei em lugares que havia necessidade de alguma burocracia. Boa parte dos usuarios do sistema nao tinha o menor pudor em dar o tapa e esconder a mao, em pedir alguma coisa e depois dizer que nao pediu. Isso estava alem do nosso alcance, nos nao podiamos educar os usuarios, que nao se importavam com isso, nem nos livrar deles obviamente. Nesse caso a burocracia era necessaria, qualquer conversa era documentada, qualquer solicitacao tinha que ser assinada.

Agora, burocracia interna? Eu me lembro uma vez, no comeco da minha carreira quando eu tinha muitos problemas com a tramitacao dos processos entre os setores da empresa. Um dia eu sugeri ao meu chefe, que era o dono da empresa, que fosse feito um sistema de protocolos, assim a cada erro que houvesse ficaria facil descobrir onde ele havia sido cometido. O velho me olhou e disse: "Otima, ideia, assim voce resolve o seu problema de nao ser acusado de erros que nao cometeu. Mas quem resolve o meu? Eu nao quero saber quem cometeu o erro, eu quero que eles nao acontecam."

Burocracia é a politica do cover your ass, eh normalmente empregada por administradores amadores que precisam da ilusao do controle e nao percebem que com isso eles atrapalham o fluxo de trabalho. É obvio que processos sao necessarios, mas o maior erro que eu vejo por ai sao os gerentes tentarem automatizar os processos antes de saber se eles funcionam ou nao. Quando voce automatiza voce congela o prcesso e cria resistencia a mudanca, porque para altera-lo voce precisa mudar toda a automatizacao, nao so o processo em si.

Quer melhorar o processo? Remova toda automatizacao dele, controle tudo com papel e caneta ou planilhas simples, depois adapte, arrume, pergunte as pessoas o que as esta atrapalhando. Meça onde as coisas estao demorando e tente de fato descobrir porque. Leia o processo, pense sobre ele. Nao assuma que voce sozinho sabe como resolve-lo, voce nao sabe, nem nunca vai saber, porque voce so ve as coisas do seu angulo e nao tem como voce conseguir ver pelo angulo de outro por mais que tente. Entao nao tente adivinhar, meça. Mas medir nao eh pedir para equipe preencher documentos, medir eh ler o fluxo, ver o que esta acontecendo de fato, nao o que as pessoas dizem ou acham que esta acontecendo. Aí, depois disso voce automatiza.

Mas o que os amadores gostam de fazer? Tentam resolver um problema com a primeira coisa que lhes vem a cabeca, normalmente colocando alguma burocracia. Resolve? Num primeiro momento sim, mas podem trazer consequencias pessimas. Geralmente ha solucoes melhores. Normalmente nao investigam as causas do problema, basta mais um pedaco de papel que fica tudo certo. Nao percebem que na verdade estao atrapalhando porque estao tornando o processo aos poucos cada vez mais moroso. E depois quando a morosidade fica notoria, nao se pode mais esconder, tentam encontrar o problema pondo mais burocracia ainda. Inventam entao milhares de coisas. Graficos, inputs, outputs, nomenclaturas para medir e ainda assim nao conseguem porque colocaram um parafernalha de coisas no meio do caminho que chegaram num ponto em que nao so nao se consegue bons resultados como tambem ja nao se consegue medir mais nada.

Sim, voce, Felipe, valoriza mais os processos que as pessoas. Valoriza quando diz que se deve automatizar a forma de estimativa de um projeto de software. E ouco muito isso e normalmente a desculpa eh: "Eu nao posso ter um processo de estimativas baseado no Feelling de um desenvolvedor". O que voces chamam de Feeling eu chamo de experiencia, nao dar credito a isso eh o mesmo que achar que voce pode jogar o PMBok nas maos de um administrador recem-formado e achar que ele pode gerir uma equipe. Ao dizer que isto deve ser automatizado voce desconsidera praticamente toda a literatura tecnica de desenvolvimento de software, que diz que so os desenvolvedores, analisando caso a caso, serao capazes de te dar uma estimativa, e ainda assim sera apenas uma estimativa.

Ha um numero tao grande de variaveis que podem influenciar no desenvolvimento de uma funcionalidade que voce ficaria espantado de descobrir. Alem da experiencia do desenvolvedor, a experiencia dele com o codigo que esta mexendo, com a linguagem. A qualidade do codigo, a ferramenta escolhida para o trabalho, as bibliotecas externas que vai precisar, se ela ja as conhece ou nao, se alguem da equipe ja conhece ou nao, se vai usar a A, a B, ou a C e por ai vai... Essa eh so a ponta do iceberg das variaveis.

Se voce acha simples, crie voce entao um bom algoritmo para estimativa e traga para nos, vamos usa-lo e ver se funciona. Porque todos os outros que inventaram ate hoje nao funcionaram.

Entao nao queira ficar irritado achando que eu nao te respeito, isso aqui eh so um forum, sua opiniao pra mim pouco importa, mas pode importar para quem le, entao nao vou deixar que voce fique propagando aos quatro ventos um monte de coisas que eu ja vi na pratica que nao funcionam.

Qualquer semelhanca...
http://www.observadorpolitico.org.br/grupos/educacao/forum/topic/a-fabula-dos-porcos-assados-autor-desconhecido/

JavaEvangelist Membro desde: 30/04/2007 07:43:01 Mensagens: 424 Offline

Olha, a verdade foi dita aqui acima.

Notícias, artigos e o maior fórum brasileiro sobre Java