Olá Brasil !!!

Como vocês devem ter percebido, acabei ficando um bom tempo sem postar nada aqui no blog.

Isso aconteceu por uma soma de fatores. Acredito que os principais tenham sido:

- Falta de tempo pra postar por causa da enorme carga de trabalho neste segundo semestre;

- Alguns assuntos já estavam meio que esgotados. Preferi passar um tempo focado no trabalho e no aprendizado para voltar a postar algo realmente útil aqui;

- Uma certa falta de organização melhor do meu tempo;

Bom, aparentemente grande parte desses “problemas” estão superados e agora estou melhorando um pouco a gestão do meu tempo, então vou voltar a postar mais por aqui.

Em primeiro lugar, vou lançar uma série de posts dedicados aos workshops e treinamentos que fiz em 2010 – e foram muitos. O objetivo disso é que também comecei a trabalhar como consultor em métodos ágeis e gestão esse ano e essa área do blog será como um portfólio, para que você possa conhecer um pouco mais sobre minha experiência no assunto.

Depois, estou montando uma retrospectiva de 2010 que deve aparecer por aqui até o final do ano. Vou focar em várias lições aprendidas esse ano e que foram muito importantes para o meu crescimento pessoal e profissional.

Bom, é isso. Espero que possamos nos ver mais daqui pra frente

Grande abraço.

André Nascimento

Alow Brasil, tudo bem?

Semana que vem acontece em SP o TDC 2010  - The Developers Conference. O evento é organizado pela Global Code e até então era mais focado para a comunidade Java. Este ano, no entanto, o modelo do evento é baseado em trilhas diversas.

O evento tomou proporções bacanas, alcançando mais de 1.100 inscrições uma semana antes de sua realização.

Cada trilha será praticamente um evento a parte e é coordenada por pessoas especialistas e conhecidas na comunidade brasileira de software. Além disso, contam com excelentes palestrantes, altamente especialistas sobre os temas abordados.

Um ponto interessante que eu quero destacar sobre o evento é que teremos alguns nomes do SDC Stefanini palestrando por lá nas trilhas de .NET, Testes, Agile e Ruby. São eles: Victor Cavalcante, Jorge Diz, Vinicius Quaiato e Antônio Zegunis – Tucaz ( que já não trabalha diretamente no SDC mas está na empresa e sempre por aqui dando uns “palpites”, rs).

Eu fui convidado pelo Felipe Rodrigues e Giovanni Bassi para palestrar na trilha Agile e contar um pouco sobre a adoção de Agile na Stefanini. Fiquei muito feliz com o convite e decidi que o título da palestra seria “Cultura mais do que Práticas”, que reflete muito bem o caminho que decidimos tomar há uns 2 anos na adoção de agilidade: Fortalecer a cultura e pensar nas práticas depois.

Outra coisa muito legal é que a Stefanini vai patrocinar o evento. É uma novidade bacana, porque não temos muito costume de patrocinar eventos técnicos. Isso é fruto de um trabalho magnífico que está sendo feito por toda a equipe do SDC e que tem dado visibilidade marcante sobre a cultura e processos aplicados nessa área.

E pra fechar, se repetirmos o feito do Agile Brazil 2010 seremos novamente a empresa com maior número de participantes no evento,

Se você ainda não fez sua inscrição, corra pois ainda restam poucas vagas.

Grande Abraço !!! Nos vemos lá \o/

Links relacionados:
- Blog do Leonardo Neves

André Nascimento

Alow Brasil…

Após um pequeno tempo sem postar nada por aqui estou retomando aos poucos o tempo para blogar \o/ Acabei dando um tempo para pensar em alguns assuntos e organiza-los em minha cabeça. Enquanto isso é claro: Muito trabalho

Faz um tempo que penso em escrever algumas coisas sobre produtividade e ambiente de trabalho e vou começar com um assunto bem legal e controverso: Faz sentido bloquear internet em uma empresa ou área de desenvolvimento de software?

É claro que já vivenciei inúmeras situações ridículas envolvendo esse assunto, mas o que me levou a escrever sobre isso foi um fato que aconteceu hoje e me deixou refletindo por alguns bons minutos. Vou resumi-lo pra vocês:

Um desenvolvedor do meu time, que está no cliente para realizar algumas melhorias num sistema que foi desenvolvido pelo cliente me chamou no msn (ele estava no celular) com uma dúvida sobre Linq. Ele queria saber algo sobre uma clausula de filtro em particular. Eu dei uma dica de como ele poderia usar o Linq pra resolver, mas não me lembrava da sintaxe exata. Então, expliquei pra ele o conceito (eu quase nunca passo somente uma linha de código sem primeiro discutir o porque e o conceito envolvido) e disse o caminho pra resolver. Sobre a sintaxe eu falei pra ele procurar no google e aplicar… fácil certo?

Nem tanto pois a empresa em que ele estava bloqueia totalmente o acesso à internet. Nem o google é aberto pra pesquisa. E ele estava dentro de uma área de desenvolvimento de software e TI de uma gigante na área de comunicação e telefonia.

O pior é que tenho visto cada vez mais empresas do segmento de TI e desenvolvimento de software partindo para ações como essa. Podemos ver alguns níveis de bloqueio nessas empresas:

1. Redes sociais como Orkut e Facebook;
2. Sites de vídeos como youtube e cia;
3. Twitter;
4. Instant messaging como msn, G-Talk, Skype, etc;
5. Blogs e conteúdo de notícias;
6. Internet banking e emails pessoais;
7. Finalmente, bloqueio total de qualquer site inclusive google.

Pessoalmente, posso dizer que consigo “engolir” justificativas para os dois primeiros da lista. O primeiro porque eu não gosto e não vejo a mínima razão para utiliza-los no trabalho mesmo. O segundo porque em empresas onde a internet é compartilhada com muita gente (caso de onde trabalho), mesmo que a banda seja boa, streaming de video realmente quebra as pernas.

Agora, para todos os demais itens da lista eu só consigo visualizar uma coisa: Retrocesso Empresarial!!!

É interessante pensarmos em porque uma empresa chega ao extremo de bloquear todo acesso de internet de um time que desenvolve software ou trabalha com TI em geral. O que vemos pelo mercado é mais ou menos isso:

1. Internet diminui a produtividade e o foco do trabalho;
2. O profissional deve utilizar seu tempo livre para estudar e não o da empresa;
3. Não é preciso pesquisar sobre desenvolvimento na internet. Profissional bom é o que “domina” a sintaxe da linguagem;
4. Problemas de segurança, como por exemplo enviar um arquivo confidencial por email.

Vamos dar uma boa olhada em cada uma delas:

Internet diminui a produtividade e o foco do trabalho

Séra? Depende muito do ponto de vista do qual se está avaliando. Como você enxerga produtividade na sua empresa quando falamos em desenvolvimento de software? Ainda é baseada na quantidade de horas que um profissional “lança” numa atividade ou numa timesheet? Se for isso, então talvez você tenha razão e podemos parar por aqui.

A verdade é que produtividade em desenvolvimento de software não é medida pela quantidade de horas que um profissional passa sentado na frente do computador ou em quantas horas ele lança numa atividade no seu sistema de controle. Esse controle é baseado na idéia de que desenvolver software é a mesma coisa de desenvolver produtos industriais – ver post sobre o termo fábrica de software – e isso não procede. Sobre isso, vou dedicar um post para falarmos, certo?

Se eu partir da premissa de que temos que trabalhar com profissionais adultos e responsáveis que saibam gerenciar seu próprio tempo e atividades e que temos que confiar nesses profissionais, vamos ver que é ridículo bloquear internet pensando em produtividade.

É claro que existem aqueles “profissionais” que aproveitam da empresa mais liberal e passa o dia todo vendo notícias de esporte, viagens, batendo papo, etc. Acontece que não dá pra punir 95% que faz certo, por causa de 5% que faz errado. O cara que faz isso não produz, se ele não produz é fácil aparecer. Se isso acontecer o que fazemos? Manda o cara embora e contrata outro adulto no lugar.

O profissional deve utilizar seu tempo livre para estudar e não o da empresa;

Essa é outra idéia que faz com que o índice de turnover de uma empresa bata picos do tamanho do Everest. Ora, quem disse que a empresa não deve incentivar o profissional a estudar em seu tempo de trabalho? Poxa, vamos ser sinceros: Se o cara quer enrolar ele faz isso com ou sem internet. Basta dar um elástico e/ou um clips pra ele e pronto. Não é melhor que o cidadão invista seu tempo ocioso em estudo e aprendizado?

E se não for em estudo também, qual o problema de ficar um tempo sem fazer nada? Existem estudos hoje em dia que mostram que profissionais que trabalham com atividades intelectuais precisam de um “break” para voltar a focar numa atividade. Quantas vezes já não passamos horas parados feito estátuas olhando para um código sem encontrar solução, alguém insistiu para tomar um café e depois de 20 minutos você voltou dando risadas altas pelas piadas contadas no café, sentou-se na frente da máquina e resolveu o problema na mesma hora?

Não é preciso pesquisar sobre desenvolvimento na internet. Profissional bom é o que “domina” a sintaxe da linguagem;

Nem vou me alongar muito neste tópico. Se você ainda acredita nesse tipo de coisa acho que já pode parar de ler o artigo (e o blog). Mais um pensamento totalmente baseado na idéia de que desenvolver software não é uma atividade intelectual e sim repetitiva e automatizada. #FAIL

Problemas de segurança, como por exemplo enviar um arquivo confidencial por email.

Se você trabalha em uma mega empresa do setor financeiro ou coisa do gênero, talvez pode ser possível usar essa desculpa. No geral, justificar bloqueio de internet com desculpas de segurança de informações é uma grande falácia. Tem empresa que bloqueia tanto a internet, messaging, etc, mas dá senha de banco de dados de produção pra consultor fazer deploy de madrugada. Segurança ? I don’t think so…

Hoje, algumas empresas partem para a estratégia de bloquear tudo e fazer com que cada um que precise acessar um determinado endereço (blog por exemplo), entre em contato com a área de infra ou segurança de informação e defenda o porque precisa daquele acesso. Depois de “10″ dias, “30″ assinaturas  e um caminhão de tempo perdido, o acesso é liberado e o profissional já não precisa mais daquele acesso. Lembra do primeiro item da lista: Produtividade? O que será que é mais produtivo não é mesmo?

E quem disse que é alguém da infra ou da segurança que é a melhor pessoa para ter esse controle? Acabo pensando que isso é justamente uma questão de controle mesmo. Do tipo totalmente territorial e injustificado. Se acontece na sua empresa, não se assuste

Resumindo:

Somos trabalhadores do conhecimento. Trabalhamos com uma atividade intelectual e não industrial e repetitiva. Somos totalmente forjados com conhecimento e informação. Bloquear acesso à internet neste cenário é um completo absurdo.

A empresa que ainda possui esse tipo de postura é completamente atrasada e corre o risco de ser varrida do mapa.

E você, o que pensa a respeito?

Grande abraço.

André Nascimento

Alow Brazil !!! Ops, BRASIL né? Ainda estou acostumado a escrever com “Z” por causa da hash no twitter, eheheh.

Bom, o objetivo do post é falar um pouco sobre o grande evento de agilidade do ano que ocorreu em Porto Alegre na semana passada: O Agile Brazil 2010. Como já falei no post anterior sobre o curso de CSPO, vou me concentrar nos dias do congresso, certo?

Para começar, vou voltar um bocado no tempo, para contar um pouco da motivação desse evento e quais eram os meus objetivos particulares com relação a ele.

Minha primeira motivação, lá atrás, quando o evento foi lançado era a de palestrar. Achei que tinha algumas experiências bacanas pra contar para o pessoal da comunidade, principalmente na área de consultoria de TI e outsourcing de desenvolvimento, que é a área que trabalho pra quem não sabe.

Confesso que fiquei um “tiquinho” desapontado quando minha apresentação não foi escolhida, principalmente pelo feedback de eu não ter experiência com agilidade. Depois de passar um tempo remoendo os motivos, acabei levando de boa e dando mais ênfase ao segundo item motivacional: Aprender e validar se o que fazemos aqui está certo ou não.

Como eu trabalho num formato bastante diferente com agilidade, ou seja, num ambiente de “fábrica de software” (odeio esse nome), acabo muitas vezes numa encruzilhada, me perguntando se estamos realmente no caminho certo, se o que fazemos é agilidade de fato ou mesmo se vale a pena. Fui para lá então com essa idéia fixa na cabeça de agregar conhecimento em práticas que ainda não conheço ou não tenho um bom domínio e ouvir relatos de outros caras que como eu, buscam uma forma melhor de desenvolver software.

A equipe da Stefanini que trabalha com desenvolvimento ágil no centro técnico de São Paulo esteve em peso no evento. Fomos a empresa com maior número de representantes no Agile Brazil 2010. Pessoal todo comprometido com a adoção e evolução do modelo ágil na empresa.

Maior equipe no evento... SDC Stefanini !!! Outros 70 ficaram em SP

Agora sem mais demora, alguns pontos do evento:

Local e Infra-estrutura:

A escolha da PUC para abrigar o evento foi muito acertada. O local ofereceu uma infra muito boa para o evento, tendo fácil acesso de várias partes da cidade de Porto Alegre. Nosso hotel mesmo ficava uns 10 Km do evento, mas não tivemos nenhum problema para chegar.

Organização:

O time de organização merece os parabéns de todos que participaram. Tudo estava muito bem organizado, o material distribuído foi bacana e haviam várias pessoas para orientar os participantes, dando informações e auxiliando nas questões gerais, como salas de palestra por exemplo.

Keynotes:

Quem abriu o evento foi ninguém menos do que o Martin Fowler, um dos que assinaram o manifesto ágil e criador de muitos dos conceitos que utilizamos hoje em nossa área. Embora ele não tenha trazido nada de novo em sua apresentação, falou de assuntos importantes como o “Flacid Scrum”, termo criado por ele. Sua palestra foi bastante focada em práticas de engenharia de software para suportar a agilidade. Nota 10 !!!

Outro keynote do qual todo mundo comentou foi o de encerramento, feito pelo Klaus Wuestefeld. Infelizmente, não assisti porque tive outro compromisso no horário

Grade e Palestras:

Quando o evento foi lançado, achei que haveriam 4 dias de congresso e não somente dois. Depois, quando o evento foi quebrado em duas partes eu já sabia que a grade não ficaria tão boa. Talvez esse seja o único ponto negativo do evento em si, pois as palestras ficaram muito apertadas e sinceramente, 5 trilhas ao mesmo tempo foi sacanagem. Acabou que o jogo do Brasil atrapalhou bastante o evento também, infelizmente não tinha como a turma da organização saber né? Então vamos poupa-los de mais comentários.

As palestras foram de bom nível, com assuntos pertinentes para a comunidade ágil brasileira. Pessoalmente gostei muito da apresentação do Alexandre Gomes e Renato Willi sobre desenvolvimento ágil e o governo. Eles dominam bastante o assunto.

Houveram também palestras que na minha visão não foram tão legais, tanto no assunto quanto na experiência do palestrante ao falar em público. Infelizmente também aconteceu o famoso fenômeno “Mais do Mesmo”. Alguns palestrantes falam da mesma coisa e da mesma forma, com as mesmas experiências que tinham e já falavam há 2 ou 3 anos atrás. Algumas palestras foram exatamente mais do mesmo, mas, se pensarmos que alguns participantes eram realmente iniciantes em agilidade, podemos deixar isso pra lá também.

Resumo:

Em geral, o evento foi muito bom e proveitoso. Para mim, serviu para validar que estamos no caminho certo \o/, priorizando cada vez mais a cultura e as pessoas e menos os processos, mesmo que eles sejam muito importantes e mereçam atenção sempre.

Também serviu para me mostrar e comprovar que não existem respostas certas e erradas quando falamos em desenvolvimento de software e agilidade. Cada um deve buscar a melhor maneira em se desenvolver software e agregar maior valor ao cliente, motivando e valorizando o trabalho em equipe.

O maior ganho que tive neste evento foi conhecer pessoalmente pessoas como o Rafael Rosa (@rafaelrosafu), Alan Batista (@Alanrrb), Ricardo Serradas (@ricardoserradas), Luiz Faias (@luisfaias) entre outros grandes caras da comunidade, que compartilham experiências e ajudam no seu crescimento. A troca de idéias com esse pessoal durante o evento faz valer qualquer investimento.

Digo então que o evento valeu cada centavo investido. Meus objetivos foram cumpridos e volto pra casa, junto com o time da Stefanini com a missão de focarmos cada vez mais em agilidade e na entrega de valor no desenvolvimento de software.

O evento me deu idéia para mais uns 5 posts pelo menos e eles já entraram na fila (salvos com outros 34 Drafts, rs). Procurarei blogar com mais frequência, ok?

Se quiser outras referências sobre o evento, também recomendo:

Blog do Rafa Noronha

Blog do Rafael Rosa

Grande abraço !!!

André Nascimento

Olá pessoal,

Conforme prometido, gostaria de compartilhar com vocês algumas impressões sobre os primeiros dias no Agile Brazil 2010.

Como vocês sabem, o evento está dividido em duas partes: Nos dois primeiros dias tivemos alguns cursos e a partir de amanhã teremos as palestras e workshops.

Eu vim para cá na segunda com o Tucaz e Victor Cavalcante para fazer o curso de CSPO com o Alexandre Magno. Escolhi esse curso porque precisava preencher alguns gaps na formação de Product Owner.

Com as experiências que temos tido nos projetos, principalmente no que diz respeito ao relacionamento com alguns clientes, percebi que existe um grande vazio no papel de Product Owner, que precisa ser trabalhado de forma mais abrangente e séria, se quisermos ter sucesso na adoção de agilidade.

Falando um pouco do evento, o lugar (PUC) é muito legal e possui infra-estrutura condizente com o tamanho e importância do evento. Ponto positivo para a equipe de organização.

Sobre o curso de CSPO:

O Alexandre Magno é um excelente instrutor. Ele realmente possui bagagem sobre o assunto e domina bastante as técnicas do Scrum. Como ele tem focado bastante no assunto P.O nos últimos tempos, acho que agregou um conhecimento muito consistente. Sua didática também é bem bacana.

O curso foi dividido com o Luiz Parzianello da PUC, que ficou com a parte de análise de negócios e como montar um plano de negócio antes de começar a falar de backlog.

Ele também tem um conhecimento muito grande sobre os assuntos apresentados. Conseguiu resumir em pouco tempo um assunto bem complexo. Sinceramente, acho que falta um pouco da didática dele para este tipo de curso, mas no geral ele mandou bem.

Sinceramente acho que não ficou muito boa a divisão do curso entre eles. Como foi algo novo, me pareceu que alguma coisa se perdeu em alguns momentos e muitas pessoas ficaram um pouco perdidas no raciocínio.

Como acontece em qualquer treinamento, workshop ou curso onde se fala de Scrum e agilidade, aconteceram algumas discussões mais básicas onde perdeu-se um pouco de tempo e foco. Acontece, né?

Minha expectativa para o curso era conhecer algumas técnicas que o Magno domina para tratamento do backlog, planejamento de releases, etc. O tempo do curso acabou ficando curto e algumas coisas importantes ficaram de fora.

Acredito que o curso no formato só do Alexandre Magno – mais focado – seja um pouco mais completo. Este é o relato de todo mundo que fez o curso com ele em outras ocasiões.

Acho que um ponto forte foram as atividades práticas de como pensar um produto e trabalhar para que ele tenha valor agregado  ao cliente e, depois o workshop de User Stories.

Gostei bastante também de algumas técnicas que foram apresentadas para tratamento do product backlog.

BTW, em geral o curso foi bacana e agregou conhecimento. Conversando com algumas pessoas mais experientes, que já utilizam Scrum, consegui concluir que esse tipo de curso é legal se você quiser saber se está no caminho certo.

O Scrum é um framework que não te dá muitas respostas. No lugar disso ele te oferece possibilidades de experimentar práticas novas e melhores a cada dia, desde é claro que você mantenha o foco na cultura e valores ágeis.

Neste ponto, acho que cumpri meu objetivo com o curso, que era de agregar mais conhecimento sobre o papel do Product Owner e ao mesmo tempo validar se estamos no caminho certo na utilização de Scrum e na manutenção dos valores ágeis.

Colocarei algumas fotos do treinamento em breve !!!

Amanhã começa a conferência. Neste momento estou escolhendo quais palestras irei assistir

Tentarei postar aqui minha visão sobre os próximos passos do evento.

Grande Abraço

André Nascimento

Bom dia pessoal,

Hoje começa em Porto Alegre o Agile Brazil 2010, evento para a comunidade ágil brasileira.

Nos dois primeiros dias de evento serão dados cursos como CSPO, CSM e XP, entre outros. Eu e alguns amigos estamos participando do curso de CSPO com o Alexandre Magno.

As expectativas para evento e para o treinamento são bem legais. Espero agregar um bom conhecimento na área de P.O, ponto que ainda é um pouco nebuloso no mercado.

Nos dias de evento (24 e 25), teremos as participações de Martin Fowler e Philippe Kruchten, além de nomes conhecidos no cenário nacional de desenvolvimento de software e práticas ágeis.

Aos poucos, tentarei adicionar algumas informações sobre o evento.

Abs

André Nascimento

Olá pessoal, tudo bem?

Fiquei um tempo sem postar nada aqui no blog porque a coisa no trabalho está um pouco corrida. Nossa equipe cresceu um bocado, iniciamos novos projetos, estamos de mudança para um escritório novo e várias outras novidades que aos poucos atualizo por aqui.

Para quem não sabe, trabalho na Stefanini IT Solutions como responsável executivo pela área de delivery de software em SP. Nossa estrutura é jovem, apaixonada por desenvolvimento de software e conta atualmente com alguns profissionais que são referência no Brasil em assuntos como: Scrum e Agile, SOA, Java e .NET. Por isso, você com certeza terá contato com uma empresa diferencial no mercado e terá oportunidades muito boas de crescimento e aprendizagem.

Com todo este crescimento, estamos intensificando as contratações novamente e neste momento buscamos profissionais com o seguinte perfil:

Líder de Projetos

Procuramos por profissionais organizados, multidisciplinares, auto-gerenciáveis, que tenham excelente background em disciplinas técnicas de desenvolvimento de software. É necessário conhecer profundamente análise e desenvolvimento de sistemas, principalmente em tecnologias orientadas a objeto.

Nossa área de desenvolvimento não trabalha com o modelo de gestão comando-controle, logo, o profissional precisa ser muito mais um líder do que gerente de atividades. Nossos times são multidisciplinares e auto-gerenciáveis e não precisam de alguém que fique perguntando a cada 5 minutos “Se está pronto!!!”. Por isso é importante que os candidatos saibam liderar e não comandar.

Se você é um excelente gerente de projetos, que comanda os “recursos” envolvidos baseado na gestão de atividades e do tempo, é mestre na confecção de cronogramas detalhados e conta com pós-graduação  e MBA em gestão de projetos, além de assinar SeuNome, PMP… Essa oportunidade NÃO É PARA VOCÊ !!!

As principais responsabilidades de um Líder de Projetos em nosso time:

• Auxiliar os times de projeto na execução de suas atividades;
• Consolidar as estimativas feitas pelos times em um plano de projeto e ajuda-los no cumprimento das metas;
• Representar o time perante o cliente e vice-versa,
• Ser um agende de negociação em assuntos de projeto e de desenvolvimento de software;
• Alinhar estratégias de execução de projetos com os líderes do lado do cliente;
• Gerenciar a comunicação ajudando-a a fluir para todos os envolvidos;
• Responder por números e controles financeiros dos projetos e;
• Auxiliar a gestão da área na alocação de profissionais para os projetos.

Olharemos com bons olhos profissionais que participem da comunidade de desenvolvimento de software, possuam blogs técnicos, participem de eventos como ouvintes ou palestrantes e que possuam o hábito constante de leitura e atualização.

Para finalizar, trabalhamos com algumas práticas ágeis (Scrum e XP) em nossos projetos, então é crucial que o profissional seja auto-gerenciável, comunicativo e multidisciplinar e que não seja adepto da gestão comando-controle tradicional. Inglês fluente também será um excelente diferencial.

Conhecimento técnico

Alguns dos conceitos e tecnologias que o profissional precisa conhecer:

• Alta capacidade de negociação e apresentação;
• Metodologias ágeis de desenvolvimento de software e gerenciamento de projetos;
• Background em gestão de projetos com práticas como PMI;
• Conhecimento de técnicas de dimensionamento de software como APF e UCP;
• Análise funcional de software.
• UML e Orientação a Objetos;
• Arquitetura de software para baixa plataforma e Web;
• Plataformas de desenvolvimento Java e .NET .
• Atuação em pré-vendas para elaboração de propostas e apresentação de soluções.

Só para reforçar, precisamos que você tenha um excelente background em desenvolvimento de software. Nosso processo de seleção envolve entrevistas com alguns líderes da nossa área, comigo e finalmente com toda a equipe

Pagamos um valor na média de GP.

Para quem estiver interessado, favor enviar email diretamente para mim: anascimento@stefanini.com

Boa sorte  e grande abraço !!!

André Nascimento

Alow Brasil !!!

Gostaria de lançar uma campanha no mercado de desenvolvimento de software, é a campanha: Programa Gerente !

Trata-se de uma campanha muito simples, mas difícil de aplicar, então vamos precisar de muita colaboração de todos para que ela aconteça.

Quase todo dia eu vejo um gerente reclamando de que sente muita falta da “época em que programava”, porque naquela época ele não tinha que fazer tanto trabalho inútil e que tinha uma visão muito melhor do resultado daquilo que ele construia.

A situação é a seguinte: Quem está numa posição gerencial acaba passando horas (as vezes o dia todo) trabalhando feito louco, mas se alguém perguntar o que ele fez nesse tempo, muitas vezes a resposta será: NADA !!! E o pior é que verdade, as atividades de gestão são complicadas e acabam não dando visão alguma de que algo realmente ficou pronto.

Se você é um gestor, sabe exatamente do que eu estou falando. O problema é isso acaba desmotivando profissionais e causando altos níveis de stress. Outro problema óbvio é que quanto mais um líder se distancia da realidade técnica no dia-a-dia, mais ele perde. Pessoalmente, eu nunca acreditei na história de que quanto mais se cresce na carreira, menos técnico você fica. Acredito que um profissional que siga para uma posição executiva tenha que generalizar mais a sua visão, mas isso não significa que ele tenha obrigatoriamente que jogar fora seu lado técnico.

Convivo com alguns executivos hoje que acabam sendo cegos o bastante para não olhar com bons olhos outros executivos que são técnicos e especialistas. Para esses, o lado técnico precisa necessariamente morrer para que o lado “administrador” domine. Que piada !!! Os melhores executivos com quem já tive a honra de trabalhar são técnicos e a mesma coisa serve para gerentes, líderes, coordenadores, etc.

Voltando à campanha, a idéia então é muito simples: Vamos fazer com que o gerentes, coordenadores, líderes e cia participem de algum projeto – por menor que seja – programando alguma coisa. Pode ser uma tela, uma rotina, um componente, não importa. O importante é que o “chefe” se envolva na programação e na construção do produto.

Vamos iniciar com isso aqui na Stefanini, ok? Então não dá pra dizer que isso não é aplicável numa grande empresa Vamos motivar todos os gerentes de projeto e líderes a dedicar um tempo para participar de um projeto junto com o time de desenvolvimento. A idéia também é que nessa atividade ele seja apenas mais um e não vista o chapeu de gerente.

Se você é um gestor ou coisa parecida, junte-se a nós nessa campanha… recupere aquele conhecimento técnico que você perdeu quando foi para o lado gerencial e que te fazia tão feliz. Você verá como suas atividades de gestão e liderança ficarão muito mais divertidas e darão um retorno muito maior para você, equipe e para sua empresa.

Aos poucos vou atualizar o blog com os resultados dessa experiência, ok?

Grande abraço e nos desejem sorte \o/

André Nascimento

Alow Brasil !!!

A resposta para a pergunta feita no título do artigo – segundo a minha opinião – é não. Claro que não !

Antes de discutirmos o porque dessa afirmação, acho importante estudarmos as origens das atuais medições individuais aplicadas pelos níveis gerenciais nos times de desenvolvimento de software.

Há muitos e muitos anos atrás eu já trabalhei em fábrica – uma de verdade, era de móveis de escritório – e lá era responsável por um setor de produção, o de corte de madeira. Era a primeira etapa da linha de produção. Além de liderar este setor e operar a máquina mais cara da empresa, eu fazia parte da equipe de PCP (Planejamento e Controle de Produção) da companhia.

Porque estou citando isso? Porque lá eu vivi de perto a implantação de um processo de linha de produção e de medição x análise da cadeia produtiva. É claro, que nossa indústria de desenvolvimento de software, quando decidiu aplicar os conceitos de fábrica de software tinha que trazer também vários dos processos de medição, análise e avaliação de desempenho utilizados na indústria convencional.

Funcionava mais ou menos assim:

1. As peças saiam em lote de uma máquina (por exemplo a minha) e iam para uma área de pulmão até que aquele lote fosse pego pela equipe da próxima máquina;
2. O tempo que um lote ficava parado no pulmão, era medido;
3. Assim que os operários da próxima máquina registravam a entrada do lote o tempo começava a contar e na liberação do lote tínhamos o tempo gasto nas peças;
4. Sempre que aconteciam paradas ou problemas (como a regulagem mal-feita de um centro de usinagem, por ex.), eram registradas as ocorrências pelo supervisor de linha;
5. Esse fluxo era executado para cada máquina da linha de montagem. Se não me falha a memória tínhamos cerca de 8 etapas na linha;”

Ora, este processo funcionava e ao final conseguíamos ter números importantes para melhorar nosso planejamento e controle da produção, como:

• Tempo médio para produção de um lote, para cada modelo de móvel que fabricávamos;
• Tempo médio para regulagem de cada máquina da linha, em cada turno de trabalho;
• Tempo médio de fabricação em cada etapa da linha;
• Ocorrências de manutenção, erros e outros pontos que paravam ou atrasavam a produção;
• Número de horas necessárias para fabricação de cada modelo, em cada etapa e em cada turno da fábrica;
• Finalmente, o valor gasto na produção de cada modelo, baseado é claro no número de horas e atividades gastas pelos operários;

Você percebe algumas semelhanças com indicadores de medição individuais que temos hoje em nosso mercado? Na indústria não eram medidos os times ou então a média do trabalho. Para se chegar aos números médios era necessário medir individualmente. Muitas vezes, não importava se o operário conseguia fazer uma peça de qualidade no tempo viável para entrega de um lote. Importava mais se ele estava dentro do tempo médio da produção. Já vi inclusive esses indicadores serem utilizados para demitir gente que não estava dentro da média !

Para a indústria convencional e suas linhas de produção, essa abordagem funciona de fato. Faz muito sentido esse tipo de medição e indicadores de produção. Infelizmente não é a mesma coisa para desenvolvimento de software. Os indicadores e a forma como eles são captados devem seguir outra abordagem.

Acabamos por implantar esse mesmo modelo de medições e análise e avaliações pessoais utilizado na indústria convencional e empurrando-o a força no desenvolvimento de software. O que utilizamos hoje nada mais é do que uma tentativa de medir a “produtividade” das pessoas num ambiente de desenvolvimento. Neste sentido, eu não acredito que medições individuais devam fazer parte de uma equipe ágil.

Tanto as medições individuais quanto os modelos de premiação / punição devem ser coletivos. Acho que este é um dos pontos positivos de se trabalhar num ambiente ágil.

Quais então são indicadores que fazem sentido numa equipe que trabalha sob cultura ágil? Vamos ver alguns:

1. Quantidade média de horas/pontos que o time atinge numa iteração;
2. Taxa de velocidade na implementação;
3. Número geral de erros entregues;
4. Metas alcançadas em cada iteração;
5. Satisfação do cliente /product owner (isso pode ser feito com uma pesquisa, por ex.);

Notem que estamos medindo indicadores do mesmo jeito, só que de uma forma mais superficial. Em resumo, não interessa o que cada um esteja fazendo de forma separada e sim o que o time conseguiu fazer de fato.

Então, você pode me perguntar: ” Mas isso vai deixar as pessoas acomodadas, pois ninguém estará medindo ou gerenciando o seu trabalho? “. Temos que fugir ao máximo do micro-gerenciamento e da ilusão do comando-controle se quisermos alcançar o objetivo de um time auto-gerenciável. O Scrum mesmo nos oferece alguns mecanismos para “medir” individualmente o desempenho de cada membro do time:

• Reuniões diárias;
• Sprints Reviews;
• Sprints Retrospectives;

E quanto a avaliação de desempenho individual, muitas vezes utilizada pelas empresas para aplicação de promoções de cargos e salários, também há outros mecanismos que podem ser aplicados. Pessoalmente eu nunca concordei com o formato  de avaliação de desempenho utilizado pelo mercado. Como podemos medir o desempenho isolado de uma pessoa se ela depende de outras para realizar o seu trabalho?

Esse sistema individual que temos hoje é responsável por promoções descabidas e por muitas vezes entregar o valor do trabalho de muitos para apenas uma pessoa. Então, se você ainda quer utilizar um modelo de avaliação, mas quer começar a pensar em como deixa-lo mais aderente a cultura ágil, faça o seguinte:

• Utilize os indicadores globais das equipes e projetos onde o profissional participou. Não é difícil traçar uma linha de atuação com essa abordagem;
• Para medir individualmente, nada melhor do que a velha “avaliação 360″. Neste modelo o profissional é avaliado por pessoas que trabalham com ele no dia-a-dia. Pessoalmente, acredito que essa seja uma das melhores formas de se avaliar alguém, principalmente os gestores.

O que falei foi apenas sobre indicadores de performance para profissionais / times. Ainda existem muitas outras formas de se avaliar e medir os projetos. São abordagens diferentes, medidas de forma diferente e que apresentam números diferentes, ok?

Métricas e indicadores são muito importantes, principalmente para empresas de serviços de software ou “fábricas de software”. Os clientes exigem esses números e a alta cúpula de executivos precisam disso para basear suas decisões. Agora, não dá para falar de cultura ágil e continuar medindo as pessoas da mesma forma que fazemos na indústria convencional.

Existem muitas empresas que medem tantos indicadores quanto possível e geram relatórios e books de gestão de centenas de páginas. Tudo desperdício, porque ninguém consegue analisar aquilo para tomar uma decisão na hora necessário. Os números devem ser os mais simples e diretos possíveis para possibilitar ao executivo ou mesmo ao time a tomada de decisões em tempo hábil. Para completar, indicador bom é aquele que reflete a cultura que está sendo aplicada pela empresa no projeto.

Grande abraço

André Nascimento

Alow Brasil !!!

Vou tocar num assunto delicado hoje, estou trabalhando neste post há algum tempo e como estou com uma crise de insônia terrível decidi termina-lo e publicar, ok? É um post um pouco extenso, então peço sua paciência para ler até o final

A motivação para este post, nasceu de algumas conversas com amigos e com executivos de mercado, também em algumas empresas que visitei nos últimos tempos e é claro do meu dia-a-dia de trabalho. Grande parte dessa motivação veio do fato de que existem ainda muitas empresas e pessoas que vêem este formato de “fábrica” de software como a salvação dos problemas, sendo poucos os que acabam percebendo que esse modelo criado para a indústria de software somente causou desperdício de recursos financeiros desde a sua criação.

Quero deixar claro que não estou criticando as empresas chamadas de fábrica de software, certo? Até nisso existe confusão. Os atuais fornecedores de software e serviços são denominados simplesmente de “fábricas de software”, principalmente pelos próprios clientes. Claro que você já ouviu a famosa frase: “Não vamos conseguir fazer internamente este projeto, manda pra fábrica…”

Bom, posto esses parâmetros, vamos então a uma definição resumida que encontrei no wikipedia:

Fábrica de Software é um conjunto de Recursos (Humanos e Materiais), Processos e Metodologias estruturados de forma semelhante àqueles das indústrias tradicionais, utilizando as melhores práticas criadas para o processo de desenvolvimento, testes e manutenções dos softwares.

Nos anos 90, quando estávamos vivenciando o ápice do processo de downsizing nas grandes companhias, passamos por um grande problema de produção nas empresas. O mercado contava com poucos profissionais especialistas e os que tinham essa especialização estavam se tornando cada vez mais caros. Por causa de vários deste problemas, pensou-se então que a saída seria “industrializar” o setor de serviços de software.

O pensamento foi simples:

1. O maior índice de trabalho que temos está na codificação de programas;
2. então precisamos de um número altíssimo de profissionais e estes precisam ser baratos;
3. como precisam ser baratos precisamos tornar suas atividades o mais manuais possíveis e eles devem estar pouco envolvidos com questões de negócio;
4. para conseguirmos isso precisamos de modelos e processos focados em atividades e de certificações destes processos.

Ora, no século passado tivemos um problema parecido com este, como ele foi resolvido? Com a criação da linha de montagem de Ford. A idéia básica era a de que muitas pessoas, distribuídas em funções e realizando operações repetitivas conseguiriam criar um produto semi-acabado ou até mesmo acabado. Era verdade que conseguiu-se com este modelo chegar ao impressionante tempo de 98 minutos para se fabricar um carro.

Pronto, temos então a linha de raciocínio que nos levou à criação do que foi em minha humilde opinião um dos maiores erros na história do setor de serviços de TI e desenvolvimento de software: A Fábrica de Software.

Linha de montagem industrial

Imaginou-se no início que a solução então seria segregar as atividades de desenvolvimento de software em várias áreas distintas, sendo as principais:

• Análise de negócio;
• Análisa técnica / modelagem;
• Codificação dos programas;
• Testes

Pronto, com essa divisão clara de “fases” e “disciplinas” num projeto de software ficava muito mais fácil de industrializar o processo, pois poderíamos então fazer qualquer uma dessas fases com pessoas diferentes, em locais diferentes, tudo orientado por um único processo. O modelo derivado deste pensamento pode ser expresso da seguinte forma:

Processo distribuído

Para sustentar essa fantástica “linha de produção”, o mercado teve que se basear totalmente num modelo de engenharia que já era adotado na era dos mainframes, o famoso processo Waterfall, ou cascata.

Modelo tradicional baseado em cascata

O processo Waterfall foi importante para a manutenção do modelo fabril porque dá uma idéia muito parecida com uma linha de montagem e não oferece o que chamamos de retro-alimentação em seu ciclo de vida. A idéia é de cada fase seja executada de forma separada, em momentos diferentes e por profissionais diferentes, alimentando com isso a segregação dos profissionais e baseando-se exclusivamente nos processos e na documentação.

Ok! Já vimos como este modelo foi criado, certo? Agora vamos analisar um pouco como está o mercado depois de quase 2 décadas da implantação deste modelo.

Chaos Report 2009

Você já deve conhecer esse relatório, não conhece? Já falamos sobre ele em outro post. O chaos report do standish group demonstra de forma muito clara como caminha o mercado de desenvolvimento de projetos de software. O leitor pode estar se perguntando: Mas o Chaos não diz que esses resultados são causados pelo modelo de fábrica de software. Com certeza, realmente não menciona, mas menciona problemas que foram causados por este processo e principalmente pela abordagem waterfall nos projetos de software.

Outro estudo que você já deve conhecer é o de que entregamos hoje em dia apenas 20% de funcionalidades que realmente serão utilizadas pelos usuários finais dos sistemas. Podemos ver este resultado na imagem abaixo:

Uso de funcionalidades em sistemas comerciais americanos

Consigo abordar alguns pontos cruciais para afirmar que o modelo chamado de Fábrica de Software não funciona. Vamos a alguns deles:

Gera e alimenta a segregação das equipes

O fato de dividir o projeto em fases => etapas => atividades, executadas por equipes diferentes que não se comunicam ou se comunicam pouco é nocivo para um projeto de software. As pessoas das pontas, que trabalham com o desenvolvimento do projeto não possuem contato com o cliente ou usuário final pois, uma vez que as fases de análise são terminadas a documentação funcional é enviada para a “fábrica” e só tem retorno quando o software está “pronto”.

É necessariamente baseado em documentação

O processo de fábrica tem a obrigação de se basear em documentação, já que não possui comunicação fluente entre os membros da equipe e principalmente com o cliente. Cada fase executada deve conter inúmeros documentos que descrevem como o software deve ser construído. Já trabalhei em projetos com processos em que tínhamos que entregar 32 artefatos de documentação ao longo do desenvolvimento. Esse número muitas vezes representava até 70% do esforço gasto no projeto. Sabe quanto tempo gastávamos com processos de qualidade e testes? Pois é, não sobrava tempo, muito menos dinheiro…

Outro ponto é que a empresa de fábrica precisa se basear nos documentos para se proteger do processo de contratação imposto pelo modelo de escopo fechado. Se aceitar alterações durante o projeto e elas não estiverem documentadas, o fornecedor terá que pagar a conta.

A base de nosso atual processo de software

Promove uma pseudo-previsibilidade

Como medimos o andamento de um projeto de fábrica? Com a famosa coluninha de % completo do project, certo? Se o projeto é separado em fases extensas e executado num modelo distribuído de fábrica essa prática torna-se indispensável. Agora a pergunta: Como podemos dizer que um projeto andou 50% se não temos uma unica linha de código escrita? Ainda não mostramos nada ao cliente, somente protótipos e documentos de requisitos.

Mudanças naturais decorrentes de um projeto são tratadas como alteração de escopo

Como já citei no item 2 as empresas precisam se basear no tal escopo fixo para executar o projeto. Qualquer alteração que ocorra durante seu desenvolvimento deverá ser tratada como mudança de escopo e negociada (paga), a parte. Se levarmos em consideração a cultura de punição que temos hoje para quem não consegue dimensionar um projeto de software com 100% de assertividade – tanto nos fornecedores quanto nos clientes – veremos que as mudanças ficarão engavetadas, engordando as estatísticas de funcionalidades entregues e não utilizadas.

Parte do pressuposto de que o desenvolvedor é simplesmente um operário

Ora, se todas as atividades que precisam de raciocínio já foram realizadas pelos analistas de negócio, arquitetos e analistas de sistemas nas fases de levantamento e definição do projeto então não só precisaremos do cara que escreve o código. É a atividade repetitiva de que fala o modelo fabril criado por Ford.

Este talvez seja o ponto onde a fábrica se saiu pior. Com este pensamento as empresas lotaram suas “fábricas” com estagiários e profissionais Jrs, realmente acreditando que codificar é simplesmente uma atividade braçal, e que o conhecimento especialista está nas mãos dos analistas, arquitetos, etc. Este modelo gerou, inclusive, a idéia de carreira que temos no mercado hoje (trataremos disso em outro post).

Meros codificadores braçais

Com essa atitude o mercado acabou gerando desenvolvedores de software que estão condicionados a receberem uma especificação detalhada e escrever código. A verdade é que temos um número absurdo de profissionais medíocres nas empresas. Pessoalmente acho que grande parte disso se deve ao fato de que limitamos estes profissionais com um modelo onde o programador deve ser burro e não onde unimos a solução com o desenvolvimento da aplicação.

Possui foco em processos e não em pessoas

Quando pensamos em fábrica de software somos levados a acreditar que neste modelo a dependência das pessoas é menor. A verdade é que isso não passa de marketing e é uma grande mentira! Um dos sonhos vendidos pelo modelo de fábrica é que o processo é mais importante e que ele suportará a ausência de qualquer pessoa. Afinal temos tudo muito bem documentado. Ora, sempre seremos dependentes de boas pessoas num projeto de software e para isso não importa o processo. Nunca acredite numa empresa que fale o contrário!

Não permite colaboração

Isso se inicia na contratação. O cliente não quer colaborar com o fornecedor e joga em seu colo todo o risco na contratação. Podemos analisar isso claramente nos processos de RFP que temos no mercado e até já falei isso em outro post. Como o fornecedor sabe que vai ficar com todo este risco, vai basear todo o desenvolvimento do projeto em documentos para que não tenha que assumir os problemas financeiros que certamente vão acontecer.

Neste modelo não há como se ter colaboração entre cliente e fornecedor, pois não há espaço para negociação no momento de mudanças. Sabemos que um projeto de software possui mudanças e que elas devem ser acomodadas e não negociadas. Mas para isso é preciso uma postura de colaboração, que não é compatível com o modelo de fábrica de software.

E no final…

Relacionamento cliente x fornecedor

Por todos este pontos e por diversos outros que podemos citar é que acredito que o modelo de fábrica de software está falido e que rapidamente chegará ao final. Este modelo vai amadurecer e evoluir naturalmente para outros modelos mais adequados ao desenvolvimento de projetos de software. Creio que a evolução natural será para o outsourcing baseado em processos colaborativos.

Nestes modelos, os riscos são compartilhados e as decisões tomadas em conjunto: Cliente x Fornecedor. Todos entendem que é melhor uma relação de ganha x ganha.

Podemos pensar em formas diferentes e mais efetivas para se desenvolver software e criar produtos melhores para as áreas de negócio nas empresas. Este é o nosso objetivo.

Grande abraço

André Nascimento