Stakeholders: desenvolvimento de software não é peça pelo número

Quero contar desta vez algumas peripécias no mundo de desenvolvimento de software, da época em que atuei conduzindo equipes e cuidando do roadmap de produtos de software.

Se você é um stakeholder (alguém que influencia algo no negócio) em um projeto de software, esse artigo é pra você. Se você ainda não se aventurou nesse universo, aprenda aqui algumas dicas para não virar o terror sem noção das equipes de desenvolvimento de software.

Em primeiro lugar eu quero deixar claro que desenvolvimento de software não é como ir a um fast-food, pedir algo e ser atendido em dois minutos. Muita gente acha que ao lidar com software pode chegar falando algo:

"Me vê um formulário de contato, um botão de comentário, uma galeria de fotos com molho barbecue e coca-cola. E de sobremesa um botão pra excluir comentários com calda de chocolate".

Acredite, algumas pessoas acham que basta pedir o que quiserem pra quem gerencia um projeto e que serão prontamente atendidas.

Certa vez uma stakeholder velha de casa e bem envolvida em uma das áreas nas quais trabalhei me ameaçou e disse que me levaria ao CEO da empresa quando me recusei a atendê-la. Ela me pediu funcionalidades perfumaria baseadas em seu gosto pessoal apenas. Eu expliquei calmamente e da forma mais amigável possível que eu não podia atender a lista de desejos dela naquele momento. Pelo menos não com a rapidez que ela queria. Minha calma para explicar no sentido da fala e no sentido também de transformar o que seria super técnico em algo decifrável por ela, que não entendia nada de software.

Por mais que eu quisesse eu simplesmente não podia parar todo um ciclo de desenvolvimento (naquele momento usando metodologia tradicional, portanto, sem chance de alterações repentinas ou flexibilidade de ágil) para enfiar uma lista de funcionalidades que ela desejava, desconsiderando outras regras de negócio, enquanto a equipe trabalhava na correção de bugs e, pior, em um produto que dentro de poucos meses seria descontinuado. No planejamento podem existir dependências, prioridades, razões para algo não poder existir, limitações da tecnologia escolhida, necessidade de correções de bugs, etc. Nem sempre é possível atender a gostos e caprichos pessoais de stakeholders.

Aliás, friso algo muito importante: se a intenção é produtizar criando softwares que possam ser úteis a vários clientes, existem algumas regras de negócios que precisarão ser pensadas para atender a todos eles, sem se amarrar a um determinado. É comum que um stakeholder envolvido em determinado projeto tente "puxar sardinha" para o seu interesse. Quem gerencia esse planejamento precisa analisar tudo isso com muito cuidado, senão, ao invés de um produto você tem apenas um projeto, que atende apenas a um cliente.

Para quem não entende de desenvolvimento ou de planejamento de software é bem comum que se peçam coisas não cabíveis, escabrosas e gigantescas, e eles pedem com toda a certeza de que é muito possível fazer aquilo acontecer. Em tipo, uma semana no máximo.

Das diversas reuniões que participei nunca vou esquecer de quando um gerente de projetos com fama de sem noção e de carrasco disse que o cliente queria uma rede social. Eu então perguntei sobre como seria esse rede social.

Ele me respondeu que se fosse igual ao Facebook estaria ótimo.

 Olha, confesso que é preciso ter bastante paciência pra trabalhar com gente assim. Ah, e também bastante força de vontade pra não rir na cara da pessoa. Como é que alguém tem a coragem de pedir uma rede social igual ao Facebook e ainda tem a certeza de que será possível desenvolvê-la em menos de dois meses.

Desconsiderei a gafe e quis entender mais algumas diretrizes. Perguntei como a timeline se comportaria em relação ao 100 mil usuários que a rede social teria. Disse que provavelmente não seria possível que todo mundo visse tudo de todos, pois com essa quantidade de usuários seria impossível e improdutiva tal ação. Era preciso no mínimo definir grupos de usuários, por exemplo. Mas infelizmente aquele cara sequer sabia que no próprio Facebook não vemos tudo o que todos os nossos amigos postam. O próprio algoritmo da ferramenta decide quem vai ver o quê. Mas para uma pessoa sem noção eu estava louca, criando impedimentos e que "ele via sim tudo o que seus amigos postavam". Ele resolveu as perguntas que eu o fazia (pois eu o deixava reflexivo demais) apenas me excluindo das reuniões. Tocou o projeto com a equipe, o resultado foi desastroso, perderam prazo e tudo o que conseguiram foi desenvolver uma espécie de mural com comentários.

A verdade é que para algumas pessoas uma funcionalidade nova trata-se apenas de um botãozinho. "Ei, só quero um botão pra postar comentários nas fotos da galeria atual do site, poxa, é só um botão". Mas essa pessoa não é capaz de compreender que o botão é uma casca, apenas a porta de entrada de uma ação. Por trás desse botãozinho de comentar existe uma estrutura enorme. É preciso remodelar a funcionalidade, prever formas de comportamento do comentário, incluir opções para apagar, editar, etc. Não é um simples botão. E eu geralmente explicava da forma como acabei de explicar: pra leigos.

Minha graduação não foi em TI. Meu mestrado eu puxei pro assunto de desenvolvimento de software como pude. E depois fui buscar cursos de gerenciamento de produtos e de projetos, de Scrum, entre outros. Mas na teoria mesmo eu não sou de TI. Nem por isso eu deixei de ser capaz de planejar softwares e gerenciar equipes de desenvolvimento. Eu precisava saber apenas o essencial para tomar decisões e orientá-los. E eu nunca tive a pachorra de pedir "apenas um botão" para ninguém, mesmo não sendo de TI. (Aproveito pra frisar que é completamente possível que alguém que não venha de TI consiga administrar desenvolvimento de software).

Outro problema frequente ocorre quando alguém atropela o processo e começa a desenvolver sem o mínimo de planejamento. Vou te contar que nem no ágil é assim. É preciso entender a ideia e planejar alguma coisa antes de sair fazendo, no mínimo. Quantas vezes eu assisti equipes que estavam trabalhando dentro de uma grande bagunça. Ninguém tinha briefing, ninguém sabia o objetivo direito, cada um pensava de um jeito sobre como devia desenvolver algo e o resultado era reclamações, retrabalho, prejuízos, perda de prazo.

Antes de partir pro desenvolvimento efetivo de um software primeiro quem vai tocar esse assunto PRECISA entender como ele deve ser. Seja o software para a própria empresa ou para um cliente externo. Enquanto essa pessoa não entender de verdade como precisa ser, ainda que o mínimo (mesmo que durante o desenvolvimento algumas coisas mudem) então o projeto vai fracassar.

Se nem o gerente (ou qualquer outro papel de outras metodologias) não for capaz de ter bem claro em sua cabeça do que se trata aquele software, não pode orientar ninguém. Depois disso é preciso ainda comunicar-se da maneira mais clara possível com a equipe e sempre se lembrar que cada pessoa interpreta uma frase, uma imagem, uma instrução de um modo diferente, baseado em suas experiências de vida e visões de mundo. Portanto, se você quer uma bicicleta não basta dizer que será uma bicicleta. É preciso dizer se é para fazer trilhas, por exemplo, ou pra apenas passear pelo bairro. Alguma orientação é muito bem vinda, mesmo que você adote o ágil.

A partir de hoje nunca mais peça a alguém apenas um botãozinho na ferramenta. Pelo menos não sem entender sobre outras questões, como as que expliquei aqui.

 Desenvolvimento de software não é peça pelo número (ou pode até ser, mas nem mesmo no cenário ágil poderá atender como um fast-food).