Taí um tema que encontra múltiplas e variadas versões, opiniões e experiências, em especial se confrontarmos escolas de gestão distintas.
Não há uma verdade única, mas há interessantes argumentos por (A) quem defende a codificação como uma atividade criativa análoga à arte, como pintar um quadro ou esculpir uma escultura, e (B) os que defendem que a produção de software, enquanto business, mais se assemelha à construção de um produto, como uma linha de montagem de um automóvel, por exemplo.
Segundo os defensores do conceito A, enquanto artistas, os desenvolvedores não devem ser pressionados com relação ao cumprimento de uma jornada fixa de trabalho, da mesma forma que a definição de prazo para conclusão de um projeto acaba por atrapalhar seu processo criativo.
Para os que percebem o software como um produto (segundo o conceito B), cuja construção aproxima-o mais das ciências exatas do que das artes, a etapa de alta criatividade está mais no projeto que antecede a montagem, e a codificação em si deve ser realizada por times com conhecimento das melhores técnicas, com método, processo e disciplina.
Profissional criativo é desejável em qualquer atividade, mas não é mandatório que todo programador seja criativo, desde que ele domine as técnicas mais atualizadas de programação para o projeto que esteja desenvolvendo.
Ou como diria o Sidney Lima Filho, especialista no tema:
– “Programar é igual a pintar, nem todo pintor é criativo, mas existem grandes obras de arte que são pinturas. Antes de me pedir para não ter horário, mostre-me o seu quadro. Criatividade é a habilidade de criar sistematicamente. Se você só cria de vez em quando, então você não é criativo, apenas teve algum rompante de criatividade. Programar é uma atividade criativa, portanto a qualidade da sua solução também reflete sua capacidade criativa.”
Ainda na ótica de quem acredita no conceito B, a criatividade na codificação se aproximaria das soluções que um engenheiro criativo aplica à linha de montagem, buscando melhor resultado do que aquele previsto no projeto original.
Neste caso, o conceito de times coesos, trabalhando juntos, no mesmo local e no mesmo horário, fazem muita diferença na produtividade, na eficácia e, por conseguinte, nos resultados alcançados na produção de software, em especial em projetos de grande porte.
Um trabalho que depende de uma equipe e no qual há uma interdependência de etapas, de compartilhamento de conhecimento e troca de experiências, seguramente terá melhores produtividade, eficácia e resultado, se toda a equipe trabalhar junta.
Ou seja, um time que desenvolve software de forma compartimentada, em que cada desenvolvedor é responsável por determinada funcionalidade ou trecho do código, será mais produtivo, eficaz e atingirá melhores resultados se todos atuarem no mesmo local e no mesmo horário.
A disciplina é mesmo um componente fundamental nesse tema e quando me refiro à comunicação presencial, destaco standup meetings diários, espírito de equipe, motivação pela criação compartilhada com amigos e colegas e reuniões de projeto, que é o que fazem o que chamo “team commitment”.
Entre produtividade ou eficácia definitivamente fique com os dois, mas atente que é um grupo de profissionais atuando juntos que impactará diretamente a conquista de resultados.
.
