Manual de boas maneiras, porque ainda é preciso sim.
Ahhh mas Mayara, o que você está fazendo aqui?! O Bar8 é o blog do desenvolvedor, você nem é desenvolvedora— Intruder alert!
Essa é a hora que preciso contar uma verdade para vocês: Estamos no mesmo barco. #Shocked
Então vamos começar assim. Trabalho com SAP e sou consultora funcional, porém, vivo rodeada de programadores (grande parte dos meus amigos, leia-se “a maioria” são programadores e, como se não bastasse, casei com um também…então, o assunto é tema em casa, no trabalho, nos bares…#hard) e meio que acabei “vestindo a camisa” do Time ❤ programadores. Desde então, venho me dedicado a entender como funciona esse mundo de TI e aprender sobre como posso ser melhor no meu dia-a-dia no trabalho para que as coisas funcionem como a parceria que deve ser. Afinal, somos uma equipe!
Pensando nisso, tive a ideia de escrever esse “manual” no intuito de falar mais sobre esse relacionamento de amor e ódio em que vivemos. Essas foram as primeiras coisas que precisei entender:
1- Você trabalha com um sistema, entenda como sistemas funcionam.
Não estou falando para iniciar agora uma faculdade de ciência da computação para conseguir conversar com um programador, apenas para que tenha noção de como sua ferramenta de trabalho funciona. Quando entendemos como funciona a base de um programa, ou a lógica com que os sistemas trabalham, na hora de fazer uma solicitação ao desenvolvedor, será mais fácil discutir sobre a problemática e contribuir com ideias e soluções.
Assim que comecei a trabalhar com SAP, tive um pouco dessa dificuldade de como fazer uma solicitação ao desenvolvedor, pois não sabia bem como pedir os ajustes necessários a serem feitos e desenvolvimentos de uma forma que fosse viável e sem parecer uma “noob” falando. Comecei então a estudar lógica da programação (veja que não estou dizendo sobre aprender a linguagem ABAP), não foi nada avançado, apenas o suficiente para ter uma noção básica de como funciona.
O primeiro contato que tive com programação foi com Web (HTML, CSS e Javascript), depois passei a estudar um pouco de lógica de programação com jogos em Ruby. Vamos deixar claro que não sou programadora, e se me pedirem para fazer algo usando essas linguagens, não vou sair escrevendo códigos, pois realmente não tenho o conhecimento e experiencia o suficiente para isso. Lembre que o meu intuito era entender os princípios de lógica de programação.
Uma dica para quem quer algo mais simples de entender, sem ter que entrar no mundo de realmente aprender uma linguagem de programação, seria o Visualg, um software feito para criar, editar e interpretar algorítimos que usa como linguagem o próprio português estruturado. É gratuito e utilizado para aprendizado.
A partir do momento que você entende como essa lógica funciona, já pula toda aquela parte de “ah, mas é só colocar um campo aí, não pode ser tão difícil assim”, e o desenvolvedor pode pular também aquela em que ele respira fundo para não te responder com um “ se é tão simples, por que você não faz?”, não é mesmo?
2- Seja específico
Se necessário e possível, desenhe. As pessoas veem a frase do “entendeu? ou quer que eu desenhe?” como uma afronta, mas eu, particularmente, sou uma pessoa super visual, então, se eu puder desenhar, desenho mesmo.
Programas funcionam com uma lógica onde várias decisões devem ser tomadas, “If this, than that”
Então, por que não colocar tudo isso num diagrama para facilitar as escolhas?
É importante que o programador saiba o que deve ser esperado daquela ação, assim ele saberá se código está funcionando ou não de forma correta.
Existem várias ferramentas para criar fluxogramas, uma que uso bastante é o sketchboard. Tem a versão gratuita que é mais limitada por ter poucos boards e um time pequeno, porém, precisei só para coisas pontuais então foi o suficiente. Para quem quiser mais ferramentas, pode optar pelas versões pagas com mais opções de planos. Nele você pode montar uma equipe para ter acesso ao projeto que está criando e o legal é que, em equipe, podemos ver a alteração que cada um está fazendo em tempo real.
3- Seja claro
Assim como nem todos os funcionais devem saber programar, os programadores também não são ‘obrigados’ a saber os detalhes da parte de negócios de cada área, porém, assim como é importante que nós entendamos a lógica de programação, é importante que eles entendam o contexto e as intenções do cenário para saber o que ele está desenvolvendo (essa moeda é a mesma para os dois lados). Por mais que estejamos criando um único produto com um determinado objetivo, esse mesmo produto terá interações diferentes e usabilidades diferentes para cada departamento, então é necessário entender o negócio como um todo para criar um produto maduro.
Se o funcional entende a lógica de como o sistema funciona e o desenvolvedor entende a ideia do negócio, conseguimos nos comunicar na mesma língua e entender o processo como um todo, assim, o trabalho irá fluir de forma clara e coerente.
Aí é aonde a gente se entende — ou deveria — na tão polemica documentação/especificação. Uma especificação que tem os objetivos claros e detalhados de maneira que ambas as partes consigam entender, evita reuniões (principalmente conflitos) desnecessárias, ganho de tempo e performance. Um processo bem documentado irá servir de ajuda num futuro quando outras pessoas precisarem entender o desenvolvimento ou até mesmo dar algum tipo de manutenção (quem nunca quebrou a cabeça por horas e horas tentando entender um cenário que deveria funcionar de forma X e depois de muito tempo, descobre que existe um desenvolvimento no meio de tudo aquilo e que muda totalmente o cenário standard? Mas as pessoas que fizeram esse desenvolvimento já não trabalham mais naquela empresa e agora ninguém sabe como aquilo funciona).
A documentação deve ser acessível por todos do time, e temos várias ferramentas que podem nos ajudar com isso como o Confluence ou o sharepoint. Eu, particularmente gosto bastante do Confluence, você pode criar páginas, editar, anexar arquivos, criar times, é fácil de trabalhar, já possui vários templetes para serem utilizados e possui integração com os outros produtos da Atlassian (como o JIRA ou o Trello que também fazem parte dos meus queridinhos). Mas é claro que antes de decidir qual ferramente usar, precisamos entender a necessidade de cada empresa, no meu caso, o Confluence é mais do que o suficiente.
Essa questão de documentação também já foi discutido num post anterior com o Antelio I. Abe, se você não viu…vai lá ver!
Acho que esse vídeo resume o que estou tentado dizer nesses 3 primeiros tópicos. Faz parte do Exact Instructions Challenge, isso começou com o Josh Darnit em um vídeo onde ele pede à seus filhos que o ensinem a fazer um sanduíche de pasta de amendoim e geleia escrevendo um Modo de preparo e é bem divertido ver como isso não é tão simples assim quando você desconhece o processo e tenta apenas seguir à risca o passo a passo. Baseado nisso, o Jeferson do canal LinuxTips, resolveu realizar o mesmo experimento. O ponto é mostrar como as vezes esquecemos de ser específicos no momento de escrever uma instrução por parecer simples ou obvia para nós, esquecendo de que para uma máquina, não é tão obvio assim. Por isso reforço, entender como a lógica das coisas funcionam, ser claros nas solicitações e específicos sobre o que querem, é muuuuito importante!
4 — Frases proibidas
Sabemos que a boa comunicação é algo imprescindível para um relacionamento dar certo, então vamos tomar cuidado?
- “ Demora todo esse tempo para fazer só isso?” — de novo, não fale se você não sabe o que está por trás disso. Esse “só isso” pode ser um monstro de 7 cabeças, por mais simples que pareça.
- “ As coisas não dão certo por que esse programa não funciona, ̶é̶ ̶u̶m̶a̶ ̶m̶e̶r̶d̶a̶!”/o desenvolvedor não fez direto — ué, algum da área de negócios precisou atuar junto na especificação e testes, não é? a falha pode ser de mais de uma pessoa. Vamos tentar entender onde está o GAP e solucionar, se tiver uma dica sobre como melhorar a funcionalidade…eis a oportunidade de fazer algo que ajude ao invés de apenas julgar.
- “Dá pra fazer mais rápido?” — dá…sempre dá… mas, qual a qualidade que deseja receber? — sei que às vezes é muito estressante aguentar “a pilha” do cliente, mas devemos ser realistas também. Ficar apressando o desenvolvedor, não vai ajudar em nada.
Deixe nos comentários as suas frases do coração.
E a dica para esse é fácil :
Por ultimo e não menos importante…
5- Não interrompa
Pense para que a sua solicitação funcione, é necessário criar toda uma logica, avaliar onde tais programas devem ser chamados, como proceder em caso de sucesso ou de falha, entre mil outras coisas que nem sempre são tão simples assim de escrever e ter que parar por “ 1 minutinho só” e retomar a linha de raciocínio depois. A gente sabe quando eles estão no mundinho deles, da medo de chegar perto…eu entendo, mas realmente pode atrapalhar…É claro que em um momento ou outro, é mais eficiente chegar direto na pessoa para fazer algum alinhamento, o problema é quando ficam te interrompendo de 5 em 5 minutos ou quando você da um prazo de 2h para uma entrega e pessoa volta em 30min perguntando se “vai ser em 2h mesmo ou dá pra terminar ah antes?”, em 1h “ nada ainda?só pra saber mesmo”…(e isso vale para todos, queria que os clientes entendessem isso também)
Algo que uso para organizar os meus atendimentos é o Trello, realmente uso trello para tudo no trabalho, como já mencionei, sou uma pessoa muito visual então um quadro Kanban me ajuda bastante a controlar minhas demandas. Organização é o que há!
Você pode trabalhar com equipes e acompanhar o fluxo de atividades, adicionar prioridades, check lists, saber quem está atuando em cada ponto…Você também pode adicionar vários power ups ( ferramentas que integram com o trello como calendário, fazer votação, marcar reuniões, várias opções para dar um up no seu trello. Assim fica fácil saber quem está atuando na sua demanda e status do atendimento, sem ter que ficar perguntando toda hora pra alguém.
Mayara, sério que é preciso escrever isso? é bem sério… as pessoas nem sempre entendem. Por mais que pareça ‘óbvio’, ainda encontramos muitos problemas desses tipos dentro das empresas,o que acaba gerando muito descontentamento e intrigas dentro das equipes.
Bom, poderíamos ficar o dia todo aqui discutindo sobre esse tipo de problemas que todos já passamos, e sobre como trabalhar com nossos tão amados programadores ( a gente precisa tratá-los bem também né, sabe como é…melhor tê-los por perto hihihi), mas acho que isso aí foi o básico que tive que entender para conseguir me tornar uma parceira de trabalho melhor. Sempre peço feedbacks ( podemos falar sobre isso em um próximo post) também perguntando sobre como foi o nosso trabalho juntos, se ficou claro ou como posso melhorar, pois é algo muito importante dentro de uma equipe.
#momentoBlogueirina
E se você curtiu o post, pode aplaudir, compartilhar e também não deixe de contribuir com comentários…Dessa forma, nos ajuda a identificar os tipos de postagens que vocês curtem e que gostariam de ver mais por aqui!
Obrigada =)
