Como fazer as pazes com prazos no desenvolvimento de software

DATA LIMITE…

Como desenvolvedor, este é um de seus maiores pesadelos ou devo dizer seu inimigo? Nomeie como você quiser.

Admite. Isso te assusta muito. Mesmo agora, enquanto você está lendo essas frases, você fica com os cabelos em pé.

Quer saber como eu sei disso?

Eu sei porque senti o mesmo. Mas agora o medo está no passado. Eu fiz as pazes com prazos. Eu os abracei.

Então, eu sugiro que você faça a mesma coisa. Abrace-os, faça as pazes com eles. Esta é a única maneira de derrotá-los.

Ok, mas como você pode fazer isso?

Existem alguns fatos que todos nós tendemos a ignorar quando se trata de definir um prazo. Meu objetivo aqui é mostrá-los para que você possa ver que é preciso tão pouco para enterrar o medo e começar a aproveitar a vida enquanto você está trabalhando em seu projeto sem se preocupar com datas.

Trabalhe em um ambiente calmo

Não se apresse. Não force nada.

A primeira coisa que você deve saber é que você não pode encontrar sua paz definindo datas irrealistas e forçando sua equipe a trabalhar com pressa. Existem empresas que lançam palavrões e mostram coisas irrealistas para motivar sua equipe a seguir em frente. Mas, embora haja alguns fatos óbvios para todos na equipe, como você pode esperar que eles acreditem no que você está dizendo se está longe da realidade?

Sem um prazo fixo - e o mais importante - crível, você não pode trabalhar com calma. Sim, manter a calma é a chave aqui. Quando você não confia na data, ou quando alguém lhe diz para fazer tudo dentro de um período limitado de tempo, ou alguém adiciona mais tarefas ao projeto sem lhe dar mais tempo, você começa a trabalhar como um louco. Isso não é mais trabalho. Isso é o inferno.

Quando você está sob estresse e pressão, não consegue ser produtivo. Quando você está calmo, você também está consciente, o que significa que pode tomar decisões melhores.

Nossas estimativas são péssimas

Os usuários do Windows se lembrarão dessa janela de diálogo. A estimativa na caixa de diálogo é exatamente igual às nossas estimativas, não é?

Vamos admitir. Nossas estimativas são péssimas. Achamos que podemos adivinhar quanto tempo algo levará. Temos a tendência de acreditar que tudo o que adivinhamos se tornará realidade.

No entanto, geralmente, quando fazemos suposições, ignoramos alguns fatores importantes que podem afetar nossas suposições. Por quê? Porque somos muito otimistas.

Para mim, o primeiro passo para fazer as pazes com os prazos e melhorar o seu estabelecimento é admitir que somos péssimos estimadores. Quando você abraçar este fato, estará consciente da próxima vez e isso o impedirá de subestimar os requisitos. E aqui está uma solução para você melhorar suas estimativas:

Divida as coisas grandes em coisas menores . Quanto menor for, mais fácil será estimar . Isso aumentará suas chances de obter estimativas mais precisas.

Bom o suficiente está bom

“O perfeito é inimigo do bom.” - Voltaire

As pessoas gostam de grandes desafios. Somos os melhores em encontrar uma solução complicada para um problema simples. Mas aqui está um fato:

Cada problema tem sua própria solução simples que você provavelmente ignora.

Não busque uma solução perfeita. Sua primeira versão não precisa ser perfeita. Construa um meio produto que possa funcionar. Se você esperar demais, desperdiçará seus recursos limitados e seu tempo precioso, ou perderá o prazo e, pior ainda, não fará nada porque está buscando a perfeição. A solução é:

Encontre a solução que lhe trará muito valor e requer pouco esforço. E não se esqueça, o bom pode ser transformado em ótimo mais tarde.

Não seja muito otimista. Seja realista.

Vejo gerentes muito otimistas, o que os leva a estabelecer prazos otimistas para motivar a equipe. Isto é tão errado. Não estou dizendo que você deve ser pessimista sobre o futuro. Pelo contrário, estou dizendo que você deve ser capaz de ver todas as possibilidades que podem criar um gargalo. Depois de vê-los, você pode considerá-los e ter uma estimativa mais precisa.

Existem diferentes equipes na empresa. Engenharia, desenvolvimento de negócios, marketing, etc. Quando a equipe de desenvolvimento de negócios o força a dar-lhes um prazo em um futuro muito próximo, você não deve ser afetado por eles. Eles querem que seu trabalho seja feito o mais rápido possível.

Lembre-se de que cada equipe pensa no seu lado.

Diferencie entre "você tem que fazer", "você poderia fazer" e "você quer fazer"

A compreensão é a chave aqui. Quais são os principais requisitos para o lançamento de seu produto? Normalmente, a equipe de produto tem dificuldade em diferenciá-los.

Quando você tem uma reunião, um dos membros da equipe dirá: "podemos implementá-lo, isso nos trará tanto valor" ou outro dirá "Devemos lançar isso". Eles estão olhando de sua própria perspectiva. Ok, podemos implementar isso e pode nos trazer algum valor, mas a pergunta importante é: “precisamos disso agora? Na primeira versão? ”

A resposta é NÃO na maioria dos casos.

As coisas que você deve fazer são as que devem ser focadas . Elimine as coisas que você pode e deseja fazer. Eles nem mesmo são negociáveis ​​na maioria dos casos.

Diga não por padrão

Há um fato importante que geralmente esquecemos quando dizemos “Sim” a algo. Estamos dizendo não às coisas que já precisamos concluir.

Quando você diz sim para algo novo, não está pensando no impacto que isso terá em suas tarefas existentes.

“Vamos adicionar mais tarefas ao projeto depois de definir o prazo. (Seu projeto deve ficar menor com o tempo, não maior.) ” NÃO .

“Focamos no que importa, ok. Mas e os detalhes? Vamos considerar que tipo de detalhes temos que podem causar problemas no futuro. ” NO . Ignore todos os detalhes da primeira versão. Não tente prever o futuro.

Encontrar mais tempo para as coisas não é o problema aqui. O problema é muita coisa para fazer. Diferencie entre “ must-haves ” e “ nice-to-haves ”.

A única maneira de fazer mais é ter menos o que fazer.

Nunca mude o prazo

Vejo equipes de desenvolvimento com um mau hábito que pode afetar muito o desenvolvimento de seus produtos: reprogramação de prazos.

Quando perdem o prazo, definem um novo. Se eles não podem encontrar este, eles marcam outro. Quando eles fazem isso repetidamente, torna-se um hábito. Então, esse mau hábito se transforma em sua cultura. Outras equipes da empresa perdem a confiança e questionam o trabalho dos desenvolvedores. Pior ainda, a própria equipe de desenvolvedores pode perder a confiança uns nos outros. Em si também.

Alterar o prazo é essencialmente uma admissão de fracasso . É fazer afirmações como: “Deixamos de planejar os requisitos, não dissemos não o suficiente, não nos concentramos no que é importante, pressionamos nossas equipes a fazer coisas irracionais em um tempo irracional”.

Esteja ciente de que sempre haverá alguns problemas

Ser muito otimista faz com que você ignore o fato de que pode haver alguns problemas. Estar ciente. Provavelmente algo vai dar errado. E isso fará com que você perca algum tempo consertando as coisas. Portanto, é melhor estar preparado para cenários ruins. Não estou dizendo que você deve ser pessimista e deve tentar prever o futuro e preparar a si e sua equipe para o desconhecido. Basta encontrar um equilíbrio entre otimismo e pessimismo. Seja realista.

Minha experiência me mostrou que, no desenvolvimento de software, algumas coisas sempre dão errado. Meu conselho para você é:

Adicione algum tempo ao seu prazo antes de defini-lo, considerando que algo pode dar errado.

Não adicione mais pessoas a um projeto

Muitas pessoas pensam que podem acelerar o processo se adicionarem mais pessoas ao projeto. No entanto, eles perdem um ponto muito importante. Vamos nos lembrar da lei de Brooks:

Adicionar recursos humanos a um projeto de software atrasado o torna mais tarde. - Freed Brooks

De acordo com Brooks na Wikipedia, existe uma pessoa incremental que, quando adicionada a um projeto, faz com que demore mais, não menos tempo. Então, por que funciona assim?

  • Leva algum tempo para que as pessoas adicionadas a um projeto se tornem produtivas. Você terá que educá-los primeiro. Você já tem recursos humanos limitados e terá que dedicar esses recursos para educar o novo membro. Além disso, como são novos, eles apresentarão novos bugs que afastam o projeto da conclusão.
  • As despesas gerais de comunicação aumentam conforme o número de pessoas aumenta.
  • Adicionar mais pessoas a uma tarefa altamente divisível, como limpar quartos em um hotel, diminui a duração geral da tarefa. No entanto, outras tarefas, incluindo muitas especialidades em projetos de software, são menos divisíveis. Outro grande exemplo disso por Brooks é: enquanto uma mulher leva nove meses para ter um bebê, “nove mulheres não podem fazer um bebê em um mês”.

Outra evidência de Richard Dalton para entender por que adicionar mais pessoas é errado:

“As equipes são imutáveis. Cada vez que alguém sai ou se junta, você tem uma nova equipe, não uma nova equipe. ” - Richard Dalton

Não procrastine

Deixe-me ajudá-lo a entender o que quero dizer. Na semana passada, tivemos uma reunião para definir o prazo para um novo recurso de nosso produto. Estávamos conversando sobre quais tarefas são nossa prioridade e como devemos implementá-las de forma eficaz.

Houve uma tarefa na qual perdemos muito nosso tempo. Havia três maneiras de implementar essa tarefa, mas de alguma forma estávamos presos. Não podíamos escolher porque os desenvolvedores estavam tentando prever o futuro. Eles estavam começando cada frase com “E se”.

Você não pode prever o que o futuro lhe trará. Não se prepare demais para o desconhecido.

Não estou falando sobre grandes decisões técnicas aqui. Claro, se você tiver que decidir sobre sua tecnologia central, deve dormir com ela para encontrar a solução certa. Mas não gaste seu tempo com coisas pequenas. Coisas incertas aumentam as reuniões e bloqueiam seu progresso porque seu processo de back-end está trabalhando continuamente nelas.

Não procrastine, decida-o e siga em frente.

Mude sua mentalidade de “Vamos pensar sobre isso” para “Vamos decidir agora”. As decisões irão acelerar o seu progresso. Quando algo for decidido, ficará claro para todos na equipe. Todos saberão exatamente o que fazer.

Comunique-se: veja onde está o gargalo?

Você planejou tudo. Você definiu o que focar e o que fazer. Você sabe exatamente quanto tempo levará (provavelmente você estará errado). Então, o prazo está fechado. É o suficiente?

NÃO.

Como mencionei acima, sempre existe a possibilidade de que algo possa dar errado. Enquanto os membros da sua equipe estão trabalhando em suas tarefas, algo pode bloqueá-los. Algo pode impedi-los de terminar suas tarefas a tempo. Você tem que ver onde está o gargalo e qual é.

A comunicação é a chave aqui. Você tem que manter as equipes sincronizadas. Às vezes, os membros da equipe podem entrar em uma caixa e pode ser muito difícil para eles ver o que está acontecendo com ela. É aqui que você deve entrar em cena. Depois de identificar o gargalo, remova-o para que os membros da equipe possam continuar de onde estavam.

Desejo-lhe boa sorte no cumprimento de todos os seus prazos :)

Obrigado pela leitura.

Publicado originalmente em //huseyinpolatyuruk.com.