Hospedagem Profissional

Hospedagem Profissional
Clique aqui e ganhe US$ 10,00 para testar durante 1 mês a melhor hospedagem: Digital Ocean!

quinta-feira, 25 de julho de 2013

Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter, indefinidamente, passos constantes.

Reflexão sobre o artigo: http://scrum.jeffsutherland.com/2008/09/maxwell-curve-getting-more-production.html Lendo um artigo do Jeff Sutherland de 2008, um dos pais do Scrum, sobre o seu trabalho na OpenView Venture Partners, me deparei com a seguinte frase, a segunda do artigo:
“As venture capitalists we used to want people to work harder and harder to get more productivity, certainly more than 40 hours a week. We would push them and push them until they started to burn out, get demoralized, and threaten to quit.”
Certamente é algo que eu já vi acontecer em várias startups, já vi vários empreendedores acreditarem nisso e vários sendo incentivados a trabalhar todos os dias, 10 horas por dia ou mais. Sim, pela vivência que eu tive o diferente é se trabalhar 8 horas por dia.
Depois de muito ter refletido sobre essa frase, continuei lendo o artigo para ver onde ele iria parar e no fim ele conclui que diminuir de 60 horas semanais para 40, fez a quantidade de pontos de história aumentar 20%, porém o retorno para a empresa aumentar em 160%. Vejam só, quando se trabalhava 20 horas a mais por semana, se fazia menos da metade de coisas importantes do que quando se trabalhava 40 horas. Além disso, ele conseguiu pessoas motivadas, que não vão estar esgotadas daqui a algum tempo.
Após ler esse artigo, cheguei a seguinte conclusão:

O melhor mesmo seria trabalhar 30 horas por semana.

alt text
Reparem que o pico de produtividade de um time que usa Scrum é perto das 32 horas por semana, o que garantiria focar o máximo na direção correta. Vendo isso venho aqui propor um modelo para se trabalhar somente 30 horas e obter mais produtividade do que com 40 horas ou 60:

Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

  • Continue pagando 40 horas para os seus desenvolvedores e nas 10 horas que você estaria "dando de graça" para eles, peça que as usem para ficarem de standby caso alguma eventualidade(servidor cair) aconteça. Sei que essas coisas acontecem e é melhor pedir para eles gastarem essas 10 horas extras, do que o fim de semana com a família.
    • Se você contratou bons desenvolvedores, eles sempre vão estar procurando aprender coisas novas, praticar e ficarão muito motivados se não tiverem que fazer isso no momento de lazer. Considere as 10 horas a mais que você está pagando como um investimento no treinamento da sua equipe. Já vi várias empresas perderem bons desenvolvedores, por esses não estarem conseguindo se desenvolver.
    • Nada estressa mais um profissional do que se programar para esquecer do trabalho e receber telefonema do chefe em um momento inoportuno, então deixar um dia já combinado para ser o dia do desespero é uma solução para isso.
    • Trabalhar presencialmente menos dias na semana, implica em menos horas desperdiçadas no transito.
    • Uma sugestão que recebi, foi de pagar essas 10 horas restantes em cursos ou eventos culturais, como cinema, teatro e etc. Isso ajuda a tornar o ócio em um momento criativo (Pesquisar pelo livro, Ócio Criativo).

O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

alt text
Sempre fui muito a favor do trabalho remoto, mas reconheço que ele não é a melhor maneira de transmitir conhecimento e informação e para o time se manter produtivo nessas 30 horas deve-se evitar falha na comunicação e ,na minha visão, o trabalho presencial traz esse ganho em cima do trabalho remoto. Então minha segunda sugestão, baseada no Scrum é:
  • Comece o trabalho em um horário pré combinado com o time (deixe eles escolherem), que faça com que eles produzam mais, e marque reuniões diárias com eles como a primeira coisa do dia, para que todos tenham certeza do que está planejado para ser executado, e peça para ninguém chegar atrasado. Uma prática sugerida pelo Scrum é aplicar uma penalidade que agregue quando um atraso aconteça, como por exemplo, pode pegar 2 horas para executar tarefas em outro setor, por exemplo suporte ao usuário, trabalhando assim 32 horas nessa semana. Obvio que times que se comunicam bastante durante o dia, a reunião de manhã passa a ser desnecessária, caso isso seja sua realidade, sugiro conversar com o time para saber qual a melhor maneira de motivá-los a chegar no horário acordado. O importante, na minha visão, é todos estarem juntos e não um trabalhar de tarde até de noite e outro de manhã até a tarde.
    • Acredito que as 2 horas a menos das 32 propostas no gráfico, seriam melhor aproveitadas se o time estiver aprendendo sobre outros setores da empresa, pois a vivência nesses setores fará com que ele entenda os problemas daqueles usuários.
    • Trabalhe em Par. Existem diversos estudos que mostram que diminui a taxa de erro, aumenta a produtividade, principalmente quando a dupla são duas pessoas menos experientes, ajuda a propagar o conhecimento, o aprendizado obtido no tempo de ócio e sua empresa fica menos dependente de um único programador, afinal, ao menos duas pessoas participarão da construção de cada parte do sistema. Os pares devem ser rotativos. É importante ter os 3 tipos de dupla: iniciante x iniciante, iniciante x experiente, experiente x experiente,

Software funcional é a medida primária de progresso.

  • Como o tempo do time passou a ser curto, é necessário que o PO priorize ainda melhor as histórias, deixando na mão do time a estimativa dos pontos de complexidade de cada uma, desenvolvendo assim as que tiverem o maior RoI (Valor de Negócio estimado pelo P.O / Estimativa de Complexidade dado pelo time )
    • Uma das maiores mágicas do desenvolvimento ágil é focar no que realmente vai dar retorno e reduzindo o tempo do time para 30 horas, o PO se vê com uma necessidade maior ainda de priorizar melhor, com isso, diminui-se a quantidade de histórias com o retorno baixo, que normalmente são escolhidas para completar número de "pontos de história" combinados por semana.
    • Isso é algo que deveria ser levado para toda empresa. Se você tem uma palestra/reunião que é necessário uma apresentação, a prioridade deveria ser preparar essa apresentação, antes de qualquer coisa, e não deixar para ultima hora e cobrar que seja lá quem for fazer, virar a noite antes da palestra montando-a. PS: Existe uma chance gigantesca desta pessoa ser você.
    • Prazos são do mal. Peça estimativas para seus desenvolvedores e priorize o que for mais importante para que eles façam o melhor nesse espaço de tempo. O máximo que um desenvolvedor pode fazer é prometer desenvolver o melhor software possível dentro do espaço de tempo acordado. Se ele te disser uma data exata para o fim do projeto, ele está mentindo para você: http://www.akitaonrails.com/2013/04/05/traducao-estimativa-o-melhor-que-podemos-fazer#.UehhKWTwK6w
ps: Quem quiser ler mais sobre o assunto, recomendo o artigo: http://jeffsutherland.com/Agile2008MoneyforNothing.pdf

Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

A ultima mudança que venho propor é a mudança do que seria o natural: 6 horas dia/5 dias por semana(30 horas) para 3 dias de 10 horas ou 4 dias, sendo 3 dias de 8 horas e um de 6. Fiz uma pesquisa recentemente que mostrou que 43% dos desenvolvedores prefeririam trabalhar 4 dias na semana, 41% 3 dias na semana, e somente 16% os 5 como hoje é estruturada a jornada de trabalho.
  • Agora se a ideia desse artigo é ganhar produtividade motivando as pessoas, me pergunto porque o trabalho em 5 vezes por semana é o mais adotado. O melhor seria conversar com o seu time, não só dessa vez, mas sempre em intervalos regulares, para saber como eles preferem trabalhar e todos chegarem em um acordo.
    • Seu time pode até mesmo dizer que tudo que eu disse acima é idiotice e que eles preferem trabalhar 40 horas, remoto, isolados em uma caverna, etc., e você jogue todas as práticas ágeis fora, mas tome essa atitude porque o seu time acredita nisso, e não você. Lembre, quem vai produzir o valor para sua empresa é seu time, o seu papel é dar a direção e fornecer o melhor ambiente possível para que eles produzam o máximo que conseguirem de forma constante.
    • E escute sempre, mesmo depois de você adotar qualquer prática anteriormente proposta, pois refletir se a direção tomada é a certa é mais importante do que acelerar em uma direção qualquer.
    • Se você vai ficar com algo desse artigo, que seja a melhoria contínua.