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

Iae pessoal, blz? Sei que meu último post já foi sobre oportunidade de emprego e quero deixar claro que meu blog não está virando um novo “apinfo”, ok? eheheh. Continuo com pouco tempo para escrever e precisando contratar mais (para ter mais tempo). Então lá vai…

Temos um certo trabalho e dedicação em contratar somente BONS profissionais. Levamos isso realmente a sério em nosso time, pois acreditamos que boas pessoas é que realizam grandes projetos. Não estamos a procura de “recursos” para desenvolvimento de meia-dúzia de projetos, queremos sim profissionais que contribuam para a empresa e para a equipe, sendo diferenciais.

Nossa cultura é de desenvolvimento ágil, por isso é imprescindível que os candidatos conheçam e apóiem essa cultura.

Precisamos agora de Analistas Desenvolvedores de Software, em nível Sênior e Pleno, para as seguintes tecnologias: Java, PHP e .NET. Temos várias vagas em cada uma dessas tecnologias.

Para todas elas, é necessário que o candidato tenha o seguinte skill pessoal e técnico:

• Orientação para auto-gestão;
• Capacidade para atuar em times de desenvolvimento de software, possuindo excelente comunicação;
• Multidisciplinaridade nas áreas de projeto (análise, desenvolvimento e testes);
• Conhecimento efetivo em Orientação a Objetos;
• Modelagem de requisitos de software, baseado em UML;
• Conhecimentos em arquitetura de software e Design Patterns;
• Testes de software, principalmente cultura de testes unitários;
• Modelagem de dados e implementação em bancos de dados como Oracle e SQL Server;
• Conhecimento e prática em abordagens como DDD e TDD garantem pelo menos 50% da contratação (rs).

Os Skills para cada plataforma:

JAVA

• Servlets, JSP, JSTL;
• Servidor WEB (Tomcat);
• Servidor de Aplicação (JBoss ou Glassfish ou Websphere ou Weblogic);
• EJB;
• Framework ORM (JPA ou Hibernate);
• Framework MVC (Struts ou JSF ou Spring MVC);
• Ajax;
• Desejável JQuery ou Prototype.

.NET

• Framework 3.0 em diante;
• C#, VB.NET e Visual Basic 6.0 (para mexer em legados);
• Visual Studio 2005/2008/2010;
• N-Hibernate e LINQ;
• JQuery.

PHP

• Desenvolvimento em PHP 5;
• Cake;
• Postgree SQL;
• Ambiente Linux;
• Arquitetura de ambientes PHP.

Se você possui esses requisitos pessoais e técnicos e quer fazer parte de um excelente time de desenvolvimento de software, envie seu CV para mim (anascimento@stefanini.com), com o título “VAGA DESENVOLVEDOR”. Só escreva em seu CV o que você realmente conhece, pois vamos validar TUDO que estiver escrito lá com relação a conhecimento técnico. Então, se você só conhece MVC, não diga que domina Design Patterns, certo?

Peço por favor que você só envie seu CV se realmente possuir os Skills das vagas. Eu não trabalho no RH e não vou guardar CVs para “outras oportunidades” na empresa. Por isso estou dando meu email direto para você. Então só envie se o seu perfil atende aos requisitos.

Grande abraço e boa sorte !!!

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 !!!

Post rápido para fazer uma propaganda básica, ok?

É que o Gilberto Holms, arquiteto java/soa aqui da nossa equipe na Stefanini iniciou seu blog sobre arquitetura. O cara é um monstro, simplesmente não tem o que falar dele. Pessoal costuma dizer que ele é o ser mais “ignorante” da equipe. Não sabe mesmo brincar…

Altamente recomendado para quem quiser saber um pouco mais sobre arquitetura de software em java e SOA.

Para acessar o blog é só clicar AQUI !!! Também estará nos meus links …

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