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.
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.
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
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.Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
- 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.
