Você precisa escolher o software que precisa: escrito dentro do prazo ou de alta qualidade

Espero conseguir atrair sua atenção com uma manchete tão provocativa (e, reconhecidamente, exagerada). Bom Agora, deixe-me reformulá-lo de uma maneira um pouco mais elegante e menos atraente :

Em princípio, o software pode ser escrito pontualmente ou bem, mas não os dois ao mesmo tempo *

* exceto em alguns casos nas equipes de alto desempenho existentes

Há vários meses que eu penso sobre por que a criação de software de alta qualidade não se encaixa bem com as datas e o planejamento estimados em geral. Durante minha carreira, vi projetos construídos em uma variedade de modelos (em cascata, genuinamente flexíveis, em cascata com flexibilidade), e todos eles tinham uma coisa em comum: não importa em que projeto estamos trabalhando, se ele foi realizado “ pela ciência” ( ou seja, não nos permitimos truques sujos, por causa dos quais teríamos pesadelos depois), sempre quebrávamos os prazos.

Por outro lado, sempre que o projeto era entregue “no prazo”, isso significava que, inevitavelmente, era necessário reduzir seu volume ou cortar tantos cantos que, durante as montanhas de implementação da dívida técnica acumulada, praticamente garantindo que o projeto fosse reescrito logo após. lançamento. Portanto, comecei a me perguntar: podemos realmente assumir que o projeto foi entregue “no prazo” se, como resultado, tivermos um suporte feio e inconveniente, cheio de bugs e, francamente, uma versão mais feia do código em comparação com o que originalmente tentou fazer?

Traduzido para Alconost

Tive oportunidade de trabalhar em projetos sem prazos rígidos. Sim, formalmente "prazos" estavam lá, mas longe de serem de concreto armado. Todos entenderam que nossos prazos são flexíveis e que a qualidade é mais importante que a entrega pontual do produto. Foi nesses projetos que obtivemos o melhor software, havia os desenvolvedores mais satisfeitos e, em geral, esses projetos foram dos mais bem-sucedidos dentre todos os que tive que trabalhar. Mas todos sabemos que esses projetos são muito raros, caso contrário, eu não teria escrito tudo isso.

Então, por que é tão difícil planejar o trabalho e distribuir um bom software, com prazos rígidos? Eu acho que isso se deve em grande parte à criatividade , habilidade e imprevisibilidade .

Lado criativo da programação

Sou da opinião de que o desenvolvimento de software é, por definição, uma atividade criativa . Obviamente, existem desenvolvedores que realizam as mesmas tarefas triviais, mas eles só têm trabalho até que alguém descubra como automatizar seu trabalho. Você não os invejará, e o tópico deste artigo é completamente diferente.

Para mim, há algo de especial no ato de criar algo novo e na busca de soluções originais em resposta aos desafios; é por isso que me sinto chamado ao desenvolvimento de software e não acho que sou o único. Na verdade, acho que a criatividade é a principal razão pela qual os desenvolvedores gostam de seu trabalho. Minha experiência sugere que, sempre que trabalhei em condições em que um "conjunto de práticas" estritas e imutáveis ​​(se fosse uma pilha tecnológica, processos, regulação etc.) era observado, havia menos espaço para a criatividade Eu era - menos me fascinava por esse trabalho. "No final, se eles já decidiram tudo por si mesmos, por que precisam de mim?" Eu pensei. Por outro lado, fiquei muito mais satisfeito, inspirado por esse trabalho (no qual eu também era o mais produtivo), onde havia relativamente poucas diretrizes de cima, havia espaço para a criatividade e confiava em mim mesmo para tomar decisões técnicas.

É importante observar que liberdade criativa adicional leva ao fato de que, no caminho para chegar a uma solução, haverá inevitavelmente mais tentativas e erros - e isso é normal. Parece para alguns que você pode simplesmente conhecer a solução perfeita a priori (antecipadamente) sem escrever uma única linha de código. Pelo contrário, insisto que, no processo criativo, o caminho para descobrir uma solução para uma tarefa (isso não se aplica apenas ao software) exige ajustes : é impossível saber tudo com antecedência; pelo contrário, você aprende na prática, gradualmente escolhendo novas opções e aderindo àquelas que funcionam, aprimorando sua decisão (e, possivelmente, entregando-a gradualmente aos clientes se você trabalha de acordo com uma metodologia "flexível") até estar satisfeito com ela.



Basta pensar em quantas vezes foram necessárias para projetar meticulosamente um componente no papel - só então, para refazer completamente o design, valeu a pena iniciar a implementação. Sempre haverá incógnitas desconhecidas nesse negócio , e você pode identificá-las e lidar com elas apenas a posteriori (de fato), programando sua decisão e não gastando muito tempo teorizando e não fingindo que podemos possuir informações perfeitas com antecedência. Essa improvisação não se encaixa bem nas datas estimadas.

Além disso, como no caso de outras atividades criativas, é útil praticar a procrastinação estratégica ao programar - esse termo foi proposto pela primeira vez por Adam Grant, que afirma que muitas vezes falha em criar sob demanda, mas, pelo contrário, a criatividade vem como uma "notificação por push " de um processo em execução em segundo plano em sua cabeça:

“Os funcionários que procrastinam regularmente costumam dedicar mais tempo a pensamentos divergentes, e os curadores costumam classificá-los como mais criativos que os colegas. A procrastinação nem sempre alimenta a criatividade: se um funcionário não tem motivação confiante para resolver um grande problema, então, devido ao deslizamento, simplesmente fica para trás. No entanto, se uma pessoa é suficientemente apaixonada pelo negócio e apresenta novas idéias, adiando a tarefa, ela chega a soluções mais criativas ".
Grant, Adam. “Originais: como os não-conformistas movem o mundo”

Novamente, isso não agradará os defensores do planejamento central que buscam prever e medir a cada minuto em projetos de desenvolvimento de software.


Via Láctea , Marte e meteoro

Habilidade de programação

Os melhores desenvolvedores que conheço são artesãos qualificados. O domínio é um recurso característico de um bom software: você cria algo que funciona e da melhor maneira possível - é relativamente fácil criar algo funcionando, mas é muito difícil fazer algo que não só funcione, mas também passe pelo teste do tempo.

Como você é um mestre, a qualidade do seu trabalho fala de você . Para você, a qualidade é mais importante que a quantidade, porque você não deseja ser reconhecido como o autor do govnokod, mesmo que possa satisfazer o gerente de produto dando ao seu programa um brilho externo e preenchendo-o com um monte de surpresas vis - chamo essa abordagem de Desenvolvimento da surpresa . Você sabe que dedicar tempo suficiente para fazer negócios e escrever um bom programa é adequado; portanto, resista à pressão do “faça mais rápido” porque você sabe que quanto mais muletas você definir agora, menor será o código e mais problemas haverá com ele negócios.


Olhos sangram

O artesanato se preocupa com o cuidado : nos preocupamos em fazer um excelente trabalho, naqueles que terão que manter nosso código depois de nós, em nossos clientes que devem ser fáceis de usar em nosso programa, em colegas de equipe etc. Você faz isso porque não é um idiota e porque sabe que é isso que deve fazer se se preocupa com o sucesso do projeto.

Em resumo, um bom engenheiro tem uma tarefa difícil: cuidar da qualidade - que será sentida a longo prazo - em um mundo onde tudo é decidido a ser feito rapidamente.

Na prática, isso é expresso em coisas semelhantes:

• Encontre a combinação certa entre encapsulamento, extensibilidade, escalabilidade etc. - novamente, será necessária uma abordagem iterativa por tentativa e erro, porque ninguém consegue criar a melhor solução na primeira tentativa.
  
• Reserve um tempo para refatorar se você encontrar um pedaço de código vergonhosamente ruim.
  
• Faça bons testes completos - talvez até faça TDD
  
• Programe em conjunto com um colega
  

Escusado será dizer que é impossível planejar tudo isso com antecedência; portanto, uma abordagem semelhante ainda não o ajudará a cumprir os prazos.

Suas previsões estão erradas

“Mesmo que existam requisitos claros - e parece que isso nunca acontece, é quase impossível calcular quanto tempo leva para um trabalho específico, pois nunca resolvemos esse problema antes. Se você decidir, basta fornecer o resultado ".
- Ron Jeffries, Movimento NoEstimates

Projetos de software são Sistemas Complexos : são criados por pessoas e, portanto, carregam a marca de relacionamentos interpessoais, motivação, problemas de comunicação e psicologia humana em geral - tudo isso é muito difícil de modelar e quantificar na tabela, se você estiver interessado na minha opinião. Portanto, os projetos de software são muito difíceis de modelar (e, portanto, prever). Isso é melhor explicado por Nassim Taleb em seu livro " Anti-Fragility" :

“Sistemas complexos são altamente interdependentes (difíceis de reconhecer) e reações não lineares. “Não linear” significa que, quando você duplica, por exemplo, a dose do medicamento ou o número de trabalhadores na fábrica, o retorno não será duas vezes maior, mas será muito mais ou menos. Isso não quer dizer que dois fins de semana na Filadélfia são duas vezes mais agradáveis ​​que um - posso dizer isso por experiência própria ... ”
- Nassim Nicholas Taleb, Anti-Fragilidade

Pior, dado que o tempo não pode ser um valor negativo, é provável que quaisquer “surpresas” não planejadas atrasem a conclusão do projeto, em vez de aproximá-lo, porque há uma assimetria de resultados:

“O tempo não é um valor negativo, o que significa que um projeto de três meses não pode ser implementado em um período zero ou negativo. Portanto, no eixo do tempo, que se move da esquerda para a direita, os erros se acumulam à direita e não à esquerda. Se a incerteza for linear, veremos que alguns projetos são concluídos significativamente antes do previsto (pois, às vezes, chegamos a um local muito mais cedo e, outras vezes, muito mais tarde). Mas, na realidade, não é assim. "
- Nassim Nicholas Taleb, Anti-Fragilidade

Isso é uma má notícia, porque a incerteza é garantida e até pequenos erros na avaliação de tarefas individuais se acumularão exponencialmente em uma escala de todo o projeto. Além disso, aqui consideramos o melhor caso quando os prazos são definidos pelos próprios desenvolvedores após uma avaliação cuidadosa do cronograma. No entanto, a realidade é muito mais absurda: na maioria dos casos, o “negócio” estabelece os prazos como ele deseja e somente então os engenheiros que planejam como satisfazer todos os requisitos desse período arbitrariamente especificado assumem o assunto; o caso é tão notório quanto começar uma casa do telhado, não da fundação, ou colocar uma carroça na frente de um cavalo.


Boa pergunta

Aqui estão alguns exemplos que demonstram a não linearidade do desenvolvimento de software e os ciclos de feedback resultantes:

• Você sugeriu uma vez que a API à qual você deseja se vincular aceita accountId , mas na verdade ela aceita apenas memberId . Adicione ao período estimado de 4 dias que você precisará refatorar o código da API - após o qual, por sua vez, você precisará de uma revisão separada, para a qual adicionaremos mais 2 dias.
  
• A tarefa que esperávamos resolver em dois dias dura uma semana, porque no processo de revisão um dos colegas o força (e faz o certo) a refatorar e otimizar o nojento pedaço de código que há muito tempo espera nos bastidores.
  
• Lembre-se da tarefa única quando você precisou implementar apenas uma nova oportunidade. Porém, para isso, é necessário atualizar a dependência, que levou quatro dias, e essa operação provocou uma reação em cadeia com a atualização de outras dependências e várias dependências durante a montagem.
  

Estamos ferrados?

Simplesmente por inércia, continuamos a jogar esse jogo com avaliações e planejamento, apenas para garantir a nós mesmos: estamos supostamente no controle da situação. Mas, na realidade, não controlamos nada; A experiência mostra que os projetos de software são imprevisíveis. Então, acho melhor focar nos negócios do que planejar - #NoEstimates , quem está comigo? No entanto, é claro, isso não funcionará em muitas organizações: "Você não pode simplesmente aceitar e deixar que os engenheiros mantenham a bola para que ninguém os controle. Deve haver responsabilidade! Eu entendi.


Você não diz isso?

O que fazer então? Eu acho que isso se resume a diminuir a lacuna entre o mundo das tabelas e o mundo do IDE, de modo a fornecer aos engenheiros o máximo de criatividade, flexibilidade e liberdade para mostrar domínio, no entanto, ao mesmo tempo, adere responsavelmente à promessa e atenda às expectativas dos participantes do projeto. Gerente Técnico (Gerente de Engenharia) - o melhor especialista na construção de pontes, que também pode absorver a diferença entre os dois mundos. Este trabalho não é fácil, mas necessário. Aqui está como Aaron Longwell fala sobre ela em seu artigo:

“Como os gerentes técnicos vivem na fronteira entre negócios e técnicos, são eles que precisam resolver as contradições entre expectativas e realidade. Eles são como uma suspensão de alavanca, que é puxada em direções diferentes: ela pode encaixar nos dois lados. Se o negócio vencer, os desenvolvedores serão levados à morte. Se as considerações de engenharia superam as dos negócios, adeus ao orçamento e aos prazos. De qualquer forma, uma falha. Um gerente de projeto de software bem-sucedido encontra maneiras de agir com flexibilidade; ceder, não quebrar, e gradualmente resolver o atrito. A abordagem de liderança como serviço pode ajudá-lo a se tornar mais flexível. ”
- Aaron Longwell, por que o desenvolvimento de software requer líderes de servidores

Também é muito importante estabelecer uma forte relação de confiança entre Produção e Engenheiros. Se houver confiança, você poderá negociar honestamente e conscientemente os prazos. Se você já provou que sua equipe cria um bom software, deve ter uma reputação bastante boa e as partes interessadas devem confiar em você, entendendo que, se você estiver fora do prazo, por boas razões e pelo bem comum.

Outro "truque" que eu pessoalmente usei como gerente não foi o de nomear datas específicas, pois elas inevitavelmente se transformam em prazos difíceis. É melhor dar datas confusas, por exemplo, "três a cinco semanas". Nesse caso, ao se aproximar de um prazo tão instável, você adiciona: "em abril ou maio", que é facilmente interpretado como "entre 15 de abril e 3 de maio" no início de abril, por volta de 10 de abril pode se transformar em "até 20 de abril" Abril "etc. Nesse caso, você não se diverte, se comunica com os colegas e a equipe oferece a flexibilidade dos termos que serão necessários para resolver os inevitáveis ​​problemas imprevistos que surgem.

Por fim, lembre-se de que é o desenvolvedor que deve ser responsável pela qualidade técnica do produto emitido, e não outras partes interessadas. É bastante natural que haja atritos entre as organizações, que, à primeira vista, são guiadas por diferentes incentivos. Nesse caso, é mais importante observar que todos vocês (presumivelmente) estão unidos por um objetivo comum: fornecer ao cliente software de alta qualidade no menor tempo possível. Aparentemente, apenas bons desenvolvedores são capazes de pensar com esse espírito e entender que é importante evitar a abordagem enganosa “um, dois - e pronto!”, Que, a longo prazo, é a mais lenta.

Concluindo, direi que esse é um problema solucionável, embora complexo (e comum). Eu diria que, se, na sua opinião, seu gerente ou sua organização não estiver inclinado a escrever um bom software, será necessário falar sobre isso e tentar alterá-lo; se isso falhar, encontre outro emprego.

Sobre o tradutor

O artigo foi traduzido por Alconost.

A Alconost localiza jogos , aplicativos e sites em 70 idiomas. Tradutores em idioma nativo, teste linguístico, plataforma em nuvem com API, localização contínua, gerentes de projeto 24/7, qualquer formato de recursos de string.

Também criamos vídeos de publicidade e treinamento - para sites que vendem, imagem, publicidade, treinamento, teasers, exploradores, trailers do Google Play e da App Store.

Mais detalhes