Entrei por acaso na última página deste tópico, achando que seria mais um daqueles com discussões infinitas beirando as religiosas/esportivas.
Achei muito interessante essa discussão que nasceu na página 7, sobre o papel de gerentes no desenvolvimento de software, hoje em dia, especialmente considerando times ágeis.
Poderíamos continuar esta conversa num tópico específico para isso?
(E evitar o desgaste que esse já causou com outros assuntos).
Que tal neste tópico aqui?
[quote=j.silvestre]Alguém tem que ter uma visão Global do projeto que uma equipe esta trabalhando, muitas vezes o programador, desenvolvedor, analista, etc,
tem apenas uma visão compartimentada, ou seja recebeu uma tarefa para fazer uma parte do aplicativo, outras pessoas estão trabalhando em
outras atividades no mesmo projeto. Então é preciso alguém com uma visão global do projeto, que pode até ser chamado de gerente do projeto ou não.
sds
j.silvestre [/quote]
Compartimentação assegura que programadores fiquem isolados do resto da equipe preparando-os assim para se tornarem peças de fácil substituição. O resultado final são assalariados digitadores de luxo que possuem apenas uma visão simplista sobre os projetos de software e que nunca tem o conhecimento do todo. Essas pessoas acabam ficando vulneráveis a indotrinação e lavagem cerebral corporativa.
Em equipes auto-gerenciáveis, todos tem o direito de ter uma visão global do projeto.
Já é a 3a pessoa que tenta negar a existência de equipes auto-gerenciáveis usando o argumento que não é possível contar com todos serem maduros o suficiente para o trabalho. Isso diz muito sobre os problemas que a sua empresa enfrenta pra atrair bons profissionais. Mas por algum motivo isso é problema meu? Hilário.
[quote=adriano_si]
Mais um problema pessoal que foi generalizado. Hierarquia existe e sempre existirá. Posso daqui há 20 anos admitir que falei bobagem, mas não está nem no horizonte um mundo sem hierarquias.[/quote]
Não disse que hierarquia não existe ou deixará de existir. Tenta ler de novo o que eu disse, desta vez com mais calma.
Pelo que entendi, seu ponto de vista é de alguém conformado com a falta de maturidade profissional entre os membros da equipe. Por isso a necessidade de uma figura controladora.
Uma dúvida: você já trabalhou em equipes auto-gerenciável pra saber quem se encaixa ou não nesse modelo?
Se o gerente de projeto só faz isso e não se envolve no projeto, ele pode ter o título que for, mas ele não é um gerente de projeto.
Uma equipe com essa média de experiência é uma temeridade ser auto-gerenciável. O problema não é responsabilidade, é experiência mesmo.
Ah, e se ninguém cobra prazos de ninguém, onde está o auto-gerenciamento?
[/quote]
Por que você acha que resolver burocracias e outras questões não técnicas relacionadas ao projeto é o mesmo que “não se envolver com o projeto”?
Aí está um ponto curioso. Quando você fez essa pergunta parei pra avaliar o ambiente onde estou inserido. Vou tentar explicar como funciona.
Temos 3 dinossauros do mercado onde estamos inseridos. Os caras são programadores antigos em outras plataformas pré-Java, porém possuem um conhecimento monstro do negócio, chegando ao ponto de muitos concursados do cliente virem aqui com a eles tirar dúvidas de negócio.
Abaixo, temos 4 figuras que já estão há mais de 3 anos na empresa e já possuem um conhecimento acima da média do negócio. Eu estou nesse bolo, crescendo a cada dia.
Abaixo, está uma galera que entrou recente (menos de 6 meses). Essa galera é bem esforçada, sendo que dos que entraram, posso dizer que depois de 6 meses, apenas 2 ainda estão treinando, todos os outros estão batendo pênalti já (no negócio que estamos, 6 meses é um tempo curto).
Resumindo, apesar da equipe ser NOVA, posso dizer que a equipe é bem madura. Fazemos 2 reuniões mensais para verificação de andamento de tarefas. Mantemos uma hierarquia interna para fluxo e controle de comunicação. Cada um faz seu horário e todos trabalhamos com metas definidas.
Nosso gerente é um dos dinossauros do negócio e do cliente. Ele está mais para um distribuidor geral de atividades do que um controlador. Porém, não temos ruídos de cliente chegando até os desenvolvedores (raras exceções onde são tarefas bem específicas), normalmente isso é filtrado por alguém com “mais tempo de casa”.
No fim das contas, creio que estou hoje inserido em uma equipe auto-gerenciável sim, apesar de outras equipes da mesma empresa não o serem.
Complementando, passei 1 ano e meio longe da empresa ajudando a formar uma startup. Equipe altamente auto-gerenciável e sem ruídos na comunicação, embora o cara da $$ cobrasse os prazos e as metas.
Enfim, acho que deu pra ter uma geral.
Em momento algum eu disse que não pode haver equipes auto-gerenciáveis, inclusive se lesse, veria que em momento algum neguei. Veja: "A verdade é que já existem equipes auto-gerenciáveis, porém o ambiente onde elas são aplicadas e foram testadas são ambientes controlados até então. " (retirado do seu quote no que escrevi).
Vou repetir mais uma vez meu ponto de vista. Creio que a generalização das coisas é que é ruim, toda generalização é ruim, e o que ocorre é que muitas vezes generalizamos a questão simplesmente porque nossa experiência é “limitada” (no sentido de que nossos ambientes antigos sempre foram iguais).
Vou ler de novo : “Sem falar que não existe cooperação onde existe hierarquia.”. Então podemos afirmar que nunca existiu colaboração, pois sempre houve hierarquia? (Minha mente é de programador, desculpe se não achei a nuance do que você disse).
Quotei algumas coisas que você escreveu, mas quando pensei experiências ruins, pensei no naomeencontro. Foi ele quem passou por 5 empresas péssimas e descarregou toda a sua raiva na área onde ele “não se encontrou”, que foi como essa discussão começou.
Abs []
Incrível cara, sério mesmo, não saia nunca dessa sua empresa e nem dessa sua equipe, pois ela representa uma % bem pequena de equipes de desenvolvimento de Software no país.
Quanto ao papel do seu gerente, ele é mais um gerente de vendas e rh do que um gerente de projetos.
Abs []
Então, eu acho que existe um problema cultural quanto a gerenciamento. Numa equipe, todos sabem quem faz ou quem deixa de fazer, o gerente não é um iluminado que consegue ter uma visão única do que está acontecendo, sempre quem está dentro do grupo sabe mais sobre o andamento do projeto do que um gerente centralizador de atividades. A questão é que o gerente é cobrado pelo andamento de um projeto e precisa repassar informações deste para os seus clientes e isso por si só já é um erro, porque o gerente é parte de um processo, não a chave dele, o gerente não pode ser responsável pelas metas do grupo. Em todas as empresas que eu trabalhei, os gerentes ficavam “vendidos” e desesperados para serem reportados, o que quase nunca acontecia, pois a equipe não tinha tempo de criar os relatórios, muitos menos essa cultura e nem regulamentos, fora isso, as informações passadas eram mascaradas muitas vezes por esses problemas. O fato é que não se envolve a equipe no processo de gerenciamento de projetos, sempre onde trabalhei era um gerente delegando um serviço, com um prazo limite e buscando atender apenas a solicitação sem enxergar o todo, e era o que acontecia, só que várias falhas eram vistas e negligenciadas, pois o prazo era curto e nossa única intenção era entregar a solicitação e o projeto. A consequência disso eram erros em todas as etapas e setores e em cada iteração aumentava-se o número de remendos, pois sempre buscou-se o menor prazo, ao invés do melhor produto.
Eu acho que a solução são equipes auto-gerenciáveis mesmo, todos sabem suas obrigações e todos tem o direito de se cobrar, e mais que isso, evoluir junto, quando você tem equipes trabalhando apenas por distribuição de tarefas, isso acaba gerando uma competição interna não sadia e que a longo prazo desgasta os funcionários. Não existe nada pior que um ambiente de trabalho ruim, cansa muito mais que um trabalho pesado em si. Fora isso, os créditos tendem a ser melhor distribuídos, pois a avaliação e o reconhecimento é da equipe não de um líder, isso faz muita diferença no dia a dia.
Não foi do modelo que discordei, mas do papel que ele atribuiu ao gerente, que e geralmente da secretaria ou do auxiliar administrativo do setor.
Mas mesmo nas equipes autogerenciaveis alguém assume o papel de gerência, mas com outros nomes. Líder técnico, coach, coordenador, analista de sistemas, etc. A necessidade ter ter alguém que coordena os trabalhos não desaparece.
Agora mesmo no caso do papel da gerência estar separado da liderança técnica limitar o cargo a alguém que se preocupa só se o escritório está limpo e se tem café e uma visão extremamente limitada. Eu realmente só posso lamentar de haver tantos desenvolvedores o que pensem assim. Claro que parte da culpa das próprias empresas, que escolhem e toleram maus gerentes as vezes por tempo demais.
A profissão e extremamente importante numa equipe, e um mau gerente pode realmente ser um algoz dentro da empresa. Mas a situação fica ainda pior se ao invés de entender o que ele faz e tentar melhorar a comunicação com ele, usamos de uma visão preconceituosa para taxar o cara de ignorante, inútil, ou achar que a profissão dele se resume a atividades medíocres.
[quote=adriano_si][quote=YvGa]
Equipes auto gerenciáveis são cada vez mais citadas na literatura sobre gestão de empresas, principalmente na nossa área… Mas ele existe e vem sendo discutido, então não se pode chamar de “Tanta besteira que não vale o trabalho responder”, algo que vem sendo profundamente discutido.
[/quote]
Concordo com você, porém se ler tudo o que o Viny escreveu em resposta ao amigo que descreveu essa imagem de gerente, em nenhum momento o Viny discute ou discorda dessa visão.
A verdade é que já existem equipes auto-gerenciáveis, porém o ambiente onde elas são aplicadas e foram testadas são ambientes controlados até então.
Tenho a mais absoluta certeza que essa visão de gerente que controla ponto está mais do que ultrapassada e é o tipo de profissional que mais atrapalha do que ajuda, mas em certos ambientes, precisa de uma(s) figura(s) centralizadora(s) que responde ao cliente e facilita a comunicação com a equipe, onde o trabalho e as decisões são distribuídas, mas o canal de comunicação é único.
A verdade é que o amigo teve experiências ruins em relação à gerentes e está colocando uma opinião burra (pra mim toda generalização é burra) sobre o assunto.
No ambiente que trabalho, hoje, ainda não é possível haver equipe auto-gerenciável por alguns fatores, dos quais os principais são:
1 - Maturidade da equipe: tanto de negócio quanto técnico, pois equipes auto-gerenciáveis precisam de um nível de maturidade alto, e isso só é alcançado hoje com algum nível de experiência.
2 - Exigência do cliente para fins de facilidade de comunicação: não adianta, o cliente quer e pronto. Facilita na comunicação com a equipe e na comunicação com a sede, pois somos parte da empresa dentro de um cliente.
No fim das contas, acho que tudo se encaminha para que equipes do futuro sejam auto-gerenciáveis, mas hoje, no país em que vivemos e na “selva” de ambientes que ainda habitamos, fica complicado resumir a função de um gerente como “o cara que fica controlando o ponto dos subordinados”.
Se o amigão teve somente essa experiência na vida dele (e eu acredito, pois a maioria esmagadora é assim), isso é um problema pessoal, mas repito, toda generalização é burra e precisamos ter cuidados ao avaliar os cenários.
Por exemplo, o amigão disse o seguinte
Mais um problema pessoal que foi generalizado. Hierarquia existe e sempre existirá. Posso daqui há 20 anos admitir que falei bobagem, mas não está nem no horizonte um mundo sem hierarquias.
E o Viny, pra finalizar, disse o seguinte
[quote]Eu estou falando de “carreira” e não de “uma empresa que trabalhei”. É lógico que existem distorções, mas a competência é um fator fundamental para que, a evolução de sua carreira seja de sucesso.
Você pode entrar numa empresa cheia de distorções, mas se vc for um cara bom, logo um colega sai para uma empresa melhor e te indica. Ser um cara bom ajuda também em movimentações entre setores, no caso de empresas muito grandes.[/quote]
Não sou advogado dele, mas é somente pra fortalecer meu ponto de vista. No fim das contas ainda acho que o problema maior do amigão é pessoal mesmo por não ter se achado dentro da área. Sendo assim, tanto faz ele trabalhar com ou sem hierarquias, pois dessa forma dificilmente se encaixará em equipes auto-gerenciáveis.
PS: Não sou gerente, sou um Desenvolvedor que trabalho com um e respeitando hierarquia (antes que queiram atribuir minha opinião ao fato de eu ser um gerente).
PS 2: Posso não concordar com a forma que o Viny respondeu, mas sinceramente entendo o lado dele.
Enfim :-[/quote]
Adriano, o gerente na empresa serve, entre outras poucas coisas, para conduzir e organizar uma equipe para que esta obtenha os resultados desejados, o que não é errado, mas enfim, experiência não tem nada a ver com maturidade, pode ser relacionada com conhecimento, mas não responsabilidade e acredito seriamente que não é necessário um “chefe” para que alguém faça o seu melhor em qualquer serviço.
O fato de você citar que a maioria esmagadora dos empregados na nossa área passam por esses problemas discutidos anteriormente, já deixa claro que nossa área precisa rever muitas coisas urgentemente, e o fato de você, eu ou qualquer outra pessoa ter conseguido “se livrar” desses problemas, isso não torna a área boa, pelo contrário, apenas prova que a área está uma droga.
[quote=ViniGodoy][quote=YvGa]
Equipes auto gerenciáveis são cada vez mais citadas na literatura sobre gestão de empresas, principalmente na nossa área. E com equipes gerenciáveis aboliu-se o conceito de gerente de projeto, pelo menos o modelo mais famoso de gerente de projeto que é o cara que cobra prazos, cuida de horários e define tarefas.
Essa figura de gerente de projetos, segundo a literatura, deve ser extinta, o que tendo a concordar. Esse cara é inútil, mais que inútil, atrapalha. Principalmente dando pitaco no desenvolvimento de software.
Isso é o que diz parte da literatura e alguns estudos que vem sendo publicados.
Estou falando de estudos, com os quais tendo a concordar e de teorias porque, sinceramente, não conheço esse modelo na prática. Mas ele existe e vem sendo discutido, então não se pode chamar de “Tanta besteira que não vale o trabalho responder”, algo que vem sendo profundamente discutido.
[/quote]
Não foi do modelo que discordei, mas do papel que ele atribuiu ao gerente, que e geralmente da secretaria ou do auxiliar administrativo do setor.
Mas mesmo nas equipes autogerenciaveis alguém assume o papel de gerência, mas com outros nomes. Líder técnico, coach, coordenador, analista de sistemas, etc. A necessidade ter ter alguém que coordena os trabalhos não desaparece.
Agora mesmo no caso do papel da gerência estar separado da liderança técnica limitar o cargo a alguém que se preocupa só se o escritório está limpo e se tem café e uma visão extremamente limitada. Eu realmente só posso lamentar de haver tantos desenvolvedores o que pensem assim. Claro que parte da culpa das próprias empresas, que escolhem e toleram maus gerentes as vezes por tempo demais.
A profissão e extremamente importante numa equipe, e um mau gerente pode realmente ser um algoz dentro da empresa. Mas a situação fica ainda pior se ao invés de entender o que ele faz e tentar melhorar a comunicação com ele, usamos de uma visão preconceituosa para taxar o cara de ignorante, inútil, ou achar que a profissão dele se resume a atividades medíocres.[/quote]
Auto-gerenciamento é diferente da forma tradicional de gerenciamento, primeiro porque o gerente não é imposto, é escolhido pela própria equipe, segundo porque é transitório, não necessariamente o líder da equipe em um projeto vá ser o mesmo de outro projeto e terceiro porque o “gerente” está sendo avaliado também pelos subordinados, a hierarquia até pode existir, mas é algo bem menos rígido do que em uma organização tradicional.
A maioria das empresas usam gerentes como cargos de confiança, assim vale a velha lei da autoridade, manda quem pode, obedece quem tem juízo, eu realmente não acho que esse tipo de atitude seja algo construtivo ou produtivo, acredito até que esse seja um dos principais motivos da alta rotatividade de funcionários nas empresas de TI, nem tanto pelas ofertas de trabalho como tanto se fala, mas sim o péssimo ambiente de trabalho que os funcionários tem vivido dentro destas empresas, é uma impressão minha, eu não tenho como provar, posso estar errado, mas é o que mais escuto falar.
[quote=naomeencontro]Auto-gerenciamento é diferente da forma tradicional de gerenciamento, primeiro porque o gerente não é imposto, é escolhido pela própria equipe, segundo porque é transitório, não necessariamente o líder da equipe em um projeto vá ser o mesmo de outro projeto e terceiro porque o “gerente” está sendo avaliado também pelos subordinados, a hierarquia até pode existir, mas é algo bem menos rígido do que em uma organização tradicional.
A maioria das empresas usam gerentes como cargos de confiança, assim vale a velha lei da autoridade, manda quem pode, obedece quem tem juízo, eu realmente não acho que esse tipo de atitude seja algo construtivo ou produtivo, acredito até que esse seja um dos principais motivos da alta rotatividade de funcionários nas empresas de TI, nem tanto pelas ofertas de trabalho como tanto se fala, mas sim o péssimo ambiente de trabalho que os funcionários tem vivido dentro destas empresas, é uma impressão minha, eu não tenho como provar, posso estar errado, mas é o que mais escuto falar.[/quote]
Acho que o problema não está na figura do gerente em si, mas no fato de que muitos deles ainda pensam que trabalhar com software é como trabalhar numa linha de produção. A informática é relativamente nova, e não é de surpreender que a própria área de administração ainda tenha que aprender na hora de liderar uma equipe de software.
Já há, entretanto, bastante literatura na administração falando na nova tendência e de equipes auto-gerenciáveis - e elas não se restringem a software. Sobre como gerir projetos quando seus funcionários tem empowerment. E de como é diferente quando cada membro da sua equipe é maduro para tomar decisões. Ter uma equipe de alto-padrão, com funcionários de nível superior, alta instrução é uma consequencia moderna e há mesmo dificuldades para os antigos gestores se adaptarem a isso. Seja em informática, publicidade, engenharia ou qualquer outro lugar que tenha um time de alto nível. Isso muda a dinâmica de ser gerente, mas não exclui nem o papel, nem sua importância. Na verdade, a necessidade de gerentes competentes é crescente.
Nesse contexto, a disciplina militar é um problema para a gerencia de software. Eu nunca gostei de trabalhar em equipes onde os funcionários são submissos e obedecem a coordenação técnica simplesmente para não serem demitidos. Quando se adota uma gestão mais focada em acreditar nas pessoas e conhecer seu time, na verdade, o cara submisso e que tem medo de tomar decisões e assumir responsabilidades se torna um problema.
[quote=ViniGodoy][quote=naomeencontro]Auto-gerenciamento é diferente da forma tradicional de gerenciamento, primeiro porque o gerente não é imposto, é escolhido pela própria equipe, segundo porque é transitório, não necessariamente o líder da equipe em um projeto vá ser o mesmo de outro projeto e terceiro porque o “gerente” está sendo avaliado também pelos subordinados, a hierarquia até pode existir, mas é algo bem menos rígido do que em uma organização tradicional.
A maioria das empresas usam gerentes como cargos de confiança, assim vale a velha lei da autoridade, manda quem pode, obedece quem tem juízo, eu realmente não acho que esse tipo de atitude seja algo construtivo ou produtivo, acredito até que esse seja um dos principais motivos da alta rotatividade de funcionários nas empresas de TI, nem tanto pelas ofertas de trabalho como tanto se fala, mas sim o péssimo ambiente de trabalho que os funcionários tem vivido dentro destas empresas, é uma impressão minha, eu não tenho como provar, posso estar errado, mas é o que mais escuto falar.[/quote]
Acho que o problema não está na figura do gerente em si, mas no fato de que muitos deles ainda pensam que trabalhar com software é como trabalhar numa linha de produção. A informática é relativamente nova, e não é de surpreender que a própria área de administração ainda tenha que aprender na hora de liderar uma equipe de software.
Já há, entretanto, bastante literatura na administração falando na nova tendência e de equipes auto-gerenciáveis - e elas não se restringem a software. Sobre como gerir projetos quando seus funcionários tem empowerment. E de como é diferente quando cada membro da sua equipe é maduro para tomar decisões. Ter uma equipe de alto-padrão, com funcionários de nível superior, alta instrução é uma consequencia moderna e há mesmo dificuldades para os antigos gestores se adaptarem a isso. Seja em informática, publicidade, engenharia ou qualquer outro lugar que tenha um time de alto nível. Isso muda a dinâmica de ser gerente, mas não exclui nem o papel, nem sua importância. Na verdade, a necessidade de gerentes competentes é crescente.
Nesse contexto, a disciplina militar é um problema para a gerencia de software. Eu nunca gostei de trabalhar em equipes onde os funcionários são submissos e obedecem a coordenação técnica simplesmente para não serem demitidos. Quando se adota uma gestão mais focada em acreditar nas pessoas e conhecer seu time, na verdade, o cara submisso e que tem medo de tomar decisões e assumir responsabilidades se torna um problema.[/quote]
Eu acho que de certa forma esse perfil de gerente é mais uma consequência do que outra coisa, eu vejo assim, as empresas dependem da venda de sistemas para viver, e para conseguir essas vendas muitas vezes é necessário reduzir o custo no desenvolvimento.
O ponto é que temos dificuldades gigantescas para determinar prazos e custos de um projeto e sempre que possível devemos vender por hora o sistema, quando temos um cliente que tem conhecimento de como é a criação de um sistema, acaba sendo mais fácil negociar, porém, essa é uma minoria.
Todo mundo que compra algo quer saber o quanto vai pagar e quanto tempo vai demorar para receber o produto que comprou, é a forma tradicional que sempre negociou-se qualquer produto. Quem está envolvido diretamente no processo de desenvolvimento até entende isso, mas quem não está, acha que isso é uma forma de aumentar o custo. E esse tipo de cobrança acaba causando uma confusão sobre comprometimento e forma de trabalho. As empresas precisam passar um custo para o cliente e um prazo, e para cumprir com o combinado que as empresas acabam contratando os leões de chácara para atender prazos irreais e maximizar o lucro do projeto, criando um estado de pressão constante na equipe, reduzindo a qualidade do serviço, criando-se o tal de good enough.
Acho que enquanto nossas metodologias forem incompletas como são hoje, sofreremos constantemente esse tipo de pressão, é pura questão de mercado o que ocorre e que como não existe nenhuma regulamentação de responsabilidade técnica, as empresas podem continuar a baixar a qualidade de seus projetos sem preocupar-se com o resultado final, pois sempre haverá a desculpa que o sistema está incompleto e que mudanças são necessárias, sendo assim, o cliente vê-se obrigado em algum momento cortar o vínculo com o contratado, mesmo o sistema estando “incompleto”.
[quote=naomeencontro]Eu acho que de certa forma esse perfil de gerente é mais uma consequência do que outra coisa, eu vejo assim, as empresas dependem da venda de sistemas para viver, e para conseguir essas vendas muitas vezes é necessário reduzir o custo no desenvolvimento.
O ponto é que temos dificuldades gigantescas para determinar prazos e custos de um projeto e sempre que possível devemos vender por hora o sistema, quando temos um cliente que tem conhecimento de como é a criação de um sistema, acaba sendo mais fácil negociar, porém, essa é uma minoria.
Todo mundo que compra algo quer saber o quanto vai pagar e quanto tempo vai demorar para receber o produto que comprou, é a forma tradicional que sempre negociou-se qualquer produto. Quem está envolvido diretamente no processo de desenvolvimento até entende isso, mas quem não está, acha que isso é uma forma de aumentar o custo. E esse tipo de cobrança acaba causando uma confusão sobre comprometimento e forma de trabalho. As empresas precisam passar um custo para o cliente e um prazo, e para cumprir com o combinado que as empresas acabam contratando os leões de chácara para atender prazos irreais e maximizar o lucro do projeto, criando um estado de pressão constante na equipe, reduzindo a qualidade do serviço, criando-se o tal de good enough.
Acho que enquanto nossas metodologias forem incompletas como são hoje, sofreremos constantemente esse tipo de pressão, é pura questão de mercado o que ocorre e que como não existe nenhuma regulamentação de responsabilidade técnica, as empresas podem continuar a baixar a qualidade de seus projetos sem preocupar-se com o resultado final, pois sempre haverá a desculpa que o sistema está incompleto e que mudanças são necessárias, sendo assim, o cliente vê-se obrigado em algum momento cortar o vínculo com o contratado, mesmo o sistema estando “incompleto”.[/quote]
Eu sempre defendi que uma das razões pela qual a informática ainda se dá muito mal com os administradores é que um não quer, e não faz questão de aprender a lingua do outro. O pessoal de administração até tem tentado, mas a contra-partida na informática, o esforço é mínimo. É só ver parte das opiniões aqui, que claramente não fazem idéia do que um gerente faz, das pressões que sofre e, de maneira geral, chegam a julga-lo desnecessário - não estou só falando do gerente técnico de projeto, mas da figura do gerente de maneira geral.
Eu concordo com você em quase tudo que disse nas suas últimas colocações. No fato das nossas próprias estimativas serem muito irreais e de nossos processos ainda serem extremamente falhos. Mas não acho que uma regulamentação resolveria nada, nem que seja necessária, muito menos benéfica.
Vale ressaltar também que muitas vezes o “leão de chácara” pressiona para os profissionais cumprirem os prazos que eles mesmos deram - e que erraram grosseiramente. Já muitos profissionais de informática (e eu já fui um deles) se empolgarem e, deliberadamente, aumentarem os requisitos do software - uma prática tão comum que há vários capítulos evangelizando contra isso no início de todo livro ágil. E não estou nem entrando no mérito também da má preparação das faculdades, e dos erros grosseiros que muitos profissionais cometem por pura inexperiência (para não dizer incompetência).
O que temos de mais metodológico, que é a UML e os processos não ágeis, chega a ser irreal e patético. Envolve um esforço grande de estimativa (que por mais que os defensores queiram, não pode ser cobrado e por isso nunca é feito), seguido de um desenvolvimento quase em cascata e de péssimos resultados.
A saída ágil, apesar de mais precisa, também falha ao propor ausência de cronograma ou prazos de longo prazo, o que soa irreal para qualquer um que vai gastar o próprio dinheiro. Imagine você ir comprar um carro, e o vendedor dizer “vai pagando aí pelas partes, que um dia seu carro vai ficar pronto”, e se recusar a dizer quantas iterações ou qual vai ser o custo total da brincadeira. Embora eu ache que o ágil seja realmente mais seguro e correto, e saiba que na prática um software é muito diferente de um carro, creio que ainda precisamos equacionar a questão da expectativa de longo prazo e as previsões de investimento. Eu passei o último ano inteiro tentando - e essa é uma tarefa MUITO difícil.
Não estou dizendo que os gerentes fazem tudo certo. Há muitas empresas ruins, onde o comercial inventa prazos e funcionalidades, onde os gerentes são realmente ignorantes e leões de chácara (e devemos fugir de empresas assim). Há também o fator humano, ou seja, o gerente também é passível de erros por inexperiência ou por desconhecimento. E há a imprecisão natural da profissão - que é bem mais distante do preto no branco da área técnica e trabalha com variáveis bem menos conhecidas.
Agora, não acho que a solução também esteja na gente se fechar no nosso mundinho, e achar que seremos uma área isolada da administração e que poderemos desenvolver projetos sem nos preocupar com custos, prazos, riscos, planos de contingência, metas, indicadores, performance, etc. Que nossas equipes serão 100% auto-gerenciadas e independentes do resto da empresa. Auto-gerenciamento técnico é uma coisa, auto-gerenciamento total, é outra e utópica.
[quote=ViniGodoy]Eu sempre defendi que uma das razões pela qual a informática ainda se dá muito mal com os administradores é que um não quer, e não faz questão de aprender a lingua do outro. O pessoal de administração até tem tentado, mas a contra-partida na informática, o esforço é mínimo. É só ver parte das opiniões aqui, que claramente não fazem idéia do que um gerente faz, das pressões que sofre e, de maneira geral, chegam a julga-lo desnecessário - não estou só falando do gerente técnico de projeto, mas da figura do gerente de maneira geral.
Eu concordo com você em quase tudo que disse nas suas últimas colocações. No fato das nossas próprias estimativas serem muito irreais e de nossos processos ainda serem extremamente falhos. Mas não acho que uma regulamentação resolveria nada, nem que seja necessária, muito menos benéfica.
Vale ressaltar também que muitas vezes o “leão de chácara” pressiona para os profissionais cumprirem os prazos que eles mesmos deram - e que erraram grosseiramente. Já muitos profissionais de informática (e eu já fui um deles) se empolgarem e, deliberadamente, aumentarem os requisitos do software - uma prática tão comum que há vários capítulos evangelizando contra isso no início de todo livro ágil. E não estou nem entrando no mérito também da má preparação das faculdades, e dos erros grosseiros que muitos profissionais cometem por pura inexperiência (para não dizer incompetência).
O que temos de mais metodológico, que é a UML e os processos não ágeis, chega a ser irreal e patético. Envolve um esforço grande de estimativa (que por mais que os defensores queiram, não pode ser cobrado e por isso nunca é feito), seguido de um desenvolvimento quase em cascata e de péssimos resultados.
A saída ágil, apesar de mais precisa, também falha ao propor ausência de cronograma ou prazos de longo prazo, o que soa irreal para qualquer um que vai gastar o próprio dinheiro. Imagine você ir comprar um carro, e o vendedor dizer “vai pagando aí pelas partes, que um dia seu carro vai ficar pronto”, e se recusar a dizer quantas iterações ou qual vai ser o custo total da brincadeira. Embora eu ache que o ágil seja realmente mais seguro e correto, e saiba que na prática um software é muito diferente de um carro, creio que ainda precisamos equacionar a questão da expectativa de longo prazo e as previsões de investimento. Eu passei o último ano inteiro tentando - e essa é uma tarefa MUITO difícil.
Não estou dizendo que os gerentes fazem tudo certo. Há muitas empresas ruins, onde o comercial inventa prazos e funcionalidades, onde os gerentes são realmente ignorantes e leões de chácara (e devemos fugir de empresas assim). Há também o fator humano, ou seja, o gerente também é passível de erros por inexperiência ou por desconhecimento. E há a imprecisão natural da profissão - que é bem mais distante do preto no branco da área técnica e trabalha com variáveis bem menos conhecidas.
Agora, não acho que a solução também esteja na gente se fechar no nosso mundinho, e achar que seremos uma área isolada da administração e que poderemos desenvolver projetos sem nos preocupar com custos, prazos, riscos, planos de contingência, metas, indicadores, performance, etc. Que nossas equipes serão 100% auto-gerenciadas e independentes do resto da empresa. Auto-gerenciamento técnico é uma coisa, auto-gerenciamento total, é outra e utópica.
[/quote]
Esse é o motivo porque acho que nossa área é uma droga…
Administração e TI tem focos diferentes, um é voltado para soluções limitadas, o outro pensa em metas e resultados. A questão é que as organizações tendem em pensar em algo como hora trabalhada/pontos de função em que cada hora um profissional é capaz de criar x pontos de função. Essa é uma visão de administração, mas não de TI, simplesmente porque ela não é real. O problema não está na administração das empresas, está na nossa área. Nós não somos capazes de produzir estimativas e orçamentos confiáveis e por causa disso nossa área sofre uma descrença, o resultado disso é que nossos gerentes geralmente são profissionais que não sabem a diferença entre um mouse e um teclado (salvo exceções em tipos de serviços muito específicos, ou empresas com maior grau de conhecimento), porém sabem como maximizar a produtividade de sua equipe a troco da qualidade. Ele não é capaz de produzir uma estimativa, mas reduz o prejuízo do projeto e quem paga são os profissionais que apenas discutem formas de implantação (aka Go Horse).
Para mim, tanto os métodos ágeis quanto os tradicionais já provaram não funcionar, para mim um é acadêmico demais e o outro caro e não funcional, é impossível planejar um sistema inteiro para dar o preço dele como é feito em engenharia.
Eu entendo 100% o que você quer dizer, mas só vou fazer um parênteses quanto a parte que você fala que o próprio funcionário estimou o prazo e está sendo cobrado por ele, o trabalho na área de TI é 100% tecnológico e de certa forma, de pesquisa, sempre haverá essa variação de prazo e isso tem que ser entendido, eu já vi muita gente tomar esse tipo de cobrança, eu mesmo já tomei, mas não concordo, as dificuldades decorrentes do cálculo de prazo são relativos as novidades encontradas em cada etapa de um projeto, existem poucos erros de cálculos em domínio conhecido e principalmente, é necessária uma análise profunda do momento em que o prazo de uma demanda foi passado, a pressão exercida para passar o prazo e tantos outros fatores…
O problema é que trabalhamos com conceitos intangíveis para entregarmos um sistema rodando. Sempre haverá pressão enquanto não conhecermos a melhor a forma com a qual devemos criar estes. Recentemente, muitas empresas migraram de sistemas desktop para sistemas web, eu conheço as vantagens tecnológicas, mas não conheço as vantagens de negócio. Eu acho que precisamos repensar seriamente o que estamos desenvolvendo e até que ponto é útil e funcional o que desenvolvemos.
A questão da regulamentação não solucionaria hoje o problema que temos em relação a especificações, que convenhamos, é nosso trauma, começamos a fazer o sistema sem saber como ele vai ficar quando estiver pronto e por isso é impossível calcular o esforço e consequentemente o tempo e o custo, tudo que fazemos é estimar baseado na nossa experiência, as vezes mais embasado, as vezes mais estimado. Só que a questão vai muito mais longe do que isso, se existisse hipoteticamente uma documentação perfeita, em que todos os detalhes fossem cobertos, ainda sim existiriam vários problemas de implantação, pela falta de conhecimento nas tecnologias que estão sendo utilizadas, e isso decorre principalmente da mudança constante na nossa plataforma de desenvolvimento. O ponto é que quando um cliente contrata uma empresa, ele geralmente não sabe qual tecnologia será usada e mesmo que soubesse, ele não consegue avaliar se quem foi contratado está apto ou não para executar um determinado tipo de serviço. A responsabilidade técnica é uma defesa para o cliente, não é para os profissionais de TI, é injusto dividirmos a responsabilidade do sistema que criamos com ele, o cliente é apenas um consumidor e nada mais, e assim que deve ser visto.
Quando eu desenvolvo um sistema para terceiros, eu limito com o cliente as tecnologias que serão usadas, mesmo sabendo que o sistema pode precisar de mais recursos, eu acredito seriamente que é melhor ter domínio de algo limitado, do que utilizar erroneamente algo poderoso. E isso varia de cliente para cliente, quando tenho um cliente com conhecimento maior, eu utilizo mais recursos, quando não, utilizo o mínimo possível, pois no futuro, caso eu não esteja mais trabalhando para ele, o cliente pode ter dificuldades de manter o sistema, devido a mão de obra que ele não tem como avaliar.
Se existisse alguma forma de tornar obrigatória a certificação de uma empresa e habilitá-la para trabalhar apenas com o que suas certificações permitem, acredito que muitos erros seriam evitados e consequentemente, haveria um domínio muito maior do que está sendo desenvolvido. Essa é a forma que eu regulamentaria algo tão dinâmico quanto TI.
Eu entendo a necessidade de alguém para manter a visão geral da equipe no problema sendo resolvido. Manter o foco, ter certeza de que todo mundo entendeu tudo do mesmo jeito e está caminhando na mesma direção. Pra isso um líder técnico seria suficiente, não precisando de uma pessoa exclusivamente pra isso.
Entendo também que é necessário alguém para se comunicar com aqueles que estão esperando o resultado do projeto, sejam diretores, investidores, clientes. Como diz Jurgen Appelo em Management 3.0, se as equipes podem se auto-gerenciar, a expectativa daqueles que aguardam o resultado não podem. E aqui sim é necessário alguém para se comunicar com eles sobre questões não técnicas sem que atrapalhe o desenvolvimento.
Quando eu falo que os gerentes são inúteis, eu falo desses que tem como responsabilidade “garantir que os prazos sejam cumpridos”, ainda que eles sejam fofos e legais e almocem com os programadores.
A empresa precisa de boa comunicação entre seus setores, precisa de gente que tome decisões estratégicas, precisa de alguém com uma visão do todo e com capacidade pra fazer ajustes nas partes. Se é isso que vocês querem de um gerente eu concordo com um.
Agora, um gerente pra ser a “cara” da equipe, como uma secretária de luxo, com posição hierárquica superior, que só preenche planilha, normalmente com dados estimados e imprecisos. Alguém cuja única função é levar mijada grossa da diretoria que sabe que não pode falar daquele jeito com os programadores porque se eles saem são difíceis de ser repostos. Alguém que recebe salários de 5 dígitos só pra engolir sapo e cuja principal habilidade deve ser “saber suportar pressão”, ou seja, levar porrada e ficar quieto pra não perder o salário de 5 dígitos.
Se são esses os gerentes que vocês defendem, ainda que sejam queridos, eu continuo com a opinião de que são inúteis para qualquer empresa.
[quote=YvGa]
Agora, um gerente pra ser a “cara” da equipe, como uma secretária de luxo, com posição hierárquica superior, que só preenche planilha, normalmente com dados estimados e imprecisos. Alguém cuja única função é levar mijada grossa da diretoria que sabe que não pode falar daquele jeito com os programadores porque se eles saem são difíceis de ser repostos. Alguém que recebe salários de 5 dígitos só pra engolir sapo e cuja principal habilidade deve ser “saber suportar pressão”, ou seja, levar porrada e ficar quieto pra não perder o salário de 5 dígitos.
Se são esses os gerentes que vocês defendem, ainda que sejam queridos, eu continuo com a opinião de que são inúteis para qualquer empresa.[/quote]
Era o que estava falando. Banalizar a profissão de gerente, chama-lo de secretária de luxo, é miopia. Ainda que o gerente seja só administrativo, há muitas coisas na profissão. Desde as reuniões - que envolvem tomada de decisão, visão estratégica e habilidade de negociação - até acompanhamento de metas e planejamento. Um bom gerente pode fazer outros departamentos da empresa trabalharem a seu favor, conseguir parcerias de tecnologia e pode aliviar muito as dificuldades do dia-a-dia. Pode projetar a equipe, conseguir promoções.
Vocês também estão pensando só nas situações positivas. O bom gerente também é necessário para evitar as coisas ruins. É ele que lida com cortes, quando são necessários, que pensa em avaliação de pessoal, que dá conta de conflitos e lida com as finanças do setor. É ele que defende a equipe frente a direção e que consegue traduzir o tecniquês na linguagem que os diretores da empresa, donos do negócio, entendem - coisa que o pessoal de TI ainda é muito, mas muito, ruim.
Na questão das metas, é ele também que gasta tempo analisando números e cruzando dados para entender porque elas não estão sendo cumpridas. E, quando o problema vem de outros setores, comprova isso para os diretores, propõe mudanças de processos, etc.
Não menosprezem a atividade, só porque ela parece fácil. Participar de reunião e dar a cara a tapa na diretoria, respondendo por todo um time não é uma atividade fácil. E, se feita da forma errada, pode representar cortes de verbas e de pessoal.
Eu concordo com o naomeencontro que esse tipo de visão dificulta muito a vida da TI e que a falha também é de TI - não exclusivamente, mas em grande parte.
Sobre a regulamentação: não vou continuar a discussão pois ela é outra. Eu já escrevi um post longo sobre isso aqui.
Sobre a área ser ruim, também discordo. Eu adoro tecnologia, gosto de estar um passo no futuro. Há muitas empresas boas, com gerencias boas. Há projetos muito interessantes e, mesmo com as dificuldades (que existem em QUALQUER área), é bastante empolgante trabalhar com computadores. É legal também conhecer vários modelos de negócio, de várias empresas diferentes. Eu mesmo já atuei no mercado de engenharia, educacional, games e agora estou na gestão de documentos. Hoje estou numa boa empresa, com uma boa equipe.
Bom, mas já cansei de repetir as mesmas coisas aqui e, logicamente, um não vai fazer o outro mudar de opinião. Por isso, vou me retirar dessa discussão, que já rendeu o bastante, com visões bastante interessantes.
[quote=YvGa]Eu entendo a necessidade de alguém para manter a visão geral da equipe no problema sendo resolvido. Manter o foco, ter certeza de que todo mundo entendeu tudo do mesmo jeito e está caminhando na mesma direção. Pra isso um líder técnico seria suficiente, não precisando de uma pessoa exclusivamente pra isso.
Entendo também que é necessário alguém para se comunicar com aqueles que estão esperando o resultado do projeto, sejam diretores, investidores, clientes. Como diz Jurgen Appelo em Management 3.0, se as equipes podem se auto-gerenciar, a expectativa daqueles que aguardam o resultado não podem. E aqui sim é necessário alguém para se comunicar com eles sobre questões não técnicas sem que atrapalhe o desenvolvimento.
Quando eu falo que os gerentes são inúteis, eu falo desses que tem como responsabilidade “garantir que os prazos sejam cumpridos”, ainda que eles sejam fofos e legais e almocem com os programadores.
A empresa precisa de boa comunicação entre seus setores, precisa de gente que tome decisões estratégicas, precisa de alguém com uma visão do todo e com capacidade pra fazer ajustes nas partes. Se é isso que vocês querem de um gerente eu concordo com um.
Agora, um gerente pra ser a “cara” da equipe, como uma secretária de luxo, com posição hierárquica superior, que só preenche planilha, normalmente com dados estimados e imprecisos. Alguém cuja única função é levar mijada grossa da diretoria que sabe que não pode falar daquele jeito com os programadores porque se eles saem são difíceis de ser repostos. Alguém que recebe salários de 5 dígitos só pra engolir sapo e cuja principal habilidade deve ser “saber suportar pressão”, ou seja, levar porrada e ficar quieto pra não perder o salário de 5 dígitos.
Se são esses os gerentes que vocês defendem, ainda que sejam queridos, eu continuo com a opinião de que são inúteis para qualquer empresa.[/quote]
Assim, eu não defendo isso, eu só acho que isso é uma consequência da forma com a qual trabalhamos, para mim é uma distorção na verdade. Do jeito que está hoje nós não conseguimos definir nem preço, muito menos prazo, sempre acabamos estimando e quando acontecem os atrasos ou estouro no custo, o resultado será sempre o mesmo, uma cobrança para honrar o compromisso, mas esse compromisso não foi assumido pela equipe, que na verdade não tem como assumir porque não existe uma forma confiável de dizer, mas quem comprar precisa saber, no final, mesmo que a equipe seja auto-gerida, ela sofrerá o mesmo tipo de cobrança sempre, que é a do prazo e do custo. Não importa quem vá cobrar, os motivos das cobranças serão sempre os mesmos, independente do que for feito.
Pelo que vi está tendo um conflito entre tipos de empresa, uma startup com 1-2 projetos que são os produtos core de empresa precisam de um nível de gerenciamento menor pois é bem menos dinamico que uma empresa com dezenas ou centenas de projetos.
Outra coisa não ter um GP/lider não significa que sua equipe é auto-gerenciavel, isto é uma denomiação a uma equipe que consegue obter controle, organização e performance com uma supervisão reduzida, isto não é algo facil de alcançar como simplesmente mandar o GP embora, é preciso conseguir motivacionar e conscientizar a equipe inteira de suas funções e responsabilidades e fazer elas performarem do mesmo jeito como que em uma equipe com um GP.
Em equipes auto-gerenciaveis AINDA tem a necessidade de um GP/lider/etc só que este terá mais confiança e dará mais liberdade para a equipe, dando mais espaço para ele realizar as outras funções dele, negociação, comunicação, organização, etc, são skills totalmente diferentes de um desenvolvedor e que não fazem parte do seu escopo de trabalho.
Concordo com o ViniGodoy no ponto que há muito conflito por falta de visão de ambos os lados, atualmente estou nos 2 mundos, desenvolvo e faço pós em GP na USP e isso abre muito a cabeça e muda sua visão de como a empresa funciona.
[quote=naomeencontro]…e acredito seriamente que não é necessário um “chefe” para que alguém faça o seu melhor em qualquer serviço.
[/quote]
Nem eu, em momento algum escrevi isso.
O fato de a esmagadora maioria dos empregados passarem por isso têm muito mais a ver com o fato de que nossa área nasceu ontem e de acharmos que tudo de errado acontece aqui enquanto contadores, administradores e até mesmo engenheiros reclamam de suas áreas. Talvez menos, mas reclamam, e olha que são áreas até consolidadas.
[quote=naomeencontro]
Assim, eu não defendo isso, eu só acho que isso é uma consequência da forma com a qual trabalhamos, para mim é uma distorção na verdade. Do jeito que está hoje nós não conseguimos definir nem preço, muito menos prazo, sempre acabamos estimando e quando acontecem os atrasos ou estouro no custo, o resultado será sempre o mesmo, uma cobrança para honrar o compromisso, mas esse compromisso não foi assumido pela equipe, que na verdade não tem como assumir porque não existe uma forma confiável de dizer, mas quem comprar precisa saber, no final, mesmo que a equipe seja ágil, ela sofrerá o mesmo tipo de cobrança sempre, que é a do prazo e do custo. Não importa quem vá cobrar, os motivos das cobranças serão sempre os mesmos, independente do que for feito.[/quote]
Equipes auto-gerenciáveis não colocam um preço no número de horas de trabalho que um programador leva pra completar determinada funcionalidade que alguém achou que deveria existir, mas no valor real que aquela funcionalidade traz em termos de benefícios para um usuário.
Concordo que é uma mudança na forma como trabalhamos, por isso não tem nada a ver com agile, que é apenas mais do mesmo.