Falhar um prazo não é apenas um inconveniente. Para um cliente pode significar um lançamento adiado, uma oportunidade perdida, ou uma conversa que tem de ter com o seu próprio cliente a explicar porque é que algo não está pronto. Levo isso a sério, e é por isso que cumprir prazos é algo que trato como inegociável.
Aqui está como o consigo na prática.
Os prazos começam com uma estimativa honesta
A razão mais comum pela qual os developers falham prazos é que concordaram com um que não conseguiam cumprir de forma realista. Ou subestimaram o trabalho, ou sobrestimaram a sua disponibilidade, ou disseram que sim porque sentiram que tinham de o fazer.
Quando aceito um projeto, dedico tempo a fazer o levantamento correto antes de dar um prazo. Analiso os requisitos, penso nos casos mais complexos, e contemplo as trocas de feedback que acontecem sempre durante um projeto. A estimativa que dou é uma em que realmente acredito, não uma pensada para ganhar o trabalho.
Se algo vai demorar duas semanas, digo duas semanas. Não uma semana com a esperança de que corra bem.
Dividir o trabalho em partes pequenas
Um prazo três semanas à frente parece gerível até ao momento em que deixa de o parecer. A forma como evito isso é dividindo cada projeto em partes entregáveis pequenas com os seus próprios prazos internos. Cada parte tem uma definição clara de concluído, e acompanho o progresso diariamente.
Isto significa que sei cedo quando algo está a demorar mais do que o esperado, o que me dá tempo para ajustar antes de se tornar um problema para o cliente.
Comunicar antes de se tornar um problema
As coisas acontecem. Os requisitos mudam. Um problema técnico revela-se mais complexo do que o esperado. Isso é normal no trabalho de desenvolvimento.
O que não é aceitável é ficar em silêncio. Se algo vai afetar o prazo, digo ao cliente assim que sei, não no dia anterior ao prazo. A comunicação antecipada dá a todos tempo para se adaptarem. As surpresas de última hora não dão.
Proteger tempo de trabalho focado
O bom trabalho de desenvolvimento requer concentração. Mudar constantemente de contexto, notificações constantes e tempo fragmentado são o inimigo tanto da qualidade como da velocidade. Estruturo os meus dias com blocos dedicados de trabalho focado onde não estou a verificar mensagens nem a saltar entre tarefas.
Não se trata de estar indisponível. Trata-se de garantir que quando me sento a trabalhar num projeto, estou realmente a fazê-lo avançar e não apenas a sentir-me ocupado.
O resultado
Os clientes que trabalham comigo sabem o que esperar e quando esperar. Essa previsibilidade vale muito, especialmente para agências que gerem múltiplos projetos e relações com clientes ao mesmo tempo.
Se já trabalhaste com developers que tratam os prazos como sugestões, entendo a frustração. Não é assim que trabalho. Entra em contacto e falemos sobre o teu próximo projeto.