O artigo Um programador não deve resolver problemas de negócios causou uma discussão forte (e até mesmo uma resposta com a afirmação exatamente oposta).E é engraçado que tudo tenha se resumido ao raciocínio dogmático da categoria "programador deve" ou "negócio deve". Como se estivéssemos falando de um sistema que funciona com um objetivo comum, e o único problema é configurá-lo corretamente.De fato, tudo é muito mais complicado, e uma empresa com um programador tem objetivos muito diferentes. Portanto, falando sobre quem, quem e o que deveria, parece uma declaração de que o comprador não deve roubar mercadorias na loja. Sim, não deveria. Mais precisamente, ele não deve roubar, se ele fala de acordo com as regras da lógica formal. Simples, compreensível, aceito pela esmagadora maioria. E daí? Isso significa que a loja pode demitir guardas e derrubar câmeras?No meu primeiro artigo sobre Habré, considerei a situação da perspectiva do empregador (empresa) e expliquei os princípios que sigo para encontrar pessoas que resolverão os problemas da empresa . E por que isso é tão importante?Mas há uma ressalva, e é que pessoas que não são entrevistadas por entrevistadores como eu, com a devida destreza, conseguem mais do que aquelas que se beneficiam. E há uma boa razão para isso - eles maximizam com sucesso a habilidade que está mais correlacionada com a renda do programador - a capacidade de vender a si mesmo. Como, - vou contar neste post.Disclamer, . . , , , , Junior -> Middle -> Senior -> Lead dev -> Tech lead -> Architect -> Chief architect -> CTO.
Formulação do problema
Primeiro, vamos descobrir o que cada uma das partes deseja alcançar: osnegócios desejam uma solução barata e oportuna para suas tarefas de TI, satisfazendo as expectativas e, no caso de gerenciamento avançado, também criando novas oportunidades de desenvolvimento de negócios.O programador deseja cultivar seu valor no mercado de trabalho, maximizar as condições de trabalho (incluindo US $, cronograma, controle rígido, benefícios e vantagens), resolver problemas pelos quais você pode aumentar sua credibilidade e obter satisfação com a solução.Conflito
Na verdade, é fácil criar um exemplo em que todos saiam ganhando, como o desenvolvimento de um kernel DBMS proprietário, em que um programador resolve aplicativos atípicos do nível das olimpíadas, se esquiva disso, fala em conferências e depois aumenta as vendas, mostrando aos clientes como eficiência e estabilidade do núcleo do que os concorrentes, eles economizarão em infraestrutura.Mas não vamos falar sobre esses casos. Vamos falar sobre os casos enfrentados pela grande maioria dos programadores que tomam decisões comuns repetidas vezes. Outra loja on-line, outro cassino on-line, outro dia útil para um negócio bancário não tecnológico comum ...E há um conflito agudo. Porque soluções oportunas, confiáveis, previsíveis, baratas e bem suportadas são feitas em tecnologias testadas pelo tempo. Condicionalmente, se o painel de administração da sua loja on-line com o núcleo do ASP.NET estiver escrito em WebForms e os autores do código ainda não saírem com você, o painel de controle do sistema de recomendação recém-criado também deverá ser escrito em WebForms, embora o pacote .NET Core + Angular + TypeScript 1000 vezes melhor e, de fato, o WebForms é uma bagunça. Afinal, a equipe que escreveu os 500 formulários escreverá o 501º com rapidez e confiabilidade, ignorando o rake. E o negócio terá uma boa solução.Para programadores que perceberam o valor do WebForms no mercado, escrever nele pode ser uma tortura, porque eles entendem perfeitamente que, durante a redação deste formulário, aumentarão o valor dos negócios, mas ao mesmo tempo diminuirão os deles, porque enquanto você fica parado, a indústria passa por você. Portanto, nessa situação, qualquer programador sensato (mesmo sendo um co-proprietário, afinal, ninguém garantirá que a loja viverá para sempre e será muito doloroso procurar trabalho em caso de falência da loja) tentará, de alguma forma, concluir a tarefa em algo depois renovado e com demanda, é claro, gastando mais tempo ao mesmo tempo, permitindo mais bugs, pisando em mais ancinhos.É claro que esta situação é exagerada. Mas a essência permanece a mesma, independentemente do domínio e da tecnologia.Um código simples em uma solução de equipe conhecida e não HYIP testada pelo tempo fornece previsibilidade e confiabilidade aos negócios, e a equipe degrada. O código em uma nova estrutura de hype e / ou com alta complexidade algorítmica oferece desenvolvimento à equipe, mas os negócios sofrem riscos por isso. O foco em um profundo entendimento da área de assunto pelo programador pode aumentar significativamente o valor do negócio (escrever exatamente o que é necessário e não escrever o que não é necessário), mas não aumenta o valor do programador (o conhecimento da contabilidade raramente é solicitado acima no mercado para programadores) em tecnologias e algoritmos, pelo contrário.Afinal, um programador que está bem ciente de algoritmos e tecnologias encontra facilmente trabalho com um impulso, enquanto para os negócios a maior parte do conhecimento é redundante e inaplicável. E um serviço escrito em estruturas da moda com o uso correto de padrões e a complexidade algorítmica correta não ajudará muito os negócios se não fizer o que era esperado.Sim, existem fatores colaterais. Por exemplo, os tópicos de hype simplificam a contratação, e o legado infernal reduz o fluxo de pessoal existente (as pessoas gostariam de sair, mas em nenhum lugar), mas essas são nuances e não são tão importantes.Soluções
Então, vamos imaginar o momento em que o programador percebeu que a empresa queria recompensá-lo um pouco (ok, digamos, adiar seu desenvolvimento) por uma causa comum. O que pode ser feito?Obedecer. E perder em seus próprios interesses. Os comentários são redundantes.Diretamente entre em conflito. Por assim dizer, eles dizem que eu não sou escravo de você. Se você deseja um código primitivo de copiar e colar com um profundo conhecimento de contabilidade, procure um tolo. Eu não farei isso. Talvez uma carona uma vez. Mas não há necessidade de falar sobre uma carreira aqui.Para convencer os negócios de que eles precisam exatamente do que você precisa.Esta é uma opção correta para o programador. Sim, é difícil conseguir com um alto nível técnico do gerente e poucas habilidades de persuasão do programador. Mas sempre vale a pena tentar. Depois de perder, você sempre pode escolher p1 e economizar até a próxima vez. E ao vencer, você obtém respeito e um senso de valor do negócio e do seu crescimento profissional ao mesmo tempo.A única questão é como obter esse santo graal?Aqui veremos algumas histórias fascinantes.História 1. Sobre o chefe do departamento Vasily
Vasily foi um dos programadores mais experientes da corporação. Ao longo de uma carreira de vinte anos, ele passou de um programador júnior para um chefe de departamento. Ele tinha 40 pessoas com subordinados diretos, resolvendo problemas diretamente com o fundador, e não com o CEO e seu substituto, como outros gerentes de seu nível. E ainda mijando código para ficar em forma. Ele fez sua carreira devido ao fato de ter uma inteligência excepcional e, além disso, os negócios poderem se comunicar com ele no mesmo idioma. Antes disso, Vasily estava em uma corrida constante. Ele fez promessas e com todas as suas forças as alcançou. Por isso, ele foi adorado. Sim, havia rumores de que ele sempre solicitava prazos muito longos, mas, por outro lado, os movia com muito menos frequência do que outros chefes de departamento.E então ele foi reconhecido como o melhor gerente do ano, eles começaram a dar a todos um exemplo, e Vasily (que em seu coração nunca deixou de ser programador) percebeu que era hora de aprender novas tecnologias, e às custas de seus subordinados para experimentar novas abordagens, em particular com DDD.O principal produto do departamento Vasily, a estação de trabalho automatizada (AWP) do operador futuro, ajudou a ganhar muito dinheiro e, ao longo dos anos de operação, quase todos os bugs foram capturados e polidos. O problema era que era um aplicativo de desktop para Windows (enquanto todos estavam mudando para a web) e usava o MSSQL como um DBMS, que, segundo Vasily, também era uma idade da pedra, porque o DBMS relacional era usado enquanto as pessoas não aprendeu a fazer bases normais.E agora estamos falando sobre a necessidade de escrever um local de trabalho automatizado para um trader opcional. O projeto durou cerca de 6 meses, incluindo a introdução de tópicos de uma nova equipe e testes beta, se forçarmos os nabos do terminal de futuros e substituirmos vários módulos. Mas, droga, fazer outro produto usando tecnologias desatualizadas ... Bem, isso não é interessante. Sim, e as pessoas terão que caçar acima do mercado, porque ninguém quer aproveitar isso (e a capacidade de caçar e manter pessoas 20% abaixo do mercado foi o recurso assassino de Vasily) e, portanto, o fato de caçar acima do mercado teria abalado sua reputação.Portanto, o que Vasily fez - ele convenceu o CEO de que, em prol do lucro e da estabilidade dos negócios, tudo deve ser escrito com 0, uma nova equipe, não deixe de entrar na Web e não levar um único byte da solução antiga, embora demore dois anos. Dada a sua reputação e experiência profissional, não foi tão difícil.Dois anos depois, a decisão estava em prod. Estruturas novas, MongoDB, DDD, funcionam no navegador, e não um único byte do terminal para futuros ... É verdade que montanhas de copiar e colar, arquitetura que não permite a integração de algoritmos sem muletas, reescritas a partir de 0 módulos, em que os elegantes algoritmos da estação de trabalho futura foram substituídos por toneladas de código padrão. Basil, no entanto, elevou sua autoridade muito bem. A estação de trabalho opcional por muito tempo citada como exemplo para outros gerentes. Depois de alguns anos, Vasily ainda caiu em desgraça, mas isso é outra história.No total, o ponto principal: Vasily descobriu novas tecnologias, inflou a equipe, aumentando sua importância, e a empresa permaneceu completamente confiante de que ajudou a empresa e mais uma vez cumpriu suas promessas.História 2. Sobre a virgem Anton
Anton, com 30 anos, adorava aprender novas tecnologias e resolver problemas das olimpíadas. Ele ocupava um lugar quase ideal para o seu tipo - era a donzela principal da equipe de infraestrutura. Anton conhecia muito bem as especificações e as últimas tendências arquitetônicas. E o desafio intelectual favorito de Anton era apresentar justificativas sobre como as tecnologias de hype ajudariam as empresas e onde exatamente elas deveriam ser levadas. Nisto, ele foi apoiado pelo arquiteto, que também não era avesso a sondar o novo ancinho com a testa de Anton. Como resultado, Anton foi convidado a conversar com FAANG, onde passou por toda a parte teórica sem problemas, e concluiu de maneira brilhante a tarefa de projetar a arquitetura Ebay (embora nada desse tipo tenha sido exigido no trabalho anterior). Então ele partiu nos EUA e deixou para trás três módulos altamente carregados no produto, que agora ninguém quer manter e desenvolver,porque ninguém entende como (e por que) eles funcionam.Total, no final das contas: Anton sabia claramente o que queria e alcançou seu objetivo, aproveitando ao máximo o empregador. Os negócios também tinham certeza de que Anton era um funcionário muito valioso, porque, como eu já mencionei, ele sempre pensava cuidadosamente na lógica, mesmo quando eram loucos por pessoas do assunto.A história do arquiteto Ivan
Timlid Ivan e Timlides Vladimir e Yuri viram o produto sob a liderança do arquiteto Sergey. Sergey trouxe os três para a empresa, e os quatro tomaram decisões importantes. Depois que o produto foi colocado à venda em 4 anos de operação, mas ainda estava longe da estabilidade, a liderança atacou Sergey e ele saiu com a cabeça erguida. Depois dele, Vladimir e Yuri foram embora.A certa altura, Ivan se tornou o único portador de conhecimento sobre o que foi escrito (exceto os idosos e os médios, a quem Sergei não dedicou particularmente à visão geral). Sentindo o cheiro de frito, a liderança nomeou Ivan como arquiteto, com a equipe correspondente, na esperança de que ele não fosse embora. Para o que Ivan disse, eles dizem que isso, é claro, é bom, mas isso não é suficiente para que eu não saia. Se você quer que eu apoie o que vimos com Sergey, deixe-me reescrever tudo com 0. Os negócios concordaram com relutância. Ivan recebeu salário, cargo e a capacidade de escrever tudo de 0 em um dia.Total: Ivan entendeu corretamente qual era o problema do negócio - o negócio está em pânico com medo de que o que viram durante o tempo de Sergey possa falhar e não haja ninguém para descobrir isso. E ele pressionou o negócio ao máximo.Total
Quer você queira ou não, mas por uma carreira, US $ e pela oportunidade de fazer coisas interessantes para si mesmo, você precisará pelo menos conversar e pensar no valor dos negócios. Sim, você pode trazê-lo, não trazê-lo, ou até trazer o negativo. Mas nesse sistema de relações, quanto mais longa a cadeia de valor que você controla para quem paga, mais forte será a posição de negociação e a capacidade de fazer o que deseja, em vez de declarar.