Dia a dia de um gerente de TI

O Gerente precisa entender bem de programação??

2010-09-04T15:34:00.000-07:00

Esta pergunta foi feita num comentário do último post. É uma pergunta recorrente, mas que sempre rende muita discussão.
Não acredito que para ser um bom gerente de TI precise necessariamente ser um expert em programação. Diga-se de passagem, esta idéia se aplica não só a TI mas a outros ramos também.
Um gerente que não tenha conhecimentos avançados de informática pode conduzir um projeto na área de TI. Claro que para isso terá que se apoiar (confiar) em membros do time que possuam conhecimento para realizar determinadas atividades (que exigem conhecimento técnico específico). Aí é onde residem algumas das habilidades requeridas para um bom Gerente: identificar as potencialidades de sua equipe, fazer com que estes potenciais sejam aproveitados de maneira mais eficaz, por exemplo.
A um dito popular na área que diz: o importante não é saber mas sim, saber o telefone de quem sabe.

Não estou aqui desprezando o conhecimento adquirido ao longo de uma vida por muitos gerentes. Muitos deles constroem uma carreira passando por programação, passando por análise e se tornam gerentes. Acredito que o conhecimento em programação, análise, arquitetura, etc. ajuda muito ao gerente a exercer seu papel. Pra começar o gerente falará a mesma língua diminuindo assim a chance de haver mal entendidos (comunicação não é tudo, mas é 100%.).
Conhecendo programação, por exemplo, o gerente poderá, caso deseje, contestar determinados prazos dados por seus desenvolvedores. Questionar também a solução apresentada. Aqui cabe um alerta: Há que se ter muito cuidado para não investir muito tempo em tarefas que não são suas enquanto gerente. Ou seja, o Gerente gerencia, o programador programa e assim por diante.
Outra vantagem é que o conhecimento técnico ajudará a tomar a decisão de quem confiar para delegar atividades importantes.

Até Breve

O manual dos nuncas de Max Gehringer

2009-05-19T13:36:00.000-07:00

Estamos de volta!

Achei muito bom o podcast do Max Gehringer sobre gerência de projetos e decidi fazer comentários a respeito (quem sou eu rsrsrsrs).

A história narrada era mais ou menos assim:

Uma empresa com muitos projetos mas a maioria não dava resultados. Certo dia decidiram availar o porquê. Dentre as principais razão estavam:
- As pessoas envolvidas mudavam muito de opnião;
- As pessoas se omitiam;
- As pessoas estavam mais interessadas em discutir com outros membros da equipe.
Diante disso um problema claro de liderança foi identificado, decidiram nomear um lider para cada equipe e elaboraram o manual do nunca.

1. Nunca peça exatamente a mesma coisa para duas pessoas

Isto parece óbvio, mas na prática acaba acontecendo. Duas pessoas podem ter entendimentos diferentes sobre a cerca da mesma atividade e isto pode gerar impasses, ou mesmo a execução incorreta de atividades.

2. Nunca acredite que uma pessoa que estudou mais que a outra sabe mais que a outra

Isto é um dos preconceitos que vez ou outra podemos nos deixar seduzir. Em minha opinião o que o autor quis dizer é: questione sempre se a pessoa escolhida é realmente a melhor opção para realizar aquela tarefa, averigúe, observe o que diz o histórico daquela pessoa.

3. Nunca de uma tarefa urgentíssima para um funcionário que sempre tem tempo livre de para um que esteja super ocupado

Novamente aqui vai a minha visão: desconfie do funcionário que sempre tem tempo livre no tocante ao comprometimento. Pra mim, desconfiar significa estar sempre atento. Neste caso, acredito eu, o comprometimento é que é a palavra chave.

4. Nunca acredite que um problema já atingiu seu ponto Máximo. Tudo sempre pode piorar

Isto pode parecer exagero, mas é bom estar vigilante. Problemas em projetos podem ser um poço sem fundo. Nunca é demais se cercar de medidas para resolver problemas e para monitorar de perto

5. Nunca acredite na opinião de quem não pode tomar a decisão

Aqui não se trata de não ser sincero pura e simplesmente. A questão é: quem não tem o ônus de tomar decisão dá uma opinião “não comprometida com o projeto”, ou seja, não alinhada com os objetivos do projeto. É comum ver gente dando opiniões nas quais eles acreditam ser o melhor tecnicamente, mas não estão alinhados com os objetivos do projeto

6. Nunca delegue coisas que depois só você terá que explicar

Essa é uma das afirmativas que concordo em gênero, número e grau. Esta é bem direta e realmente é NUNCA. Quando se trata de colocar sua pele em jogo você delegaria a responsabilidade? Aquilo que você terá explicar caso dê errado jamais pode ser delegado.

7. Nunca tente convencer se você pode mandar

Esta pra mim é uma das mais controversas. Confesso que me chocou um pouco, pois sou favorável a sempre tentar convencer antes de mandar. Ou seja, usar sempre o convencimento como primeira alternativa. Acredito que isto ajuda a manter a equipe motivada. No entanto, tenho que concordar que mandar deixa as coisas mais rápidas. Para quem pensa assim a questão é saber se você tem ou não o poder de mandar. Já para quem pensa como eu (primeiro tentar o convencimento depois dar ordens) a questão é saber quando já se gastou tempo demais tentando convencer e que a hora é de decisão.

O Gerente e sua equipe - 2ª Parte

2008-08-18T17:56:00.000-07:00

Caros,

Depois de um "longo e tenebroso inverno" aqui estamos nós. Volto comentando sobre uma dúvida passada pelo Juarez no meu penúltimo post. E quando um membro da equipe invade uma competência que não é a sua, como por exemplo, dar uma de "gerente do projeto por um dia". O que fazer?
Bem lidar com pessoas nunca foi fácil e por isso as respostas para questões como essas nunca são muito precisas. De qualquer forma temos algumas coisas a falar:

Temos que observar qual a proposta de organização para equipe. Os papéis estão claramente definidos? Está claro para todos os membros que papel eles devem desempenhar?
Tomar cuidado para não tolher a "pró-atividade" da equipe, visto que está é uma característica desejada em quase todos os times;
Verificar sempre se não é possível converter em boas ações as "interferências". Ou seja, usar a criatividade para verificar se as "intromissões" ou desvios de função podem ou não ser aproveitados.
Em último caso, quando se tratar realmente de problema que afete de alguma forma o bom andamento do projeto o líder da equipe deve se posicionar de maneira firme e educada e explicar o porquê daquela atitude ser prejudicial no momento. Casos problemáticos devem ser acompanhados mais de perto, sempre com o cuidado de avaliar caso a caso.

Não se pode negar que em casos extremos (atitudes que comprometem seriamente o desempenho da equipe) o gerente terá que tomar atitudes mais drásticas como punições ou o desligamento da equipe. Note que, propositadamente, coloquei esta alternativa depois do "último caso". Isto é pessoal, gosto de tentar todas alternativas antes de partir para atitudes punitivas. Gosto de esgotar as possibilidades, trabalhar muito o motivacional e aproveitar o que cada membro da equipe tem de melhor.

Espero ter contribuído

Até breve

Artigo publicado no SBQS

2008-05-17T07:54:00.000-07:00

Caros,

Sei que este post é um tanto quanto off-topic, mas lá vai....
Gostaria de compartilhar com todos a notícia da aprovação de um artigo escrito por mim e um amigo para publicação num simpósio nacional. O artigo (Avaliando os efeitos da aplicação do TDD) será publicado no SBQS 2008. Por estar providenciando os ajustes finais no artigo fiquei um tempo sem postar, mas estamos de volta. No próximo post responderei a pergunta (feita aqui no blog) sobre como fazer quando os membros da equipe atrasam na entrega de artefatos.

Até breve ....
______________________________________________________________________

O gerente e sua equipe

2008-05-03T06:18:00.000-07:00

Quando estamos na área de produção de software muito ouvimos falar sobre padronização, automatismos, métricas, etc. Além disso, vários de nossos cursos (computação em geral) estão ligados a área de exatas. No entanto, o que poucos consideram é o lado humano da produção de software, ou seja, o lado da não exatidão, o lado que ainda não dá pra ser automatizado. Por isso e por um comentário feito neste blog é que decidi falar um pouco sobre relacionamento do gerente com a sua equipe.

Desde que aprendemos a viver em sociedade que nos deparamos com problemas de relacionamento. Num projeto de software estes problemas podem ser uma fonte de dor de cabeça para o gerente e aos poucos ir minando o projeto, pois apesar de toda técnica aprendida pelos membros do time estamos sempre sujeitos as "variações de humor" e desentendimentos, pois pessoas não são autômatos, pessoas possuem famílias, problemas das mais variadas naturezas. O gerente que desconsidera isto empurra a poeira pra debaixo do tapete e um belo dia a casa pode vir abaixo. Não adianta fechar os olhos para alguns problemas pessoais de sua equipe. Isto mesmo, apesar de serem problemas pessoais, muitos deles acabam interferindo no andamento dos trabalhos.
Vou repetir aqui o que um amigo postou aqui no blog: " O gerente tem que ser meio psicólogo, meio terapeuta...". Acredito firmemente nesta afirmativa.

Como minimizar

Ao invés de evitar, decidi usar o termo minimizar, pois acredito que problemas desta natureza sempre ocorrerão.
Em primeiro lugar o gerente deve conhecer bem sua equipe, suas habilidades, experiência profissional e (é aqui que entra o lado do psicólogo rsrs) suas dificuldades (sejam elas quais forem). É preciso conhecer as habilidades para que se possa distribuir melhor as atividades, saber com quem podemos contar em determinadas situações. O mesmo se aplica a experiência profissional.
Com relação ao lado pessoal, é recomendável que o gerente, sempre que puder, estreite os laços com os membros de sua equipe. Não falo isso pura e simplesmente porque precisamos terminar o projeto, e sim por ser muito mais prazerozo o trabalho realizado entre amigos. Além do que, o fato da equipe se relacionar bem com o gerente é facilitador direto da tarefa de FeedBack.
Reserve um tempo para escutar seus problemas pessoais, as questões que os afligem, preocupe-se verdadeiramente com cada um com suas particularidades.

Constantes Feedback- Além de passar feedback para a equipe é essencial que o gerente permita que os membros da equipe o forneçam também. Considero este último ainda mais importante. Ao passar feedback seja educado e o faça sempre de forma construtiva. Por exemplo, nunca diga: "você está errado" e "sim você poderia fazer melhor o que está fazendo se o fizesse assim...." é claro que a forma de abordar cada pessoa varia de acordo com o perfil de cada membro da equipe. Alguns aceitam críticas mais abertas, já com outros o cuidado com as palavras deve ser redobrado.

Evolução da sua equipe- Preocupe-se sempre com o crescimento de sua equipe, afinal de contas TI é uma área em constante mudança. Além do mais, os profissionais dessa área gostam de estar sempre evoluindo. Mesmo com cronogramas sempre apertados, reserve um tempo para melhoria. A sensação de estar evoluindo é, na minha opinião, uma das melhores coisas num trabalho.

Saber realmente o que sua equipe está fazendo é muito importante, não é necessário saber fazer tudo mas o quanto mais você souber sobre as atividades de seu time melhor será a comunicação e por conseqüência o relacionamento com a equipe.

Lembrar que mesmo contando com diferentes pessoas numa equipe a homogeneidade deve ser buscada a todo o tempo. Talvez homogeneidade não seja a melhor palavra e sim a consciência de equipe, espírito de equipe, etc. É importante saber tomar proveito das desigualdades e promover a união, desenvolver a idéia de que á equipe deve funcionar como um todo.
_____________________________________________________________________

Tomada de decisão

2008-04-29T15:48:00.001-07:00

Tomada de decisão, eis aqui uma coisa com a qual, se já não estamos habituados, teremos dificuldade ao entrar na área de gerência. Acontece que no cotidiano lidamos com tomada de decisão, mas nem sempre utilizamos técnicas para fazê-lo. Na realidade na maioria dos casos tomamos decisões de forma empírica ou simplesmente nos deixamos levar. Quando se está à frente de um projeto isto não pode ocorrer.
Outro fator que está presente em um projeto e que geralmente é inimigo da boa tomada de decisão é o tempo. O gerente novato pode se sentir bastante inseguro para tomar alguma decisão de impacto para o projeto. Ou mesmo pode levar tempo demasiado para reagir o que significa atraso para o projeto.

A tomada de decisão geralmente está associada a um risco para o projeto. Ou melhor, a tomada de decisão consiste em adotar a alternativa que representa menor risco para o projeto. Ou ainda, tomada de decisão visa sempre minimizar os riscos (negativos) de um projeto.

O PMBOK estabelece um área para a gerência de riscos e para ela quatro processos:

Identificação dos riscos;
Quantificação dos riscos;
Desenvolvimento das respostas e
Controle das respostas

Na minha opinião, o processo com maior grau de dificuldade é a quantificação dos riscos pois se soubéssemos quantificar exatamente cada risco, ficaria mais fácil combatê-los e optar pela resposta correta. O problema é que essa análise apesar de poder ser quantitativa geralmente tem seu maior peso no aspecto qualitativo. Ou seja, geralmente não temos números exatos pra decidir.

Como Evitar

Alguém disse uma certa vez (acho que foi Maquiável, não estou bem certo) que: "A decisão lastreia-se na informação, mas brota da sabedoria". Daí podemos dizer que para tomar decisão é necessário informação, boa informação e da maneira mas rápida que pudermos obter. Porém só a informação não basta tem que haver sabedoria o que nos tempos de hoje chamamos de experiência. Sim, acho que só com o tempo e o aprendizado é que se aprimora a tomada de decisão.
Em termos práticos, caso são possua a informação suficiente, procure-a, consulte quem saiba (a boa e velha opinião do especialista). Se dispuser de tempo, investigue através de protótipos (spike solutions, por exemplo). Outra técnica que ajuda é a da árvore de decisão.
Há também algumas ferramentas disponíveis para quantificar e analisar riscos:

@Risk - www.palisade.com
Risk+ -www.projectgear .com
Primavera´s Mont Carlo - www.primavera.com

É preciso ter em mente algumas coisas :

Nunca despreze toda e qualquer informação que possa ser útil
Documente sempre o porquê de se tomar determinada decisão
Controle se a resposta ao risco (decisão tomada) está sendo satisfatória
Não tenha vergonha de voltar atrás caso perceba que tomou alguma decisão errada (antes tarde do que nunca)
Uma decisão rápida vale mais do que uma indefinição muito longa
Não chore o leite derramado, se tomou a decisão errada trate de aprender com ela, isto é faz parte do processo de ganhar experiência.

Boa sorte e mãos a obra. Até Breve!
____________________________________________________________________

Estimando Prazos para o projeto

2008-04-26T08:00:00.000-07:00

Um cuidado que devemos ter é ao estimar prazos ou ao pedir que o façam é que temos que ter em mente que estimativas são aproximações e não uma medida precisa. Esta consciência deve ser tanto da equipe de projeto quanto dos clientes.
Mesmo sabendo que os prazos num projeto são aproximados é natural que as pessoas ao serem indagadas para fornecer tempo para execução de uma tarefa embutam neles uma margem de segurança, uma vez que temos intrinsecamente a idéia de que isto gera um compromisso. Agora imagine que cada pessoa dentro da hierarquia de uma equipe de projeto coloque sua margem de segurança. Tomemos como exemplo uma equipe apenas com dois níveis, desenvolvedores e gerente. O desenvolvedor acha que pode terminar a tarefa em 10h mas, por "segurança" passa para o gerente que deve levar umas 13 h este por sua vez no momento de elaborar o cronograma coloca a tarefa com duração de 15 h. Só aí temos um acréscimo de 50% no tempo da tarefa.
Por esse ponto de vista a maior parte das tarefas de um projeto deveriam terminar ou antes ou muito próxima do prazo. Mas isnto não é o que acontece na maiora dos casos.
Isto ocorre segundo a lei de Parkinson que diz que o trabalho se expande para preencher todo o seu tempo disponível para ser concluído.

Como Evitar?

A técnica do XP de ter o cliente sempre disponível nos ajudou a resolver o primeiro problema, que era fazer o cliente enxergar estimativa como algo aproximado. É claro que não basta ter apenas o cliente por perto, e sim de construir um relacionamento de confiança. Quando uma atividade atrasava o cliente era informado (detalhadamente) através de reuniões periódicas.
Da mesma maneira, evitar a "gordura extra" depende de um bom relacionaemento com a equipe de desenvolvimento. Os desenvolvedores precisam ter tempo razoável para realizar as estimativas e precisam saber que o gerente não os irá "chicotear"caso uma estimativa dada não se confirme. Em todos os nossos encontros para estimar prazos gostava sempre de enfatizar que me passassem o prazo real. É claro que sempre comparava os tempos estimados anteriormente para tarefas semelhantes com os tempos passados para a nova tarefa.
Em resumos os princípios de nossa forma de estimar prazos foram:

Construir confiança do cliente;
conscientizar que estimativas são aproximações minimizando as gordurinhas nos prazos;
sempre fazer a comparação com estimativas anteriores

____________________________________________________________________

Comunicação- Parte II-Reuniões

2008-04-25T16:29:00.000-07:00

Dada a importância que tem está área decidir me aprofundar mais um pouco em alguns detalhes. Neste post tratarei da comunicação interna seus problemas e alternativas para contorná-los.
Uma boa prática mas que se não for bem aplicada toma um tempo enorme num projeto são as reuniões com as equipes e com os clientes. Essas reuniões quando não são bem planejadas e conduzidas tendem a se tornar longas e enfadonhas. Uma tentativa que fizemos foi o de fazer reuniões a cada 15 dias (nossa iteração) nessas reuniões eram repassados todas a metas atingidas, o problemas, as soluções encontradas dentre outras informações. O problema com está abordagem foi que além de acumular muitos assuntos alguns problemas descobertos no início da iteração esperavam até o fim para serem resolvidos.

Como superei?

De início as reuniões passaram a ser semanais, depois passaram a ser diárias mas ainda sem um planejamento. Isso mesmo, por menores que sejam as reuniões, elas precisam acontecer com o mínimo de planejamento. Para isso recorremos ao SCRUM que define as seguintes regras para as reuniões diárias : (tradução nossa)

Devem ser diárias;
Devem acontecer no mesmo local e no mesmo horário todos os dias;
Não devem durar mais de 30 minutos (no nosso caso adotamos 15 min com 5 min de tolerância); Uma dica neste caso é usar o celular para alarmar a cada cinco minutos.
O SCRUM master é apontado (no nosso caso o próprio gerente do projeto)
o Scrum Master é responsável por perguntar a todos da equipe

O que você fez desde a última reunião?
Quais foram as dificuldades na execução de sua tarefa?
O que você pretende fazer de agora até a próxima reunião?

A conversa só é permitida para responder as 3 perguntas acima;
Reuniões podem ser estabelecidas para logo após essa reunião; (geralmente estas reuniões servem para que alguns membros da equipe possam debater mais detalhadamente sobre problemas e/ou soluções)
O Scrum master é responsável por tomar decisões imediatas para romover impedimentos a resolução de problemas;

Vale ressaltar que é preciso de muita disciplina para que estas regras sejam seguidas. A atitude do gerente nestas reuniões é decisiva, muitas vezes sendo um pouco chato.
É preciso evitar que estas reuniões se tornem encontros para colocar a conversa em dia, fazer lanches, conversar sobre futebol, fim de semana, etc. (armadilhas scrum)

Mesmo com as reuniões diárias outras reuniões eram necessárias e as vezes mais longas. Nestes encontros algumas regras gerais foram aplicadas:

Fazer reuniões apenas quando necessário;
Comunicação com antecedência da pauta da reunião e inclusive di tempo de duração;
Tempo de duração não superior a 2 horas;
O número de participantes deve ser tão enxuto quanto possível;
Toda reunião deve ter no mínimo um relator/secretário e um gerente
Reuniões devem sair com todo lists e definições;
Caso ache necessário elabore ata (prática, resumida, apenas com o essenncial); Template de ata de reunião

Até a próxima !

Comunicação- Parte I

2008-04-24T16:39:00.001-07:00

Essa foi umas das áreas de gerência de projeto que mais negligenciei no início. Confesso que não dei muita importância (participar de reuniões, conversar com os envolvidos ? Isso não é trabalhar, pensava eu).Isto aconteceu logo num projeto no qual parte dos envolvidos estava em locais geograficamente distantes. Como dizia o velho guerreiro: "Quem não se comunica se trumbica".
O resultado vocês já podem imaginar: a falta de comunicação ou a má qualidade da mesma tende a bagunçar muito projeto. Os sintomas são muitos, dentre os quais vivi alguns:

retrabalho- quando a comunicação falha fatalmente uma tarefa tem que ser corrigida, ou seja, refeita;
Erros no projeto- se a falha não for percebida a entrega do projeto poderá conter falhas
Desvios de escopo- se descobertos em tempo acarretam em elevação de custos, insatisfação, alterações de prazo. Caso sejam descobertos tardiamente, as conseqüências são bem mais danosas;

Uma pesquisa da empresa norte-americana de treinamento Vital Smarts aponta que por causa da falta de comunicação 82% estouram os prazos e 79% não conseguem atender as especificações de qualidade. Mais info.
Acredito que quanto maior o número de envolvidos no projeto e quão maior for a distância entre eles mais tempo o gerente terá que dedicar a esta área. Em nossa experiência a comunicação era dividida basicamente em três categorias de acordo com os envolvidos: superiores, clientes, parceiros (externos a equipe) e colaboradores (interna a equipe).

Como superei?

Felizmente esta foi uma necessidade tão forte que rapidamente percebemos a importância de nos comunicarmos bem. Tivemos dar uma pequena pausa, recorrer a literatura (PMBOK e algumas práticas de gerência de projetos ágeis) elaborar um plano de comunicação e passar a segui-lo e reavaliá-lo constantemente. A seguir algumas das principais práticas/técnicas que utilizamos:

Reuniões diárias com a equipe (Segundo SCRUM);
Escuta ativa;
Criação e divulgação da forma de comunicação;
Fazer e divulgar lista de contato dos envolvidos;
Construir e manter site do projeto (com mínimo de overhead sobre o projeto em si);
Uso teleconferências;
O cliente como parte da equipe (prática abraçada pelo XP)

O assunto comunicação é vasto e certamente voltarei a falar dele detalhando um pouco mais

Até breve!

Delegar tarefas

2008-04-24T15:09:00.000-07:00

Uma das armadilhas com a qual me deparei durante o primeiro projeto como gerente foi a de tentar fazer de um tudo. Isto mesmo, no início tive dificuldade de me afastar do desenvolvimento em si. Acredito que isso acontecia parte por conta da equipe reduzida que tínhamos e parte pela inércia, ou seja, estava habituado a desenvolver (codificação, projeto e análise) "fiz isso durante muito tempo em minha carreira, era o que eu sabia fazer melhor".
Este problema atrapalhou o bom andamento do projeto durante alguns meses. Foi duro até eu aprender a delegar tarefas. Pode parecer óbvio, afinal de contas a distribuição de tarefas é uma das atribuições básicas do gerente de projeto. Pois bem, não que fizesse isso todos os dias, mas constantemente me pegava fazendo tarefas que deveria confiar a alguém.

Como superei?

Bem, neste caso acho que a gerência a qual eu estava subordinado contribuiu para isso, insistindo, orientando e cobrando que eu exercesse minhas atividades de gerência. A pessoa que controlava o meu trabalho constantemente me cobrava por cronogramas, status do projeto etc. sendo assim tinha cada vez mais que delegar atividades para poder me dedicar as tarefas de gerente.
Outro componente foi o tempo, a prática das atividades de gerência me fez perceber a importância de distribuir responsabilidades.

Denial of Service- O gerente é um multitarefa por natureza

2008-04-23T13:25:00.001-07:00

Não é raro, independente da área de atuação, ser atropelado por um volume grande de atividades, todas aparentemente com a mesma prioridade. No entanto, esta parece ser uma coisa pra lá de rotineira na área de gerência em TI.
Quando iniciei gerenciando projetos vivi na pele essa avalanche de tarefas. O meu primeiro projeto como gerente a quantidade de tarefas era bem superior ao meu número de horas no dia, todas com a máxima urgência. Isto pode facilmente conduzir qualquer gerente novato ao stress, ou melhor, como costumava chamar ao Denial-Of-Service. Isto porque chega a um ponto que se não tomarmos cuidado acabamos por não concluir tarefa alguma a contento. Ou seja, pode-se comprometer bastante o cronograma de um projeto se não soubermos como lidar com uma demanda excessiva.

Como superei

A primeira coisa a se fazer é manter a calma. Falado assim isto parece simples, mas na verdade não é. Como gerente, somos responsáveis pelo bom andamento do projeto e queremos,naturalmente, resolver os problemas da maneira mais rápida possível. Isso pode acabar levando a uma produtividade baixa (pelo menos foi o que aconteceu comigo durante um tempo).
Uma vez calmo, a segunda coisa a fazer é pensar com frieza em qual dos problemas que quando resolvido trará maior ganho num menor espaço de tempo. Ou seja, tempos que priorizar atividades segundo os critérios de retorno para o projeto (levando em conta o tempo para obtê-lo). Trata-se do bom e velho "atacar um problema por vez".
Vale lembrar que é sempre bom considerar que algumas atividades podem ser delegadas. É sempre por fazer-se essa indagação, pois quando iniciamos na atividade de gerência muitas vezes queremos resolver tudo sozinho. Mas isso já é assunto para outro Post.

Até Breve

O Início - A Mudança- O mito de que o gerente não faz nada

2008-04-22T09:26:00.000-07:00

Como primeira postagem, escolhi voltar um pouco no tempo e lembrar da primeira vez que fui escolhido para gerenciar um projeto. Eu que sempre gostei de desenvolver (codificar e fazer análise) por força da circunstância me vi obrigado a gerenciar um projeto de software.
Como preparação, alguns cursos (PMBOK) e uma boa dose de pesquisa na Web me foram indispensáveis.
A seguir comentarei sobre as primeiras dificuldades (desafios), começando pelo que chamo de

O mito de que o gerente não faz nada.

Como desenvolvedores tendemos a acreditar que nós fazemos todo o trabalho e por conta disso sofremos a maior pressão quase todo o tempo. Quando passamos de desenvolvedor para gerente um dos sentimentos preponderantes (geralmente ao final do dia) é o de que não produzimos nada, ou seja, nenhum código "brotando de nossas mãos". A sensação é estranha e é preciso de certo esforço e tempo para convencer-se que o seu trabalho "tem algum valor".
Acredito eu que pela natureza distinta dos trabalhos (Desenvolvedor X Gerente) acabamos com a sensação de improdutividade. Isto é, ao invés de ver, aos poucos o código ganhando vida, agora temos que participar de um número bem maior de reuniões, resolver problemas de relacionamento na equipe (picuinhas), cobrar prazos, atualizar cronogramas etc. Raros não foram os dias em que me via como um mero resolvedor de "probleminhas".

Como superei?
Bom, para superar está terrível sensação três fatores foram essenciais:

passar a enxergar as novas atividades como desafio;
saber que um bom gerente tem como uma de suas funções servir a sua equipe para que se possa atingir um fim;
tempo;

O gerente noviço precisa se comprometer com as suas novas tarefas e acreditar que elas são importantes para o bom andamento dos trabalhos, por isso enxerga-las como desafio ajuda muito.
Se ver como um servidor de sua equipe é um dos pontos chaves, ou seja, como gerentes acabamos nos importando mais com o bem estar geral de nossa equipe do que com o nosso, passamos a ver qualquer obstáculo ao bom andamento das atividades como nosso inimigo.
O tempo, ou seja, a experiência faz com que se "tome gosto" pelas atividades de gerência. De outra forma podemos dizer que se os dois primeiros fatores forem observados é questão de tempo para que a sensação desagradável de improdutividade desapareça.

E aí? Alguém mais já passou por algo parecido?

Boas vindas

2008-04-22T06:05:00.000-07:00

Oi pessoal,

Como boa parte dos profissionais que trabalham com gerência de informática comecei como programador , passei a analista , depois gerente de projeto e hoje ocupo um cargo de gerência de sistemas. Bem como grande parte das pessoas, eu NÃO nasci gerente e estou tendo que me adaptar.

Decidi criar este blog no intuito de compartilhar idéias para os que passam ou ainda vão passar por situações parecidas na área de gerência de TI, bem como pessoas interessadas no assunto. Abordaremos, principalmente, relatos de casos vividos, problemas e suas soluções. Sintam-se à vontade fazer críticas e compartilhar opiniões.

Espero que ajude.