Na escola, já aprendemos que o engenheiro estadunidense Frederick Taylor é considerado o pai da administração científica pela invenção do modelo de administração cunhado como taylorismo. Apesar de essa linha de abertura ser demasiado entediante por trazer consigo um breve flashback do sofrimento psicológico para os que, assim como eu, foram alunos de escolas estaduais, relembrá-la é importante. Taylor tem muito o que nos ensinar no que diz respeito ao gerenciamento de equipes de engenharia de software.

Apesar de o livro Princípios da Administração Científica ter sido publicado há mais de um século, trazendo um enorme avanço para a eficiência de empresas do mundo todo, muitos dos gerentes, nos dias atuais, continuam atrasados em mais de um século quanto às suas práticas de gestão de equipes e projetos. Apesar também de a obra citada ter sido escrita com foco na indústria do início do século XX e conter diversas dicas voltadas para a produção industrial que não são aplicáveis à engenharia de software dos dias atuais, ela ensina que devemos estudar nosso trabalho cientificamente.

Se você está com sua memória dos tempos de escola afiada, já deve ter se lembrado de que o modelo de Taylor foi tão bem sucedido no aspecto da produtividade que teve um efeito negativo para a indústria estadunidense com a criação de estoques de produtos que superava a demanda pelos mesmos, o que levou os japoneses a inventarem um modelo mais eficiente no que diz respeito ao equilíbrio entre oferta e demanda, que foi apresentado para nós nas escolas brasileiras como Sistema Toyota de Produção, ou simplesmente Toyotismo. Uma vez que os japoneses introduziram o modelo de administração científica na Toyota, conseguiram, por meio desse processo, evoluir rapidamente e tornaram obsoleto o então modelo de produção mais avançado. Uma das principais conclusões que podemos tirar desse evento e dos que deram sequência é que uma vez que colocamos o nosso trabalho sob o microscópio e uma abordagem científica, somos capazes de alcançar um estado de melhoria contínua. Os japoneses não demoraram para perceber isso após o sucesso do Toyotismo, cunhando então o Kaizen.

Quando o assunto é engenharia de software, devemos nos lembrar de que a engenharia mecânica está presente no mundo desde o século XVIII, naturalmente sendo muito mais avançada e madura em suas práticas do que a engenharia de software. Por isso, devemos olhar com cuidado para esses eventos históricos em torno da engenharia mecânica para que possamos absorver o máximo de aspectos e princípios que possam ser adaptados para a nossa realidade de engenheiros de software. Foi exatamente o que Jeff Sutherland fez com o desenvolvimento do Scrum, que apesar de tratar de diversos aspectos da construção de uma aplicação, aqui iremos abordar apenas o aspecto oferecido por ele no que diz respeito ao estabelecimento de um método científico para a análise do trabalho de sua equipe. O objetivo é entender a importância que esse processo tem para o nosso trabalho e como devemos agir para desfrutar o máximo dele.

Medição dos fatores de sucesso

Toda equipe de engenharia de software possui objetivos e toda vez que nos propomos a executar um projeto, assumimos que seremos então capazes de executá-lo até o fim e entregá-lo no prazo esperado de acordo com todos os requisitos especificados, isto é, se tudo correr bem. A frase “se tudo correr bem” tem uma grande importância para a execução de qualquer tipo de projeto, portanto devemos ser capazes de desenvolver mecanismos para medir e traduzir esse termo para uma linguagem mais científica. Cada projeto tem um conjunto de variáveis distintas que juntas irão definir o que é o famoso “se tudo correr bem” daquele projeto em questão. Seu trabalho como gestor é identificar quais são esses fatores e criar mecanismos para os medir. Fatores relacionados ao sucesso de um projeto que são fáceis de se medir e normalmente medidos podem ser o número de bugs encontrados por período de tempo, quantidade de trabalho realizado em um dado período de tempo e nível de satisfação de clientes e usuários do seu produto. Uma vez que você começar a acompanhar esses tais indicadores, você poderá ver quando eles irão oscilar e então poderá ir para a fase seguinte, que é associação de causas e efeitos. Para um maior aprofundamento nessa atividade, recomendo a verificação do PMC (Project Monitoring and Control), uma process area muito importante do CMMI (Capability Maturity Model Integration) que explora esse conceito ao extremo para as mais variadas necessidades da indústria de desenvolvimento de software.

Uma vez que você identificou os fatores de sucesso mais importantes a serem medidos, irá notar no que diz respeito ao desenvolvimento contínuo que todos esses fatores deverão ser medidos em duas dimensões, sendo uma delas o tempo e a outra a quantificação do fator em si. Isso ocorre, dado que o filósofo alemão Martin Heidegger estava corretíssimo, nós somos seres temporais e portanto no que diz respeito à indústria as coisas não são diferentes. Nós somos bons ou ruins em uma dimensão temporal, logo todos seus indicadores de sucesso devem ser medidos contra o tempo para que você consiga entender se você está melhorando ou piorando com o passar dele e não existe uma melhor forma de medir esses indicadores contra a dimensão temporal do que por meio de sprints, isto é, que eu saiba. Particularmente gosto do conceito de sprints, pois todo o time é envolvido no processo de identificação das causas de oscilação dos indicadores, tornando o processo muito mais eficiente já que iremos reunir diversas perspectivas e promover o debate entre a equipe.

É importante manter em mente que os seus indicadores devem buscar representar a relação direta que a engenharia de software tem com o sucesso do seu negócio, portanto se você acredita que a produção de mais funcionalidades irá ajudar na retenção ou aquisição de consumidores novos, é necessário então que você busque um meio de associar a relação de causa e efeito que seu software tem com seu negócio. Um erro que já cometi foi o de me importar somente com a entrega do produto no prazo especificado, sem muito me importar com o negócio que iria se beneficiar daquele produto. Quando fazemos isso, inevitavelmente o produto entregue dificilmente estará otimizado em seu potencial máximo para o negócio em questão, na verdade, toda otimização aplicada foi feita somente para reduzir o tempo de entrega e ficar dentro do orçamento planejado. Portanto, tenha em mente que indicadores genéricos como número de funcionalidades ou story points entregues por período de tempo são essenciais, mas se você se mantiver preso somente a esses indicadores genéricos, não será capaz de utilizar o método científico para entender a totalidade da relação entre software e o sucesso do seu negócio.

Estabelecendo o método científico

Uma vez que você tem suas medições configuradas e operando, vem então a hora de aplicar o método científico. Sempre que houver uma mudança nos indicadores, você irá junto da sua equipe tentar entender o motivo de determinada mudança. Produzirão então uma tese e, em seguida, tentarão verificar se o resultado é verdadeiro por meio da escolha de um experimento. Essa mudança pode ser para melhor ou para pior, não importa, o que importa é que você e sua equipe estarão utilizando o método científico para entender o que funciona, o que não está funcionando muito bem para vocês e os motivos por trás disso. Essa é a forma reativa de trabalhar com o método científico e esse é um dos mais importantes princípios do desenvolvimento ágil de software: responding to change over following a plan. Você também poderá utilizar o método científico em seu favor de uma maneira mais proativa, isto é, aplicando teses encontradas em literatura e demais meios de comunicação e acompanhando como os indicadores irão reagir a essas mudanças.

Um bom mecanismo para estabelecer a relação entre causa e efeito no que diz respeito aos indicadores de sucesso são as sprint reviews e as sprint retrospectives, cerimônias presentes no Scrum Framework. Ao término de cada sprint, você irá se reunir com sua equipe e juntos irão fazer uma revisão de todo o trabalho realizado, apresentando os objetivos alcançados, as novas funcionalidades e explicando como as coisas se deram durante a sprint. A revisão é uma cerimônia mais informal e normalmente os stakeholders do projeto são convidados para fazer parte da revisão dos trabalhos executados na sprint. Em seguida, você e seu time abandonarão a informalidade da revisão e entrarão na formalidade da retrospectiva, em que vocês irão analisar os indicadores, estabelecer relações entre causa e efeito e desenvolver teses que terão como objetivo tornar a equipe mais produtiva na próxima rodada de trabalho. Uma ferramenta que pode ajudar sua equipe no processo de retrospectiva é o EasyRetro, em que você tem um modelo de board para ser utilizado pela sua equipe. Antes de conhecer o EasyRetro, eu escreveria a opinião de cada um dos membros da equipe em um documento word, por exemplo, e disponibilizaria o documento para todos no fim da cerimônia para que tudo ficasse arquivado caso fosse necessário no futuro ou para consulta na próxima sprint, o que geralmente é necessário.

Conclusões

Aplicar o método científico para gestão de sua equipe não é algo de outro mundo. Apesar de exigir um determinado trabalho para estabelecer indicadores eficientes que incluirão algumas consultas no banco de dados e sincronização com alguma ferramenta para apresentação de gráficos, como algum BI, Google Sheets ou Microsoft Excel, uma vez que esse trabalho for feito, você não irá se preocupar muito com a manutenção de indicadores e irá focar mais no desenvolvimento de teses para tornar sua equipe mais eficiente, o que é fantástico. Embora muitas equipes se coloquem com os pés entre as mãos enquanto tentam estabelecer um determinado processo de gestão, recomendo inicialmente o foco exclusivo no método científico, pois esse em si é mais simples do que implementar o Scrum ou Kanban à risca, por exemplo, e irá lhe permitir identificar de antemão qual metodologia ágil é a mais eficiente para a sua equipe. Além disso, se você mantiver seus indicadores de uma forma transparente para sua equipe, será mais fácil lidar com as opiniões adversas de seus colaboradores, pois sempre que alguém tiver uma ideia nova, as decisões não serão tomadas com base em influência política de um membro de lábia afiada ou então em emoções irracionais. Elas serão tomadas com base na análise fria e calculista dos indicadores que demonstram o que é ou não melhor. Além de um resultado para a gestão de sua equipe a curto prazo, a utilização do método científico irá lhe garantir uma forma robusta de adquirir conhecimento ao longo de sua carreira, tornando-o um gestor mais eficiente e fazendo também com que os membros da sua equipe evoluam constantemente.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: