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

Alow Brasil !!!

Conforme prometido, só quero compartilhar o link para o álbum do Flickr com as fotos de nosso workshop de scrum com a equipe de desenvolvimento de software em SP da Stefanini.

Procurei deixar o treinamento no sábado o mais informal possível, por isso eu estou “fantasiado” de Serginho Malandro com esse boné, ok?

Alias, informalidade é uma das características que destacam este time. Além é claro de: União, seriedade, comprometimento, amizade, domínio técnico e uma dose de muito bom-humor, eheheh.

Segue o link para o álbum: Clique Aqui !!!

Grande abraço

André Nascimento

Alow Brasil…

Sempre existiram, existem e vão continuar existindo oportunistas em todo lugar. Em nosso país então, temos 15 por cada m². Estão em todo lugar, então… CUIDADO !!!

O que vemos hoje por aí é fantástico, chega a ser engraçado. O pior é que não é. Gostaria de apresentar o “scrum de prateleira”. A receita para fazer o seu é muito simples:

1. Pegue um cara que acha que conhece e pratica agilidade (geralmente porque fez um curso de 16 horas);
2. Junte com uma empresa (consultoria, software house, ISV, treinamento, etc), oportunista que não perde a chance de aumentar seu faturamento com um “novo produto”;
3. Acrescente uma pitada do bom e velho marketing nocivo da nossa indústria que “vende o sonho pra depois entregar um pesadelo”;
4. E, finalmente, coloque essa mistura em nosso bom e velho mercado prostituído de sempre.

Pronto, temos uma receita fantástica para o fracasso. E o pior? A culpa de tudo ao final será desse “tal de Scrum”.

A idéia que muitas empresas e pessoas possuem hoje quanto ao scrum está baseada na visão de um produto, uma caixinha que você compra numa loja, leva pra casa, abre e vive feliz. Agilidade não tem absolutamente nada a ver com essa idéia.

Experimente fazer esse teste: Procure no google algo como “scrum”. Simplesmente isso e você verá do que estou falando. A quantidade de empresas oferecendo: formação, treinamento, consultoria, etc, por aí é absurda.

O pior de tudo isso é que as pessoas estão caindo nessa! Tem gente achando que encontrou a formula mágica para todos os problemas da indústria de software, e que pra ter acesso a esse verdadeiro milagre é só fazer mesmo um curso e “ir pra cima”. Por favor, eu não estou falando que você não deva fazer um curso, ok? Ele é indispensável (desde que seja com alguém que realmente conheça agilidade). Mas, simplesmente pegar o scrum “enlatado” e colocar na sua empresa não é algo que dará resultados (pelo menos não positivos).

Muitas empresas estão com um foco total em ganhar dinheiro com o scrum hoje em dia e infelizmente prestam um desserviço a comunidade ágil. Essas empresas vêem o scrum como mais uma oferta de serviço, quando ele não é apenas isso. Ao partir para uma processo ágil você muda completamente a cultura da sua empresa, ou pelo menos da área onde se está trabalhando com agilidade.

Em minha opinião, o foco deve ser nas pessoas, sempre. A mecânica do processo por si só não vai resolver problema nenhum, é nas pessoas que devemos investir. O processo e a mecânica são meros coadjuvantes. Tentar utilizar/vender scrum sem entender isso é um grande tiro de 12 atrás da nuca

Por isso é que temos um número absurdo de pessoas fazendo reuniões diárias e pendurando pseudo-kanbans nas paredes e se dizendo especialistas em scrum ou em agilidade. Se está funcionando pra você, ótimo \o/ O problema é quando não funciona, não é? Neste momento teremos um novo e grande culpado: o SCRUM.

Se quiser adotar práticas ágeis na sua empresa ou equipe, por favor, não passe na loja. Esqueça o “produto” scrum na prateleira e não dê atenção para ele. Primeiro, leve para casa os princípios da cultura ágil e tente pratica-los. Nessa prática, o scrum te ajudará com algumas dicas e processos, nada mais !

Se continuarmos a pensar em agilidade como um produto de prateleira, teremos uma triste verdade daqui a pouco tempo…

Futuro com o Scrum de Prateleira

Leituras que podem colaborar:

• O que matou o Rup pode matar o Agile – Rodrigo Yoshima.
• Eu não uso Scrum porque Scrum não funciona – Tucaz.

Grande abraço

André Nascimento

Fala Brasil !!!

Nos dias 12 e 13 de março realizamos  com o time do Software Delivery Center, aqui na Stefanini em São Paulo o workshop de desenvolvimento ágil com Scrum. Alguns podem estar se perguntando: “Mas você não disse que já trabalham com Scrum aí na Stefanini? Como assim?”.

Pois é, nós trabalhamos sim \o/ Mas, felizmente nos ultimos meses tivemos um crescimento bastante positivo e várias pessoas foram agregadas ao time do Software Delivery Center. Algumas delas, vieram do mercado já conhecendo alguma coisa sobre desenvolvimento ágil, outras nunca tinham sequer ouvido falar.

Tenho notado com o passar do tempo que até mesmo as pessoas que dizem conhecer bem sobre agilidade, de fato, conhecem pouco. Isso claro é porque poucas pessoas entendem e conseguem colocar em prática questões culturais de agilidade. Há aqueles que tentam, mas acabam esbarrando em chefes/gerentes/diretores que não querem nem saber. O ponto positivo nessa equipe é que o “chefe” já está bem convencido, eheheh.

Como tivemos esse aumento significativo em pouco tempo (cerca de 25 pessoas nos ultimos 4 meses), decidimos que já era hora de realizar um workshop decente com todo mundo. Eu estava começando a ficar preocupado com um pessoal mais novo que olhava para os Kanbans e não entendiam nada, ou pior, achava que Scrum se resume aos Kanbans :S

Falando rapidamente sobre o workshop, tivemos todos os membros da equipe presentes nos dois dias (ok, tivemos 1 ou 2 ausências). O formato foi o mesmo que utilizamos em clientes da Stefanini, claro, focado no dia-a-dia da equipe. Como estou com o “chapeu” de gestor desse povo, acredito que foi mais fácil realizar o workshop pois estou com eles todos os dias e sei bastante coisa do que se passa com o time.

O fato de trabalharmos juntos não diminiu as discussões, opiniões e pontos de vista do pessoal. Isso é o que eu considero um dos maiores ganhos que temos vivido com agilidade por aqui: Todo mundo tem voz e a opinião de todo mundo conta!

Tivemos mais uma vez a dinâmica da fábrica de aviões (fantástica). Realmente é um dos pontos fortes do workshop!

Vou compartilhar algumas fotos do workshop com vocês. Em breve vou organizar meu Flickr, prometo

Equipe do Software Delivery Center da Stefanini

Pessoal na sala do workshop

Dominando a "padoca" da esquina na hora do almoço.

Algo parecido com um "gerente". I don't think so!

Ok! Nem só de trabalho vive o homem. Happy Hour após o workshop!

Mais uma do Happy!

O principal ganho que tivemos com este workshop foi ver que o pessoal entendeu o que realmente é importante em trabalhar com agilidade e scrum. Claro, nem todos ainda acordaram, ainda não temos o resultado que queremos, mas sinto que estamos no caminho. O importante é que tentamos colocar em prática os princípios da agilidade em nosso dia-a-dia e isso está refletindo positivamente em nossos projetos.

Espero que daqui há 1 ou 2 meses tenhamos que parar novamente todo mundo para um novo workshop sobre agilidade.

Até lá! Grande abraço…

André Nascimento

Alow brasil !!!

Estamos com vagas em aberto aqui na Stefanini em São Paulo. Os profissionais trabalharão conosco na estrutura do Software Delivery Center.

A Stefanini IT Solutions é uma empresa de grande porte – acho que não preciso falar muito dela – atualmente é a maior empresa de serviços de TI do Brasil. Trabalhamos na estrutura técnica de fábrica de software na cidade de São Paulo.

Abaixo os dados de divulgação das vagas:

Desenvolvedor Sênior e Pleno – Java

Perfil do profissional

Procuramos por profissionais organizados, multidisciplinares, auto-gerenciáveis e especialistas em disciplinas técnicas de desenvolvimento de software. É necessário conhecer profundamente análise e desenvolvimento de sistemas na linguagem Java e orientação a objetos.

Nossos projetos atuais utilizam Java como ferramenta de desenvolvimento, mas daremos preferência para aqueles que conhecerem mais do que uma plataforma de desenvolvimento (.NET, Ruby, etc).

Mais do que especialistas numa única plataforma, estamos procurando especialistas e entusiastas em desenvolvimento de software que não se limitem a somente uma abordagem e/ou plataforma.

É importante que os candidatos sejam entusiastas do desenvolvimento de software e de preferência participem da comunidade de software. Conhecimento de abordagens como DDD e TDD e boas práticas de programação serão um grande diferencial (básico né?). Também olharemos com bons olhos profissionais que tiverem blogs técnicos e que possuam o hábito constante de leitura.

Para finalizar, trabalhamos com algumas práticas ágeis (Scrum) em nossos projetos, então é crucial que o profissional seja auto-gerenciável, comunicativo e multidisciplinar. O inglês deverá ser bom ao menos para leitura. Níveis avançados serão considerados um grande diferencial, pois temos várias oportunidades de interação com clientes e parceiros fora do Brasil.

O que diferenciará o perfil como Sr. ou Pl. será a profundidade de conhecimento do profissional e seu tempo de experiência com as tecnologias relacionadas.

Conhecimento técnico

Alguns dos conceitos e tecnologias que o profissional precisa conhecer:

• UML e Orientação a Objetos
• 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
• Design Patterns
• Banco de Dados (Oracle ou SQL SERVER)

Interessados, favor mandar CV com as seguintes informações para o email vfreitas@stefanini.com.

1. Nome dos blogs que frequenta ou listas de que participa;
2. Ultimos 3 livros lidos;
3. Qual o seu valor atual;
4. Qual a sua pretensão salarial;
5. Referências pessoais e/ou profissionais

É importante mencionar que está respondendo ao anúncio do meu blog.

Boa sorte !!!

André Nascimento

Há algum tempo venho observando e registrando alguns fatores culturais envolvidos nas relações cliente x fornecedor, empresa x empregado, etc.

Semana passada, enquanto estava em Belo Horizonte e participava de uma apresentação sobre desenvolvimento ágil e scrum para um cliente americano aqui da Stefanini - a HNI Corporation – percebi o quanto esses fatores influenciam em nosso trabalho e principalmente na adoção de um aproach ágil para o desenvolvimento de software.

Vamos começar com essa imagem, que acredito que todos já devem ter visto em alguma apresentação sobre desenvolvimento ágil:

O Iceberg do Scrum

Quem está acostumado a falar sobre agilidade sabe que ela representa a visão de um processo ágil e sua adoção, onde temos:

O topo do iceberg, que representa o que todo mundo vê no scrum como mais importante,

• Processos – Ciclo, cerimônias, etc;
• Papéis – Product owner, Scrummaster, Time, etc;
• Ferramentas – Kanban, gráficos, etc

E a parte de baixo do iceberg que representa o que realmente importa e abrange um processo ágil,

• Auto gerenciamento;
• Comprometimento de todos;
• Comunicação aberta;
• Mudança cultural.

Desde o ano de 2008 tenho feito muitas apresentações sobre agilidade para os mais diversos públicos, desde equipes de desenvolvimento até CIOs e CEOs de empresas aqui no Brasil. Essa imagem do iceberg reflete muito o nosso cenário para adoção de agilidade. Quando falamos sobre a avalanche de mudança cultural que uma abordagem ágil oferece para a empresa todos ficam bem preocupados (principalmente executivos).

O que me chamou muita a atenção no caso da HNI é que eles viram a realidade diária deles na parte de baixo do iceberg. Ao final da apresentação o CIO da empresa nos disse bem animado: “Fantástico, já temos toda a base do iceberg e nem sabemos o que é Scrum. Agora só precisamos pensar em como e onde utilizarmos o processo para melhorar mais os nossos projetos”. Confesso que fiquei chocado…

Depois de ter digerido um pouco melhor a apresentação e seu impacto, cheguei a conclusão (meio que óbvia), de que o mercado brasileiro ainda precisa de um bom tempo para acreditar em desenvolvimento ágil e implementa-lo de fato. Hoje, temos uma cultura no desenvolvimento de projetos de software que está muito longe de ser colaborativa e auto-gerenciável.

Se pensarmos em nossos modelos de contratação – podemos começar vendo a questão sobre RFPs – já podemos ver que a coisa toda é direcionada para desviar dos problemas, antes mesmo de que aconteçam. Quase ninguém está interessado em fazer software com qualidade, porque a área ainda é tida como “buraco negro” das empresas, que só sugam recursos e não devolvem nada.

A verdade é que a grande maioria das empresas pensa no Scrum apenas como mais uma oferta de serviço: “Está na moda, então vamos botar no menú e ver o quanto vende…” Poucas pessoas e empresas estão interessadas na mudança cultural que é inerente a agilidade, como: Tratar profissionais como pessoas, incentivar o auto-gerenciamento, abolir o comando-controle, abrir mão da visão industrial de software, etc.

A questão é muito mais séria e complicada do que pensamos, pois as diferenças culturais são realmente muito grandes e pesadas. Estou pensando seriamente se um dia saberemos no mercado brasileiro o que é agilidade de verdade. É necessário abrir mão de muita coisa que se vê como essencial para aproveitar o valor dos princípios ágeis.

Esse pensamento me leva a algumas questões, quase que existenciais como:

1. O que precisamos fazer para ser ágeis de verdade no Brasil?
2. Como incentivar mudanças culturais nas empresas e provar que elas trazem resultados melhores do que as abordagens tradicionais?
3. Como destruir o enraizamento de um modelo de mais de anos num país como o Brasil?
4. Como convencer executivos sobre auto-gerenciamento num país onde profissionais ainda compram atestados médicos para não serem descontados por uma falta?

Em minha opinião, ainda temos muitas questões que precisam ser formuladas e respondidas.

Até a próxima, grande abraço !!!

André Nascimento

Alow brasil !!!

O título desse post já diz muita coisa, certo? Vamos falar um pouquinho sobre certificações.

Em primeiro lugar, quero que você leve em conta que eu nada tenho contra certificações. Mas, quero levantar algumas  questões que julgo importantes.

Então, vamos lá.

Todos sabemos que nosso mercado chegou a um estágio de incrível prostituição e um dos grandes responsáveis por isso são as grandes consultorias de serviços. Elas incentivaram as piores práticas de gestão de pessoas, que hoje infelizmente são seguidas também pelas médias e pequenas empresas de serviços. Todo mundo é recurso, não é?

Já convivemos com o termo “certificação” há algum tempo em nossa área. Não vou resgatar a história lá atrás, tudo bem? Mas, se levarmos em conta, de uns anos pra cá tivemos o que podemos chamar de um “boom” nos modelos de certificação e no número de profissionais certificados.

Você já deve ter visto muitas vezes anúncios de emprego exigindo um profissional certificado, ou mesmo quando foi pedir uma promoção que precisava de mais certificações para demonstrar seu domínio sobre o assunto.

O fato é que o mercado de consultorias valoriza e muito um profissional que possui certificações e cada vez mais exigem isso.

No entanto, existem dois tipos de profissionais que se certificam. Vamos olhar cada um deles:

O cara que domina um assunto, tem experiência e se certifica para homologar este conhecimento – Este é o cara que faz justiça as suas certificações. Ele possui experiência prática em todos os níveis abordados pela sua certificação e não é somente um vendedor de tecnologia ou produto. Se chamado para resolver um problema demonstrará que realmente é um especialista no assunto e mesmo que não domine todas as técnicas possíveis para resolver um problema, usará seu perfil investigativo para aprender novas formas e no fim vai dar um jeito.

O cara que estudou o assunto a fundo, leu muito material e foi fazer a prova – Este profissional participa de fóruns de discussão, faz diversas apresentações nos mais importantes eventos da comunidade e adora exibir seus títulos a qualquer momento (quem não adora assinar Fulano de Tal, PMP por exemplo?), e quando chamado para resolver um problema, já carrega seu fantástico notebook com kilos de material com propagandas. O problema é que esse cara geralmente não tem experiência prática com o assunto. Ele gosta muito de ler, mas não consegue resolver um problema simples. Além do que, passa tanto tempo se dedicando as apresentações que faz que acaba não tendo tempo para participar da entrega de um projeto de verdade.

Infelizmente, o segundo tipo de profissional está dominando o mercado atual. Não são raros os casos em que conhecemos profissionais com “baldes” de certificações que não justificam nada. A qualidade de seus trabalhos é completamente medíocre.

Mais uma vez vemos que o próprio mercado é um dos grandes culpados disso. Ora, como avaliamos os profissionais hoje? Isso é assunto para mais um post, mas para resumir: Não temos gente qualificada para selecionar os profissionais hoje em dia e a certificação ajuda muito neste trabalho.

Vamos pegar como exemplo uma das certificações que está na moda: A tal de ScrumMaster. Este é um exemplo perfeito de certificação que não serve pra nada. Desculpe-me os CSTs, ok?

Outro dia, realizando uma apresentação numa empresa ouvi o seguinte comentário:

“Ah, conheço um cara muito especialista em Scrum, ele é um Scrum Master certificado”.

Para se tornar ScrumMaster até há pouco tempo era só participar de um treinamento de 16 horas com um CST e receber o certificado. Que especialidade há nisso? Pelo amor do bom Deus!  Este tipo de certificação é uma das coisas que autorizam pessoas totalmente desqualificadas a falar de um assunto para o mercado e se mostrarem como especialistas de algo que pouco entendem, fora aquilo que leram num livro.

Outro exemplo que podemos ver na comunidade de desenvolvimento de software: Quantas vezes já precisamos aqui na empresa de ajuda de especialistas e corremos atrás de profissionais certificados, com títulos, etc. Nenhuma vez consegui trazer aqui um “especialista” que conhecesse muito mais do que a minha própria equipe.

Com tudo isso, gostaria que você pensasse um pouco sobre a importância de ser realmente certificado em algo. É um titulo importante. De fato, os grandes profissionais com quem trabalhei e que eram realmente especialistas, não tinham nenhuma certificação.

Para finalizar, gostaria de compartilhar algo sobre o processo de seleção que fazemos aqui na empresa. Nós não nos importamos nem um pouco se o profissional tem ou não certificações. Peço ao RH da empresa que não coloque nada relacionado a certificações ou mesmo a formação acadêmica quando mandamos uma vaga para o mercado.

Agora, se o candidato coloca em seu CV aquela lista gigante de certificações, com certeza ele terá um trabalho bem grande para justificar seu conhecimento para o pessoal que vai entrevistá-lo. Exemplos:

• Se o cara diz que tem meia dúzia de certificações em desenvolvimento da microsoft ele tem que saber descrever como é que o framework .NET funciona;
• Se o cara diz que tem certificação Oracle, ele tem que saber dizer quais são os 5 passos que a engine do banco faz quando vai processar uma procedure;
• Se o cara diz dominar todos os design patterns do GoF e etc, ele terá que citar quais deles já utilizou num projeto e que problema foi resolvido com eles. Geralmente não aceitamos nada de MVC ou DTO, ok?

E então: Qual será a sua próxima certificação?

Links interessantes:

Cuidado com os especialistas

Abs

André Nascimento

Alow Brasil !!!

Nos dias 22 e 23 de fevereiro estive em Porto Alegre ministrando um workshop de Scrum e práticas ágeis no estúdio de games Ubisoft Brasil.

O pessoal já conhecia algumas práticas ágeis pois um de seus produtores havia participado de outro workshop e levado o conceito para dentro da empresa.

Algumas coisas que a equipe já utilizava no dia-a-dia:

• Entregas parciais de funcionalidades de um produto;
• Planejamento com todos os membros do time, envolvendo sempre pessoas das áreas de: Criação e arte, design e programação;
• Kanban para alinhar as atividades do time e comunicar ao pessoal sobre o andamento dos projetos;
• Reuniões diárias;
• Manutenção de um Product Backlog;

O objetivo era alinhar o conhecimento de todos os membros da equipe e fortalecer as bases do Scrum e da agilidade, pois nem todos tinham uma idéia clara dos princípios ou do porque realizavam algumas das cerimônias.

Decidimos então fazer um workshop muito baseado nos princípios  ágeis, abordando pontos como:

• Origem do Scrum e as principais diferenças com os processos tradicionais;
• Papéis e suas responsabilidades;
• Ciclo de vida e dia-a-dia de uma equipe ágil;
• Artefatos e cerimônias;

Tivemos cerca de 30 pessoas no treinamento, entre elas: Designers, programadores, produtores e testers. Todo o time do estúdio participou o/

Pessoal da Ubisoft no workshop Agile em POA.

Conseguimos tirar muito proveito do workshop, principalmente nas discussões com o pessoal. Foram levantadas questões pertinentes ao desenvolvimento ágil no cenário da Ubisoft –  desenvolvimento de games.

Existem várias particularidades que a área de games possui para a utilização de práticas ágeis e são grandes os desafios que essas particularidades impõe. Algumas coisas interessantes que discutimos:

1. Quem é o melhor Product Owner para o desenvolvimento de um jogo? Existem inúmeras pessoas envolvidas na criação, direcionamento e estudo do game. Difícil escolher somente uma pessoa para fazer isso;
2. Neste cenário é difícil contar com uma equipe totalmente multidisciplinar, pois é muito comum a existência de especialistas. Exemplo: Uma estória envolve criação, design e programação. Como um programador de física vai “meter o bico” numa estimativa de design e vice-versa na hora do planning poker?
3. Existem critérios de aceite bastante subjetivos. Exemplo: Eu espero que esse jogador pule e que isso seja divertido :S. Subjetivo, não?

Existiram vários outros pontos em que paramos, pensamos, discutimos e chegamos a algumas conclusões muito interessantes. No final, duas coisas ficara bem claras:

1. Processos ágeis se encaixam totalmente na cultura e realidade de uma empresa que faz jogos, muito mais do que qualquer outro processo tradicional �/
2. É preciso muito trabalho, dedicação e criatividade de todo o time para implementar práticas ágeis e adaptar alguns pontos que não fazem sentido utilizar.

O workshop contou com várias dinâmicas, que demonstraram na prática como funciona trabalhar com agilidade no dia-a-dia. A melhor delas foi a da fábrica de aviões, todos gostaram muito Alias, deirxo meus agradecimentos aos grandes Flávio Steffens de Casto e Rafael Prikladnicki que, levando muito a sério o sentido de comunidade disponibilizaram a dinâmica criada por eles. Parabéns, tanto pela dinâmica quanto pelo compartilhamento Srs.

Pessoal tentando criar o protótipo do avião!

Testando o protótipo

Ao final, fizemos uma retrospectiva sobre o workshop e o pessoal deu um feedback muito positivo. Como ponto negativo, os designers e artistas pediram para eu não mencionar tanto assuntos de programação no “próximo” workshop num estúdio de games. My bad pessoal, mas pedi um desconto por ser da área de software e tudo ficou bem.

Muito obrigado a todos da Ubisoft que participaram do workshop. Espero que vocês tenham sucesso no dia-a-dia com práticas ágeis !!!

Referências:

Se você quiser saber mais a respeito de processos ágeis na indústria de games, segue um livro interessante:

Amazon: Agile Game Development With Scrum

Youtube: EVE Online Fanfest 2009 – Scrum & Agile

EVE Online Fanfest 2009 – Scrum & Agile

Abraços

André Nascimento