O olho do dono que engorda o ROI
Saudações pessoal!!
Nas últimas 2 semanas, tenho tido discussões frequentes com os membros do #SDC da stefanini a respeito das dificuldades que temos enfrentado na adoção de agile em grandes empresas.
Depois de muitas conversas uma das conclusões que chegamos é que o alto número de intermediários e cargos, e a política de aprovação de orçamentos emperra a adoção de agile em grandes empresas. Infelizmente em grandes empresas lidamos com intermediários que muitas vezes não estão preocupados em maximizar o ROI, e sim em contratar uma empresa que sirva de seguro para seu cargo. Há uma frase do mundo de TI que diz “Ninguém nunca foi demitido por ter contratado a IBM” que frisa bem este espírito, para quem não entendeu significa que quando o projeto não der certo a defesa da pessoa que contratou será “Mas eu contratei a IBM, se eles não resolveram o problema, quem resolveria?”, algo que não aconteceria, por exemplo se este mesmo projeto fosse realizado por uma pequena empresa, a culpa pelo projeto falho cairia sobre o contratante que não soube escolher um bom fornecedor para realizar o seu projeto.
Este contratante que geralmente não é o dono, mas tem um cargo executivo, tem um budget pré-estabelecido para gastar com determinados projetos. Não interessa para ele investir tempo em quanto do escopo será realmente utilizado e qual a prioridade dos itens necessários para o projeto, para ele é muito mais fácil elaborar uma RFP (e aqui temos alguns dos problemas da RFP) informando quais itens a consultoria terá que assumir, e então passar o risco do projeto para a consultoria, que em troca colocará a famosa “reserva de contigência”, popularmente conhecida como gordura, no projeto, para se proteger do risco.
É claro que se isto fosse feito de modo a diminuir o risco para a consultoria a empresa que contrata iria gastar menos. É como contrair um empréstimo, quando a empresa contrai um empréstimo dando garantias como patrimônios que o empréstimo será pago o valor do juros é menor, quanto maior o risco, maior o juros, e consequentemente maior o gasto que a empresa vai ter para ter o mesmo valor de empréstimo.
Mas qual seria o interesse em investir tempo para economizar um valor que ele já tem aprovado para gastar? E o pior, este valor na verdade para ele é um valor virtual, pois não sairá do bolso dele… Será que existe uma forma para grandes empresas quebrarem este paradigma?
Existe um grupo chamado “Beyound Budgeting Round Table” que propõe não só uma nova forma de controle orçamentário, mas também uma nova forma de gestão, já aplicada em empresas como Toyota, Unilever e o banco UBS, entre outros. Para quem quizer se aprofundar um pouco mais segue uma página sobre o que é beyound budgeting da MetaManagement, que através do Niels Pflaeging, representa o Beyound Budgeting no Brasil.
Não sei quanto tempo ainda levará para que presidentes de empresas despertem para este tipo de gestão que é cada vez mais necessário neste mundo tão dinâmico, mas acredito que as empresas que despertarem primeiro terão um diferencial em gestão de custos e investimento em capital humano.
Para finalizar, deixo vocês com a palestra do Niels Pflaeging, e um artigo da HSM.
Vamos jogar tênis ou frescobol?
Saudações pessoal!
Peço desculpas a todos pela demora no post, mas tive 2 semanas de férias e quando voltei parecia que tinha saído por uns 6 meses… =D Agora que as coisas voltaram para os trilhos volto a ter um tempo para blogar!
Em uma das empresas que prestei consultoria havia uma faixa no andar de desenvolvimento com a seguinte pergunta: “Estamos jogando tênis ou frescobol?”
Esta frase, baseada no texto do Rubens Alves utilizada para refletir os tipos de relacionamentos entre casados também pode ser aplicada no relacionamento entre cliente x fornecedor ou até no relacionamento entre a equipe interna.
De acordo com Rubens Alves:
“O tênis é um jogo feroz. O seu objetivo é derrotar o adversário. E a sua derrota se revela no seu erro: o outro foi incapaz de devolver a bola. Joga-se tênis para fazer o outro errar. O bom jogador é aquele que tem a exata noção do ponto fraco do seu adversário, e é justamente para aí que ele vai dirigir a sua cortada – palavra muito sugestiva, que indica o seu objetivo sádico, que é o de cortar, interromper, derrotar. O prazer do tênis se encontra, portanto, justamente no momento em que o jogo não pode mais continuar porque o adversário foi colocado fora de jogo. Termina sempre com a alegria de um e a tristeza de outro.
O frescobol se parece muito com o tênis: dois jogadores, duas raquetes e uma bola. Só que, para o jogo ser bom, é preciso que nenhum dos dois perca. Se a bola veio meio torta, a gente sabe que não foi de propósito e faz o maior esforço do mundo para devolvê-la gostosa, no lugar certo, para que o outro possa pegá-la. Não existe adversário porque não há ninguém a ser derrotado. Aqui ou os dois ganham ou ninguém ganha. E ninguém fica feliz quando o outro erra – pois o que se deseja é que ninguém erre.”
Embora em um projeto todos devessem lutar pelo sucesso do mesmo, da mesma forma que existem os casamentos tênis e frescobol, existem os times / clientes tênis e frescobol:
Cliente frescobol
Aponta os erros de forma construtiva. Ajuda o time a resolver impedimentos e guia o time para atingir os objetivos. Se coloca à disposição para resolver dúvidas, afinal o que mais quer é ter um projeto com qualidade.
Cliente tênis
É o oposto do cliente frescobol, se arma de documentações e evidências, quando existe algum erro, no lugar de buscar a melhoria de forma construtiva usa como justificativa para tirar os problemas dele da reta e jogar o problema para o fornecedor. Tem uma postura “Buy and forget” se ele está pagando para que você resolva o problema não quer ficar explicando, se possível quer explicar uma vez só no início do projeto e chegar só no final para dizer que estava tudo errado…
Times frescobol
Busca a melhoria contínua da equipe. Abraçam o projeto, e ajudam uns aos outros não importando se a ajuda ocuparia uma parte do tempo que poderia ser utilizada na realização da tarefa da pessoa. No lugar de enviar emails avisando que tiveram problemas tomam atitude e tentam resolver os problemas.
Times tênis
Cada um se preocupa com a sua tarefa, não importando se o projeto não dará certo por falta de colaboração, pelo menos “fiz a minha parte”. Se algo dá errado tentam justificar com os erros do cliente, ele provavelmente não soube explicar. Não se preocupam com o sucesso do projeto, se na minha máquina funciona, então não é problema meu.
Cabe a cada um de nós identificarmos este tipo de comportamento e escolhermos se queremos ter times e clientes tênis ou frescobol.
Retrospectiva Encontro Ágil 2010
Saudações Pessoal!
Aconteceu ontem em São Paulo a 3ª edição do Encontro Ágil. O formato do evento foi bem interessante por ter debates e open spaces sobre alguns assuntos no lugar de palestras, vou relatar aqui um pouco do que vi sobre o evento.
A primeira sessão que vi foi facilitada pelo Alexandre Magno o assunto era Product Vision Games. Ele demonstrou algumas formas de se fazer uma boa visão do produto, nos reunimos em trios e montamos a visão de um produto. Me reuni com o Carlos Leite da empresa Freeddom, e outra pessoa (que não me lembro o nome =/ ), montamos a visão de um produto que tenho no meu backlog a tempos, um site de troca de livros. Um item interessante que fizemos foi o “velório do produto” que seriam fatores que se não forem levados em conta podem fazer nosso produto não ter sucesso nenhum. Este ponto é interessante pois, em alguns casos podemos decidir que nem vale a pena fazer o produto. Ele sugeriu algumas literaturas, como Innovation Games e a técnica Design Thinking .
Logo após começaram as sessões de open space, participei da sessão de Lean e Agile, iniciada pelo Christopher Thompson do Lean Institute Brasil . O Thompsom é formado em engenharia naval e tem um grande background de Lean, sua intenção era entender um pouco mais do mundo do software, pois tem sido contratado por várias empresas deste setor, para aplicar uma abordagem lean.
A sessão foi bem interessante, embora alguns atritos entre alguns membros da comunidade que defendiam seu ponto de vista (alguns mais by the book e outros menos…) Me surpreendi com algumas colocações do Yoshima, acompanho seu blog, e tinha uma visão dele bem mais radical, mas não foi o que demonstrou na discussão… Isto demonstra certo amadurecimento que o mercado nos dá, e que outras pessoas que apenas vendem treinamento, mas não atuam no mercado entregando software não tem. Thompson em certo momento disse que não entendia as desavenças da comunidade do software, ele falou que na indústria as pessoas discutem Lean, Kanban, etc… todas de forma a agregar umas as outras e que no mundo do software ocorrem várias desavenças… Esta é uma triste realidade, que no meu ponto de vista é ocasionada por algumas pessoas mais radicais que não vivem o dia-a-dia do mercado e querem impor algo que não vivem na prática.
Depois participei da sessão “Evoluindo seu time através de coach” facilitada pelo Felipe Rodrigues, ele apresentou algumas técnicas de coach com demonstração. Depois fizemos duplas e realizamos sessões de coach. Acho que me sairia bem como coach =D, fiz o coach com um desenvolvedor que queria implantar scrum para melhorar a qualidade do código das equipes com quem ele trabalha, acabamos atráves das técnicas de coach chegando a conclusão que ele poderia fazer isso, usando seu círculo de influência de coordenadores, antes mesmo de implantar scrum…
A última sessão que participei foi o painel sobre equipes auto-organizadas, com o Akita, Klaus Wuestefeld e Eduardo Marcel Maçan. A discussão foi bastante ampla, desde quais são os pontos que fazem com que a auto-organização seja tão difícil (como os padrões da educação – para quem ainda não viu, recomendo o vídeo do Semler sobre o assunto.), se a hierarquia impede a auto-organização, se é possível escalar, etc…
O evento foi bem proveitoso, e acredito que seu formato será adotado nos próximos eventos agile, pois possibilita muita discussão.
Sem boas práticas de engenharia não há agilidade
Saudações a todos!!!
O objetivo deste artigo é despertar alguns times que algumas práticas de engenharia (como um bom design de domínio, refactoring e TDD) são peças fundamentais para que possamos colher os benefícios das metodologias ágeis. Vamos começar voltando um pouco no tempo e explicar como era o mundo antes das práticas ágeis:
Crise do Software
A “crise do software” foi um termo cunhado para descrever as dificuldades enfrentadas no desenvolvimento de software no fim da década de 60. A complexidade dos problemas, a ausência de técnicas bem estabelecidas e a crescente demanda por novas aplicações começavam a se tornar um problema sério. Foi nessa época, mais precisamente em 1968, que ocorreu a Conferência da OTAN sobre Engenharia de Software (NATO Software Engineering Conference) em Garmisch, Alemanha. O principal objetivo dessa reunião era estabelecer práticas mais maduras para o processo de desenvolvimento, por essa razão o encontro é considerado hoje como o nascimento da disciplina de Engenharia de Software.
NATO Software Engineering Conference 1968
Duas décadas depois, em 1986, Alfred Spector, presidente da Transarc Corporation, foi co-autor de um artigo comparando a construção de pontes ao desenvolvimento de software. Sua premissa era de que as pontes normalmente eram construídas no tempo planejado, no orçamento, e nunca caiam. Na contramão, os softwares nunca ficavam prontos dentro do prazo e do orçamento, e, além disso, quase sempre apresentavam problemas.
Custo das mudanças
Uma das consequências de tentarmos igualar metodologias de desenvolvimento de software a metodologias de engenharia tradicionais (como construção civil) é a visão de que o custo de modificar o programa aumenta exponencialmente ao longo do tempo, conforme gráfico abaixo:
Acolhendo as mudanças
A partir da metade dos anos 90 começaram a surgir discussões sobre se a forma faseada acima (cascata), como ocorre na construção civil era realmente o melhor modelo para o desenvolvimento de software. As metodologias ágeis de desenvolvimento surgiram exatamente para permitir maior flexibilidade no processo de desenvolvimento de sistemas e minimizar o custo de mudanças ao longo dos projetos, fazendo com que o gráfico acima fique mais próximo do apresentado abaixo:
Mas afinal de contas, como isto é possível? Como podemos adicionar mudanças ao software sem implicar em altos custos para o mesmo? A reposta a esta pergunta é o título do artigo: Aplicando boas práticas de engenharia!
Muitos times adotam scrum, mas deixam de lado as boas práticas de engenharia que são necessárias para que seja possível acolher as mudanças ao longo do projeto como pregam as metodologias ágeis. Este tipo de problema já foi discutido por Martin Fowler e James Shore . E meu objetivo com este post é despertar estes times para o estudo de práticas de engenharia como refatoração, boas práticas de design de domínio e TDD .
Se você usa scrum (O que é scrum?) , mas não utiliza estas práticas, sugiro que comece com urgência a estudar estes assuntos.
Um bom caminho para iniciar são os 3 livros abaixo:
Não à ditadura do desenvolvimento
Saudações pessoal!
Como sabem sou da área de desenvolvimento de software, mas neste post farei o papel do advogado do diabo =D
Vou começar com uma analogia:
Você está morrendo de fome e depois de andar um pouco entra no primeiro restaurante que encontra, sua vontade é de comer um hamburguer, na verdade você até gostaria de um prato melhor, mas a fome é tanta que a velocidade de ter um hamburguer torna o prato mais interessante que você pode imaginar…
Você não sabe, mas quem vem atender é um dos melhores chefs do mundo, estudou por anos com os melhores chefs e aprendeu as mais variadas receitas, conhece todas as tendências da culinária e faz com maestria os mais refinados pratos, ele ouve o pedido diz que fica pronto em 10 minutos e vai para a cozinha.
Quando começa a pegar os ingredientes pensa: “Não! Ele não vai querer um hamburguer! Ninguem mais esta comendo este tipo de comida hoje em dia! É comprovado que faz mal a saúde a longo prazo! Ele quer satisfazer a fome, eu entendi isto e vou fazer de uma forma melhor, vou preparar um Blanquette de veau , (digamos que o preço do prato seja o mesmo) vou levar apenas 10 minutos a mais e além de satisfazer a fome dele, ele terá um prato saudável, com mais vitaminas e que os mais variados chefs recomendam.”
O chef volta e o cliente já revoltado pelo prato ter demorado mais do que ele esperava olha e vê que não é o que ele queria, manda ele voltar para a cozinha e fazer o hamburguer que havia pedido.
O chef perplexo argumenta “Não é possível, o prato é bem melhor, mais saudável, por que você vai querer um hamburguer? Agora que fiz um prato melhor vou ter que refazer de uma forma pior?”
Você fica com tanta raiva que não quer mais argumentar tudo o que quer é o maldito hamburguer.
Parece engraçado, mas no mundo do desenvolvimento isto às vezes acaba acontecendo. Estudamos tanto a melhor forma de fazer um software, que às vezes acabamos sequer perguntando ao cliente se é realmente isto que ele quer.
Você pode pensar, eu sou de TI, portanto sei o melhor para o meu cliente, assim como o chef pensou, porém tenho a mesma opinião expressada pelo Kent Beck no livro Programação Extrema Explicada, capítulo 14: “Mesmo que a escolha de uma tecnologia pareça ser em princípio uma decisão técnica, ela é na verdade uma decisão de negócios, mas que deve ser levado em conta informações do Desenvolvimento. O cliente precisará viver com um fornecedor de um banco de dados ou uma linguagem por muitos anos e ele precisa sentir-se confortável com a relação tanto a nível de negócios quanto no nível técnico. Se um consumidor me diz: ‘Nós queremos este sistema, e você precisa usar este banco de dados relacional e esta IDE Java’, minha função é apontar as consequências dessas decisões. Se eu penso que um banco de dados orientado a objetos e C++ é a melhor escolha, eu faço as estimativas do projeto dos dois jeitos, E então as pessoas de negócios podem tomar uma decisão de negócios.”
É nosso dever argumentar sobre um benefício que outra alternativa teria, no entanto se o cliente mesmo assim querer um hamburguer, faça o hamburguer! Não fique preso ao que os demais chefs apontam como tendência, ou o que eles vão pensar se souberem que você fez um hamburguer. Além de mostrar que você entende do seu mercado, vai satisfazer seu cliente e quem sabe faze-lo voltar outro dia para apreciar o Blanquette de veau .
Sucesso = Paixão
Saudações pessoal!
Recentemente li uma edição da revista super interessante com uma reportagem que falava sobre o que tornavam algumas pessoas melhores em algumas áreas do que outras. Seria a genética? Ou simplesmente a dedicação?
Geralmente citamos frases como “esta pessoa nasceu com dom para isto” . Este pensamento nos tira a culpa de não sermos tão bons quanto elas, afinal se não temos o tal gene para chutar a bola tão bem quanto o Ronaldinho, não é culpa nossa, certo?
Mas este é o oposto do que diz os estudos (“Cambridge Handbook of Expertise and Expert Performance”) de Anders Ericsson, um dos mais renomados pesquisadores nesta área.
As horas de treino são muito mais fundamentais do que qualquer outro fator genético. Ele usa como exemplo Mozart (que aos 6 anos já se apresentava para reis e frequentemente é usado como exemplo dos que defendem que o dom faz parte da genética). Porém seu pai era músico e o fazia treinar desde os 3 anos de idade. E sua primeira obra avaliada como realmente genial pelos músicos foi feita aos 21 anos de idade, com aproximadamente 15 anos de treino.
E partindo deste ponto podemos chegar a outra conclusão. Ser realmente apaixonado pelo que fazemos é o que realmente faz com que sejamos bons nisto.
Quando vejo profissionais de destaque na minha área (TI) são pessoas que geralmente treinam (escrevem código, lêem artigos, participam de palestras) após o trabalho, e dedicam grande parte de seu dia ao assunto não se limitando ao horário de trabalho 9:00 – 18:00. Se você não tem gosto pela área não estará disposto a gastar horas com isto e nunca chegará no nível deles.
Ano após ano, vejo muitas pessoas ingressarem na área de informática, simplesmente pelo número de vagas ofertadas ou pelo salário acima da média das demais áreas, no entanto muitas dessas pessoas não tem o menor gosto pela área. Qual a chance de ser um profissional destacado se você sequer tem um grande interesse pela área? Se você faz parte destes profissionais, faça um favor para si mesmo, procure algo que realmente gosta, e veja o que as pessoas que são destaque nesta área fazem, estude e treine bastente e em algum tempo você ganhará tão bem sendo um bom profissional de uma área que não paga tão bem, quanto sendo um profissional ruim de uma área que paga bem.
Matérias relacionadas:
Planejando suas iterações com o TFS 2010
Neste post apresentarei como planejamos uma sprint utilizando o TFS 2010 com o template MSF for Agile 5.0
Vou admitir que você já tenha criado o team project com o template MSF for Agile 5.0
O primeiro passo que devemos realizar é a construção do Product Backlog. O product backlog é formado por uma lista de User Storys que devem ser priorizadas do maior para o menor valor para o cliente, com a finalidade de planejarmos e entregarmos primeiro as funcionalidades de maior valor. Você pode ler mais sobre como criar um bom Product Backlog aqui. Segue link para saber mais sobre o que é scrum?
Dentro da pasta “Shared Documents” do seu Project Portal existe uma planilha chamada “Product Planning”, conforme figura abaixo:
Na primeira aba da planilha será apresentada a lista de User Storys, conforme abaixo:
Você pode cadastrar as User Storys diretamente na planilha e clicar no botão Publish, para as alterações serem efetuadas no TFS. Cada User Story deve ser medida em Story Points pelo time e deve ser selecionada a iteração a qual pertence em “Iteration Path”. Você também pode criar as User Storys no Project Portal clicando em New Work Item / User Story.
Na segunda aba da planilha “Product Planning” temos a configuração das iterações, nela informamos qual é a data de início e fim de cada iteração e o tamanho do time. É exibido um gráfico com a velocidade do time, conforme abaixo:
Temos ainda a aba Interruptions onde podemos configurar feriados e dias não trabalhados da equipe. Aqui configuramos as interrupções de todo o time, também temos como configurar uma interrupção de um membro específico do time dentro da planilha de planejamento da sprint que será explicada a seguir.
O próximo passo é o planejamento da iteração. Na sprint planning o time deve quebrar as User Storys em tarefas e estimá-las em horas.
No TFS para criar a Task você deve selecionar a User Story e clicar no botão “Add New Linked Work Item”, selecione no campo Link Type a opção Child, e escreva um título para a Task.
Você deve preencher os campos “original estimate”, “remaining” e “completed” com a estimativa original em horas, o número de horas que faltam e o tempo completo, respectivamente. Como a tarefa acaba de ser criada o “original estimate” e o “remaining” serão iguais e o completed será 0. Assim que concluirmos a tarefa devemos mudar o estado para “closed” e preencher o campo remaining com 0 e o completed com o número de horas que a tarefa levou para ser concluída. Você deve ainda selecionar em Iteration, em qual interação esta tarefa estará.
Depois de estimarmos todas as tarefas que irão na próxima sprint você deve configurar a planilha “Iteration Backlog.xlsm” ela deverá ficar dentro da pasta shared documents\”Sua iteração”. Você pode copiar esta planilha da pasta “Documents \ Samples and Templates \ Document Template – Iteration Backlog.xlsm”
Abrindo a planilha na primeira aba “Iteration Backlog” temos todas as tarefas que foram cadastradas para a iteração atual.
Na segunda aba “Settings”, configuramos a data de início e fim da iteração.
Na aba iterruptions podemos definir interrupções específica do membro do time.
Na terceira aba “Capacity” temos uma visão gráfica da alocação do time. Podemos configurar quantas horas cada membro do time poderá destinar a iteração e assim termos uma visão se será possível terminar os itens selecionados dentro da sprint.
Quando algum membro do time estiver com muitas tarefas, podemos voltar na aba Iteration Backlog e mudar o campo “Assigned To” para um membro do time que tiver horas ociosas, mostradas em verde.
O objetivo deste gráfico é mostrar se o estimado está dentro do possível, durante a sprint caso o time sinta necessidade poderão ser alteradas as pessoas que irão executar as tarefas. Com as tarefas balanceladas o time pode dar início a sprint. Alterando as tarefas para “closed’ quando forem concluídas e o campo completed work com o número total de horas gastas na tarefa e o remaining work para 0.
Retrospectiva #AgileBrazil 2010
Saudações pessoal!
Este post está um pouco atrasado, mas não será sonegado! =D
Na semana dos dias 22/06 a 25/06 aconteceu na cidade de Porto Alegre o evento Agile Brazil 2010, que contou com nomes influentes do cenário nacional e mundial de agile. O evento foi muito bem organizado e contou com cerca de 800 participantes.
A abertura do evento foi feita por ninguém menos que Martin Fowler um dos criadores do manifesto ágil. Em geral a apresentação dele não trouxe novidades para quem já acompanha seu blog, mas ouvir ele apresentar pessoalmente suas idéias já é gratificante.
Achei interessante a palestra do David Hussman entitulada “Produtos e Pessoas sobre Processo e Dogma”, a ideia geral da palestra era conhecer não só como implementar uma técnica, mas conhecer o porque implementá-la, assim só utilizamos se faz sentido, e não somente porque alguém falou que se você não usa aquilo você não é ágil ou coisa do tipo…
Participei depois do workshop do Yoshima e Phillip Calçado, “Reconheça! Você não sabe modelar!”, eles passaram a idéia de que modelar não é necessariamente desenhar algum diagrama, quando se cria um protótipo junto com o cliente já estamos modelando.
No final do primeiro dia assisti a palestra da DBServer, eles abordaram como equilibram a utilização de scrum com contratos de preço fixo, fazendo um pré-game de algumas funcionalidades para medir a velocidade do time e ter alguma previsão do quanto o cliente irá gastar a partir de então.
No segundo dia cheguei apenas após o almoço e peguei a palestra “Quando o Scrum passa a atrapalhar” do Guilherme Silveira e da Cecilia Fernandes, da Caelum. A palestra foi um pouco na linha do pensamento do David Hussman, falando que eles passaram a utilizar somente o que achavam necessário do Scrum, de acordo com a cultura deles. Achei interessante que não houve nenhuma manifestação xiita do tipo “Vocês estão usando scrumbut e vão queimar no inferno!” ou algo assim. Talvez porque o nome Caelum seja bem conhecido na comunidade, mas acredito que isto demonstra um amadurecimento da comunidade em não dizer que existem receitas de bolo para tudo.
A palestra de encerramento do Klaus Wuestefeld, também frisou a idéia de evitar receitas de bolo, ele resumiu os valores do XP em dois, que são suficientes segundo ele para motivar a equipe e tornar o trabalho cada vez melhor.
A grande impressão que tive ao final do evento é que a comunidade está menos xiita e mais voltada a busca de resultados práticos, afinal a idéia de que não há uma bala de prata que sirva para todos os projetos está sendo levada mais em conta do que o medo de não usar o scrum by the book, e ser apontado como um “scrumbut”.
Você quer observar a história ou fazer história?
Saudações Pessoal!
Antes de iniciar como consultor do SDC passei por um processo de seleção totalmente diferente de todos que tinha passado até então (e não foram poucos…). Uma das perguntas que me fizeram no processo foi se eu participava da comunidade de software.
É claro que minha resposta foi sim, afinal eu participava de eventos, principalmente da sucesu-sp, listas de discussões (scrum-br), etc… Mas depois da chamada do meu amigo Rafa Noronha, percebi que faltava algo.
Como é possível participar efetivamente da comunidade se eu não tinha um blog para registrar minhas idéias? Percebi que minha participação na comunidade era muito mais para buscar informações que eu precisava, do que compartilhar as informações que eu possuia.
Um blog exerce um grande papel na divulgação e troca de experiências entre membros da comunidade, e este foi o principal motivo que me motivou a criar o meu.
Há uma cena do filme “O Código da Vinci” na qual o Robert (Tom Hanks) se desculpa por ter envolvido Leigh (Ian McKellen) na busca por respostas para solucionar o crime que acontece no início do filme. Leigh, que é um historiador, responde entusiasmado:
- Eu e você Robert temos observado a história. O tempo como uma vitrine. Agora estamos dentro da história! Vivendo! Fazendo! Obrigado!
Sir Leigh
Espero com este blog passar não só a observar a história, mas ajudar a escrever a história da comunidade de software brasileira, se você ainda não possui um blog, crie! Compartilhe suas experiências e ajude-nos a escrever a história!
Saudações!
Saudações pessoal!
Já faz um tempo que estou com o projeto de criar o blog no meu backlog, e nada como o feriado de São Paulo (09/07) para colocar minha lista de “to do” em dia! Gostaria de agradecer aos 4 estudantes M.M.D.C. (na verdade 5, Alvarenga faleceu alguns meses depois) e a todas as demais pessoas que morreram para que além de termos nossa constituição novamente, também fosse possível a atualização deste blog!
Bom, vamos a apresentação: Sou o Ricardo Fernandes Luiz, nasci em 1982 em Osasco-SP, e trabalho com TI desde 1998. Antes mesmo de começar a trabalhar com TI já tinha um grande interesse pela área, que começou quando meu tio Ede que trabalhava com design comprou um pc, ainda com windows 3.11 em meados dos anos 90.
Este foi o primeiro contato que tive com um pc e fez com que eu e meu irmão mais velho André Fernandes, tivéssemos um grande interesse pela área. Anos mais tarde meu irmão ingressou no curso técnico de processamento de dados na Fundação Bradesco, em Osasco, e eu comecei a estudar pelas apostilas dele. Comecei a desenvolver programas simples, copiando os códigos das apostilas, e me divertia ensinando alguns amigos da 8a. série a desenvolver alguns programinhas em VB enquanto a maior parte dos alunos tinha aula de power point. Nerd total! =D
Mais tarde também ingressei no técnico em informática (não era mais processamento de dados) da Fundação Bradesco, e meu primeiro contato profissional com a área se deu na empresa Micromatic, em 98. Eu já fazia alguns sites pessoais e o dono da empresa, na qual meu irmão trabalhava, se interessou em criar um site para a mesma. Tive algum contato com Delphi, linguagem que a empresa utilizava, pois os sistemas feitos eram voltados para teleatendimento, mais conhecido como CTI (computer telephony integration). Daí surgiu também meu interesse por telecomunicações, área que sou formado.
Depois da Micromatic passei pela Ideológica empresa parceira da microsoft. Minha missão nesta empresa era migrar um ERP feito para uma indústria de comércio de cacau (Indeca) de VB4 para ASP3, fazendo com que o sistema pudesse ser acessado pelo diretor de fora da empresa. Passei depois pela SGIWEB, empresa do grupo remaza (mais conhecido pelo sistema de consórcio) porém que tinha um grande foco em comércio eletrônico através dos sites gimba.com.br (B2c) e websupply.com.br (B2B).
Logo depois comecei a trabalhar na Spread Teleinformática, com desenvolvimento em ASP3 e banco de dados Oracle. E comecei a cursar engenharia de telecomunicações. Fui líder técnico do projeto de recuperação de crédito para o banco Bradesco e comecei também a me interessar por gestão. Algum tempo depois iniciei na Politec, com a missão de ajustar a ferramenta interna de controle de fábrica, para certificação CMMI nível 5 (na época a empresa tinha certificação nível 3). Fui líder de alguns projetos, e comecei a cursar mba em gestão empresarial.
Nesta época fundei, juntamente com meu irmão a Nitroweb Informática empresa voltada a soluções web, além de sistemas de gerenciamento de rede (SNMP), marketing por bluetooth, comércio eletrônico, alocação de profissionais, treinamento, e sistemas sob medida.
Tenho estudado práticas ágeis desde o início de 2009, e no final de 2009 fui convidado para atuar como consultor em gestão de projetos do time do SDC da stefanini, com a missão de ajudar a montar um time de desenvolvimento voltado a práticas ágeis, juntamente com o André Nascimento, Leonardo Neves, e mais aproximadamente umas 40 pessoas, acho que estamos conseguindo alcançar este objetivo.
Agora que já estou bem apresentado =D Vamos aos assuntos que vocês encontrarão neste blog:
- Prática Ágeis;
- Desenvolvimento de software;
- Liderança / gestão de projetos;
-Gestão empresarial;
-Tecnologia;
-Reflexões e desabafos.
Espero poder contribuir com minhas experiências!
Abraços!
