Feliz dia do programador! Ame seus desenvolvedores

Hoje é o dia do programador, o 256º dia do ano. E decidimos escrever um post não para nossos colegas desenvolvedores, mas para aqueles que estão ao lado deles e conosco. Para aqueles que nos trazem ao calor branco, isso nos faz ferver nossos cérebros, desabafar e falar nervosamente sobre a essência, a interface e as razões do prazo quebrado. Para vocês, queridos gerentes, empresários, analistas, gerentes sem formação em TI e outros amigos do escritório.

Se você ler o Habr, provavelmente terá que se comunicar com os programadores, pedir que eles concluam o front-end ou o back-end do site, altere o código de análise, pendure o próximo fragmento de código no cabeçalho do site, faça melhorias no software cliente e muito mais. Então, como encontrar uma linguagem comum com o desenvolvedor, para não brigar? Nós sabemos algo sobre isso.


Então, logo fora da lista.

Indique claramente seus requisitos. Sempre: não importa se você pede para fazer uma pequena seleção do banco de dados ou preparar um projeto de software sério para o cliente. Não há descrição das tarefas no formulário "Faça de mim um cartão de evento como um perfil do VKontakte" (muitos programadores trabalham no VKontakte, contratam a mesma quantia e fazem): "Bem, você faz tudo e eu escolho" (fazer várias opções para o programa é caro, você O CEO concordou?), “Vamos fazer uma bola” (esta é uma fita e são necessárias bibliotecas especiais para sua implementação). Primeiro de tudo, você deve entender o que deseja receber e é isso que o programador precisa transmitir. Formule os requisitos em russo, sem o escritório e declarações pseudo-técnicas - e sim, de preferência por escrito.

Falando em escrever. Esta é a maior invenção da história da humanidade, hoje otimizada pelo computador. Sinta-se livre para usar papel em uma conversa com o desenvolvedor:

• faça esboços e protótipos do que você deseja ver (se for um programa ou uma interface separada) - hoje existem muitas ferramentas para isso
  
• use mapas mentais para planejar o trabalho e criar um plano de projeto
  
• descrever a funcionalidade desejada da maneira mais simples e detalhada possível
  
• compõem os termos de referência (TOR).
  

Se isso lhe parece uma ciência complicada, pesquise no Google o que um analista de sistemas faz e o que ele usa em seu trabalho - muito pode ser levado em consideração.

Você não precisa usar diagramas, fluxogramas e pseudocódigo UML se não os possuir. No caminho, havia mais de um gerente fascinado pelos diagramas da UML e reunia neles tudo o que precisava: do plano da reunião à descrição da campanha de marketing. De fato, a ferramenta parece lógica e conveniente, no entanto - uma surpresa - a UML foi criada para projetar a arquitetura do software, e cada designação não é apenas uma seta ou um círculo, mas um componente muito significativo. Além disso, seu programador pode não conhecer a UML e, para ele, serão blocos completamente sem sentido.

A mesma história com os diagramas de blocos nos quais existem diferentes formas de blocos, não pela beleza, mas pelo pseudocódigo. Não há necessidade de escrever no estilo: “ SE mês = abril, ENTÃO placa de dados campo 1 campo 2 campo 3 ”. Isso é simplesmente um absurdo ilegível que não conquistará o serviço de TI, mas, na melhor das hipóteses, rirá.

Responda às perguntas a tempo. Todo mundo sabe que os programadores são ociosos, estão sentando e vendo seu código, nunca alcançarão gerentes com cem tarefas. Ok Ainda assim, quando você está conduzindo um projeto, você é responsável por ele e passa a tarefa ao programador, tendo a consciência de responder às perguntas a tempo. Não há necessidade de evitar chamadas e chats, marcar e-mails como importantes e colocá-los em uma pasta separada. O programador passa o tempo de trabalho interagindo com você, ele pode ter um simples por causa de uma pergunta não respondida - e a culpa é sua. Entre em contato durante o horário de trabalho sobre questões que você levantou antes de outros desenvolvedores. A propósito, isso também se aplica a clientes de terceiros.

E, no entanto - se você foi solicitado a ver o que aconteceu, avalie o protótipo ou teste a funcionalidade para saber se ele atende aos seus requisitos, não vá para dez funcionários vizinhos e não faça isso juntos. Então você aumenta significativamente o tempo até a conclusão da versão final.



Título "Suas maneiras". Compare consultas semelhantes em russo e inglês. Trabalho, amor, dinheiro - tudo é como todo mundo. Mas o mais importante, como eles veem os usuários?

Não culpe os desenvolvedores por todos os problemas. “O serviço de TI trabalha no código há tanto tempo”, “O pessoal de TI está perdendo o prazo final”, “Algo que o programador está pesquisando no TK há tanto tempo” - isso é familiar? É fácil culpar o problema por uma pessoa que interage com a tecnologia - bem, algo poderia estar errado lá também. Não, mantenha um registro de tempo rigoroso, registre o fato da transferência de tarefas (você pode fazer isso, por exemplo, no CRM ou no gráfico de Gantt), deixe que todos sejam responsáveis ​​apenas pelo seu trabalho.

Outro extremo - em caso de insatisfação do cliente, borrife cinzas em sua cabeça e grite: “O que você está fazendo! Procurando algumas críticas e traduzi-lo! Estamos perdendo dinheiro e reputação! Urgentemente! " O pânico é facilmente percebido pelos colegas e pela gerência; os nervos do programador estão no limite. Porém, na verdade, a porta do cliente caiu ou a velocidade da conexão caiu. Aprenda a não culpar, mas a perguntar: “Vasya, Volga LLC enfrentou um problema: não há conexão com o banco de dados. Você não pode me dizer o que poderia ser, onde cavar? " Sente a diferença?

Não traga idéias de todo o mundo para um rascunho de trabalho. O Google adicionou filtros à pesquisa, a Yandex ativou Alice, a Habr lançou uma nova versão móvel, o Salesforce ativou a inteligência artificial, a RegionSoft lançou o CRM v.7 e agora você está correndo pelo corredor para oferecer a introdução dessas tecnologias no projeto da sua empresa, porque é isso que elas fazem Gigantes de TI. No entanto, quaisquer alterações devem ser introduzidas em termos de viabilidade, relevância e retorno. E se as melhorias não beneficiam o usuário final e não geram lucro, sua implementação se tornará uma carga extra para o desenvolvedor. Prepare uma justificativa, cálculos, calcule o custo da introdução de recursos e somente depois tome uma decisão para começar a discutir o problema.

Não avalie a complexidade de um programador se você não é um líder de equipe. "Precisamos de um módulo para calcular o volume de uma caixa para o envio de um pacote, aqui estão os negócios de meio dia, vamos sentar!" - O comerciante otimista Masha chama e corre para beber chá antes da terceira reunião. Ao mesmo tempo, a própria Masha não sabe de onde ela tirou esse tempo. O programador tem tarefas de trabalho, problemas atuais, um rastreador de bugs paira sobre ele e um backlog pisca ao lado, por isso é entre eles que ele procura tempo para resolver o problema. E não é fato que o problema resolvido em 15 linhas de código possa ser resolvido durante o conjunto dessas linhas - o tempo leva para escolher o algoritmo, encontrar uma solução, selecionar bibliotecas, código de depuração, autoteste etc.

E o melhor de tudo, se você possui um regulamento de empresa que prescreve o procedimento para solicitar conclusões / descargas / veiculações extraordinárias etc. Nesse caso, todos se sentirão confiantes e saberão os prazos aproximados para resolver o problema. E sim, defina termos reais.



Não tente influenciar a pilha de tecnologias de desenvolvimento se você mesmo não desenvolver nada. A situação é banal: o gerente vai para a próxima conferência intergaláctica de TI, ouve relatórios e seu cérebro repentinamente interrompe que haja barulho por toda parte em Go, e então ele recebe um Gopher de pelúcia. E agora ele está na frente do departamento de TI, acariciando o esquilo encontrado e fala sobre as vantagens que Go ouviu e como usá-lo em nossa sangrenta empresa.

A resposta é simples. Os programadores são muito curiosos e aprendem sobre linguagens de programação, DBMSs, novos sistemas operacionais, bibliotecas e estruturas muito antes que outro participante da conferência escreva um relatório sobre eles. Ao mesmo tempo, eles não são apenas curiosos, mas procuram ver se essa ou aquela tecnologia pode se encaixar para facilitar o trabalho e fortalecer a fé no produto (porque os programadores também são extremamente preguiçosos no bom sentido da palavra). Portanto, cabe a eles decidir o que arrastar para a pilha de desenvolvimento e o que deixá-la descansar até melhores tempos e novas tarefas. E é improvável que você os supere nisto.

Tenha cuidado com a escrita , pois ela não transmite entonação (no entanto, isso se aplica a todos os colegas e outras pessoas em geral). Se você escrever “E faça uma descarga em uma hora)))))))))))))))” ou “É melhor implementá-lo, parece-me que ele diminui a velocidade))))))))))))))] " , Os colchetes não o salvam - a mensagem principal será lida. Descreva qualquer questão de trabalho de forma clara e sem emoção. Se você gostou do trabalho, pode dar uma barra de chocolate :-)



Após o pedido "por que os programadores russos são tão bons" eles deixaram para se orgulhar

Não imponha seus métodos de comunicação. Hoje, cada um de nós em um PC e telefone móvel possui uma dúzia de ferramentas de comunicação: Telegrama, Skype, SMS, telefone, Viber, correio, Slack, Jira ... E cada um deles tem seu próprio círculo de tarefas e assinantes. Portanto, se o programador solicitar que o final de semana escreva apenas no carrinho, defina tarefas apenas no Jira e ligue apenas pelo Skype, ele tem um bom motivo: ele tem certeza de que não esquecerá de fazer o trabalho associado a esses contatos. Mas o seu SMS "Comece na segunda-feira o relatório de pagamentos da primeira metade do ano" será perdido nos tópicos de discussão da campanha de domingo. Portanto, é melhor escrever sobre isso nos programas de trabalho e não se considerar excepcional e o mais eficiente na comunicação e definição de tarefas. Acredite, isso não é difícil.

Se você trabalha com programadores e cria programas para clientes externos, forneça um release. Ou seja, no momento em que o programa estiver pronto e lançado na produção, você deverá ter todos os materiais promocionais, visuais, apresentações, acordos e assim por diante. Isso é respeito pelo trabalho do desenvolvedor - porque nessa empresa ele desempenha a função de uma unidade de produção. Se você personalizou os programadores, eles fizeram tudo dentro do prazo e o lançamento foi adiado por três meses, este é um ótimo desmotivador e desvaloriza a equipe como tal. Raramente existe um programador que não se importa com o que acontecerá com seu programa no futuro e não está interessado em como ele se comporta no mercado e com os clientes.





O Yandex doméstico tem uma visão completamente diferente: até Ada Lovelace está classificada entre os programadores da 1C, e nas vagas principais estão Assembler e Delphi (se alguma coisa, procuramos em um navegador anônimo). Mas o principal é que existem 256 dias - e é hoje :-)

Aprenda com os programadores e aprenda terminologia. Uma pessoa que sabe programar, pensa sistemática e logicamente, sabe priorizar, vê a essência das coisas e conhece o assunto perfeitamente (não, bem, em homenagem ao feriado, você pode exagerar um pouco!). Ele tem muito a aprender - principalmente porque você trabalha na área de TI, precisa de um domínio decente do aparato conceitual e do vocabulário profissional. Comunique-se no trabalho, esclareça questões polêmicas, pergunte, lembre-se dos termos e suas definições - isso definitivamente não interferirá em sua carreira. Mas entender com um programador será definitivamente melhor.

Pelo menos você não escreve no portal corporativo "Feliz dia do programador", mas pode escrever algo como isto:

“Gente! Feliz dia do programador! É ótimo que você comprometa o código no prazo, refatore e torne nosso software ainda mais rápido e intuitivo, colete builds no tempo e execute-os na produção. Desejo a você commits de sucesso, bibliotecas confiáveis, estruturas convenientes e nós, usuários adequados. Você faz do mundo do presente um pequeno futuro. E nós amamos você!

Bem, você aprendeu nossa pequena lição? Agora, parabéns aos seus desenvolvedores.

Boas férias, amigos! Equipe RegionSoft Developer Studio , desenvolvedores de CRM poderoso e outros softwares para negócios, que sabem muito sobre comunicação entre usuários e programadores

---

Nosso canal de telegrama

Dizemos olá ao canal principal de Nizhny Novgorod sobre os eventos de TI e o site it52.info . Vá a eventos, esteja no assunto.