Executando verificação de segurança...
4

Como ser mais participativo em discussões técnicas do time?

Sou dev e, há seis meses, fui promovido de Júnior para Pleno na empresa onde trabalho. Na semana passada, houve uma rodada de feedback e durante um one-on-one, meu manager me deu um feedback que não sou participativo em discussões técnicas.

Realmente, isso é verdade. Tenho que admitir. Em refinamentos e nas daily, quase nunca exponho minhas opiniões e isso geralmente acontece por dois motivos:

  1. Não consigo pensar em algo que contribua para as discussões.

  2. Tenho um pouco de medo/vergonha de que minha opinião seja considerada ridícula (a velha síndrome do impostor).

Se eu for listar, com certeza o motivo número 1 é o mais frequente, acho que acontece umas 80% das vezes. Mesmo durante os refinamentos, simplesmente não consigo ter ideias. Quando meus colegas levantam pontos de discussão, sempre penso: "Como não pensei nisso antes? É tão óbvio."

Percebi que ser mais participativo(soft skill) está diretamente relacionado a uma progressão mais rápida na carreira aqui na empresa. Vocês tem alguma dica ou algo que vocês fazem que ajudam vocês a serem mais participativos?

5

Não sei se vai te ajudar de alguma forma, eu pessoalmente não me recordo de ter passado por isso (Provalvemente passei, mas eu já estou velho e não me lembro.). Mas vou tentar deixar alguma dica.

Consuma material técnico ligado de alguma forma com as suas atividades, por exemplo, atualmente você trabalha em um serviço de autenticação escrito em PHP. Mas navegando pelos sites, newsletter, Feed RSS... você se depara com algum artigo de como criar um serviço de autenticação em Java, mesmo que você não trabalhe com Java percebe que o conteúdo tem alguma relação com seu trabalho? Ao ler o artigo você verá formas diferentes de resolver o mesmo problema, e isso aumenta seu repertório.

Se prepare para as reuniões, tem que ter bastante experiência para chegar em uma reunião e dar sugestões técnicas sem estar a par do assunto. Como não é seu caso, então sugiro que tente se antecipar com os assuntos e já ir pensando em possíveis soluções para os problemas que serão apresentados.

Dê sugestões mesmo sem saber se daria certo, se ficar se contendo para falar pois não tem certeza se sua ideia é válida ou não, infelismente você terá feedbacks como esse do seu chefe. Não precisa ter uma solução correta para sugerir ao time, você pode levantar a mão e dizer: Não sei se daria certo, mas se a gente fizer.... e a ideia pode ser ruim vão te falar isso, pode ser boa mais incompleta e vão te falar isso, e pode ser excelente e também vão te falar isso. Não se pode ter medo de falar na reunião.

1

Realmente, talvez essa parte de se preparar para as reuniões eu não faço tanto. Acho que se eu chegar com um contexto antes das meets vou conseguir ser mais participativo.
Thanks😊

4

O importante é não cair no mesmo erro.
Não tem problema você não ter ideias.
Anote as perguntas inteligentes e sugestões inteligentes dos colegas, os problemas tendem a se repetir, então você usa o que aprendeu, ou seja, sua experiência.
Por exemplo, não é minha ideia, mas quando alguém diz, junta a informação dos dois campos, imediatamente já pergunto: Quer algum separador entre as informações? Se sim, vai ser o quê? espaço, hífen, vírgula, etc.

Segue uma anotação antiga que seu seguia

Segue abaixo algumas dicas para se construir um bom software independente da linguagem de programação a utilizar:
· A tecnologia deve se adaptar ao usuário e não o oposto. Tenha sempre isto em mente.
· O usuário deve sentir que tem total controle sobre a aplicação. Como por exemplo: sempre cancelar um comando ou desfazer alguma ação. Escolher a fonte, tamanho da fonte, tamanho da janela, posição da janela etc. Aconselho que essas definições, estejam disponíveis no item de menu “Preferências”.
· Em menus e botões utilize nomes curtos. Não ultrapasse dois níveis de opções nos menus.
· Vá além do que o usuário ou cliente exige, pois infelizmente e na maioria dos casos, ele não tem uma visão abrangente do assunto. Pesquise, converse e descubra o máximo que puder sobre o assunto. Utilize suas experiências anteriores.
Você não é apenas um programador, ou seja, um digitador de códigos, você agora é um desenvolvedor, pois está envolvido em um projeto e todos seus processos.

Ícones
Abuse da utilização de ícones. Eles ajudam a memorizar um comando ou função. O ícone deve ser coerente com o comando ou função. Utilize ícones com 32-bits de cores, modernos e brilhantes, pois dará impressão de um software também moderno, caso contrário parecerá com um software ultrapassado, mesmo que não seja.

Aparência é importante
Um professor meu dizia: "Um trabalho desleixado é o sinal de uma mente negligente!"
Há muita verdade nisso.
Se não existiu preocupação sequer com a aparência da tela a ser exibida de um modo correto, o que dizer sobre o resto do seu trabalho?
Seu profissionalismo deve ser evidente em cada parte do seu trabalho.
Se o que é visto pelo público é de má qualidade, não há razão para acreditar que o trabalho por trás da interface é algo bom.
Muitos de nós desenvolvedores não somos especialistas em desenhar interfaces bonitas e legíveis, então devemos levar em consideração, a contratação de alguém nesta área.

Valide os dados
Valide todos os campos (CNPJ, CPF, I.E., cartão de crédito etc.)

Filtre os dados
Sempre utilize máscara de entrada quando possível.
Evitando entrar caracteres num campo numérico por exemplo.
Impeça a digitação de caracteres especiais como: vírgula, dois pontos, ponto-e-vírgula, travessão, aspas simples, aspas duplas, espaço etc.
Obs.: Nunca armazene na base de dados a máscara de entrada, mas somente os dados. A máscara de entrada serve somente para “guiar os olhos” durante a digitação.

Limite os dados
Se um campo numa tabela cabe apenas 30 caracteres a exemplo, então limite a caixa de texto a 30 caracteres também.

Registro duplicado
Para evitar isto, antes de inserir as informações procure na base de dados e verifique se o registro já existe.

Assistentes e componentes úteis
Abuse dos assistentes segue abaixo alguns exemplos:
Nos formulários inclua a opção classificar e filtrar os dados.
Nos relatórios, também inclua a opção classificar e filtrar os dados.
Nos campos de data sempre inclua um calendário para que o usuário possa consultar uma determinada data facilmente.
Nos campos de caminho do arquivo (path) inclua sempre uma caixa de diálogo para o usuário selecionar o arquivo, evitando assim que ele digite todo o caminho manualmente e eventualmente cometa erros.
No caso do formulário conter campos numéricos e outros que efetuem cálculos, disponibilize uma calculadora para o usuário, pode ser a do próprio Windows, sem problemas. Obs: Disponibilizar uma calculadora para o usuário, não implica em deixar campos sem cálculo automático, deixe essa tarefa por conta do seu programa, poupando tempo e evitando erros por parte do usuário.
Durante o preenchimento de um endereço ou localidade, coloque o campo CEP em primeiro lugar, após o usuário tê-lo preenchido consulte o CEP na base e retorne o estado, endereço, município e bairro automaticamente.
Ao criar um relatório inclua sempre as seguintes funções:
1º Selecionar Impressora.
2º Configurar Impressora.
3º Configurar Página.
4º Uma opção interessante e a de exportar os dados como texto separado por tabulações, geralmente o usuário necessita manipular os dados do relatório em outro aplicativo. O arquivo texto é simples, pequeno (na maioria dos casos) e rápido de ser importado. Outra vantagem e que praticamente todos os softwares do mercado suportam este formato.
5º Opcional. Se possível inclua a opção enviar. Esta opção permite enviar o relatório ou dados utilizando o correio eletrônico (Outlook ou Lotus Notes).
6º Opcional. Habilite o modo estrutura do relatório para o usuário, inclua a opção retornar ao padrão, deixe-o salvar e importar a sua própria estrutura.

Mostre que o software está trabalhando
O usuário deve sempre saber que algo está acontecendo, principalmente numa tarefa demorada que pode consumir alguns minutos para ser executada. Mostre uma ampulheta, ou uma barra de progresso, ou uma barra de status para informar o usuário. Evitando que ele comece a teclar ao acaso para ver se algo acontece. Apenas alguns segundos de inatividade, já faz com que o usuário se sinta frustrado achando que o programa está travado.

Salve
Nunca feche um formulário sem salvar ou execute qualquer outra ação sem salvar os dados ou ao menos perguntar ao usuário se os dados devem ser gravados. Qualquer falha nesse sentido causará receio do usuário a você e ao seu software.
Salve toda a configuração do usuário, mesmo que pequena. (pasta, nome de arquivo, posição das janelas etc.)
Adicione suporte a backup da base de dados e insista para que o usuário faça backups regularmente, através de mensagens de avisos.

Ajuda
Habilite a ajuda no seu software para quando o usuário pressionar F1 obtenha detalhes sobre o processo em que está utilizando.
Informe na ajuda os processos mais simples. Lembre-se o usuário não é obrigado a adivinhar como seu software funciona, mesmo se tratando de tarefas óbvias.
Efetue a documentação do seu software.
Toda mensagem de erro deve estar no idioma do usuário. O botão de ajuda deve estar disponível sempre, para que o usuário obtenha detalhes do erro, além da solução quando possível.

Treinamento
Não cometa o erro de simplesmente largar o software na mão do usuário.
Para garantir o bom uso do seu software, inclua na venda ou aluguel o valor para treinamento ou suporte.
Faça questão disso. É um item indispensável.

Integração
Integre seu software com outros aplicativos comuns ao usuário como Excel ou Word. Por exemplo, exportar dados para o Excel ou fazer mala direta entre sua base de dados e um documento do Word.

Instalador
Se o seu aplicativo não for do tipo web, crie um instalador para o seu software, nada de pedir ao usuário para criar pastas, manipular arquivos, registrar componentes manualmente, configurar o registro do Windows etc. Crie o instalador e apenas peça para dar dois cliques.

Respeito
Respeite os usuários, eles não são técnicos e nem programadores. Não são obrigados a entenderem termos técnicos ou efetuarem procedimentos deste nível.
Evite piadas como:

  • Se o capim mudar de cor, o burro morre de fome.
  • É BIOS. Bicho Ignorante Operando o Sistema.
  • O problema é a pecinha entre o teclado e o monitor.
    etc.
    Se todos tivessem as mesmas habilidades, experiência e idéias, a vida não teria diversidade, criatividade e entusiasmo. ;)

A importância do Usuário
Qualquer projeto que você desenvolva tem de envolver usuários. Eles são as pessoas que vão sentar na frente de sua interface por oito horas por dia e decidir se gostam ou não. Se não gostar, não importa o quão eficiente o código seja e quantos milhões foram gastos em desenvolvimento, eles vão encontrar maneiras de sabotá-lo.
Lembre-se: somos apenas desenvolvedores, não importa o quão legal seria ter todo texto roxo sobre um fundo laranja, é o usuário que vai dizer o que é legal e o que não é.

Tolerância a falhas
A aplicação deve ser tolerante a falhas. Usuários cedo ou tarde irão cometer erros. Um único erro não deve derrubar a aplicação. Se não há espaço para erros, os usuários terão medo de experimentar, de descobrir por conta própria como fazer as coisas. Isso retardará o processo de aprendizagem consideravelmente.

Paz e harmonia
Quando a coisa não anda bem, é difícil manter o bom andamento do projeto.
A desavença entre desenvolvedores e testadores; consultoria e cliente etc. infelizmente é frequente. É preciso ter em mente que todos são parceiros e devem trabalhar para um bem comum, deixando determinadas coisas de lado, pois não agregam valor nenhum como:

  • Disputa para provar que tem razão.
  • Não assumir erros.
  • Focar em achar culpados, ao invés de tentar solucionar o problema.

Experiência própria
A consultoria onde trabalhei, responsável por implantar um determinado software, já chegou a perder 3 dias porque o cliente culpava o software de não enviar e-mail e a consultoria dona do software culpava a infra-estrutura do cliente.
A consultoria de software revisou todo software e informou que o produto estava correto e chegou até sugerir determinados testes de rede.
O cliente se recusava a fazer os testes, pois rede era o ramo de atividade deles, eles sabiam o que estavam fazendo e nenhum e-mail foi enviado ao servidor de e-mail deles.
Após uma reunião fervorosa, aceitaram os testes e finalmente começamos a trabalhar juntos para a solução do problema, concluímos então que o e-mail estava sendo barrado pelo antivírus deles, ou seja, era um problema de infraestrutura sim, pois todo firewall e antivírus é responsabilidade do pessoal da infraestrutura. Eles focaram somente na rede, mostrando apenas evidências coletadas dessa. Por ego próprio, acabaram ficando cegos, esquecendo-se de checar outros itens que compõe a rede.

2

Olá amigo, vou tentar ajuda-lo.
Para se tornar um bom dev, terá que aprender ter um bom senso analitico (lógico e sistemico), dito isso é importante que adquira um bom conhecimento do negócio isso vai ajudar muito a contribuir positivamente nas Daily.

Digo isso pois nas Daily são discutidos poucos aspectos técnicos e mais de negócio, vou tentar exemplificar.

O joaquim do seu time está mexendo no cálculo de imposto de renda que é feito dentro do sistema, no qual está com problema no valor final quando o cálculo usando não é o simplificado.

Se você conhecer o negócio, você já irá perguntar: (Quando isso ocorre? Está em uma situação específica? Se não adicionar no imposto o bens de direito o cálculo funciona?)

Veja que o problema é uma regra de negócio e por ter algum conhecimento consegue fazer algumas perguntas para se aprofundar no problema e sugerir testes para ver se o problema continuará ocorrendo.

Em pouquíssimas ocasiões me encontrei em daily que o problema seja mais técnico mesmo, isso eu costumo pegar mais no code review (e depois falo com o dev para entender melhor as decisões tomadas) do que na daily

2

Hum, verdade. Eu realmente não vejo as coisas tanto com a "lente" de negócios. Vou começar a me forçar a enxergar mais as coisas dessa forma.
Thanks😊