Todo mundo sabe o que é um prazo, mas nem todo mundo sabe como defini-lo corretamente. Para falar sobre quebrar o prazo do projeto, você pode pegar muitas metáforas bonitas. Yubitsume é um desses. Este é um corte ritual da falange do dedo no Japão. Em particular, eles recorrem ao yubitsume para pedir desculpas ao líder ou proprietário por um erro. Se você assistiu a filmes sobre a yakuza, entendeu do que se tratava.
O ritual passou da comunidade de jogos de Bakuto e foi visto como um substituto adequado para o pagamento da dívida. O devedor permitiu que a pequena falange fosse consumida, e isso complicou sua vida futura: ele não conseguia mais segurar sua espada com segurança e, na batalha, dependia mais de seus companheiros, inclusive do dono.
Não importa em que hora e local você mora e o que você faz - o relacionamento com a equipe deve ser forte e os prazos devem ser respeitados. Os gerentes do
Live Typing Studio, embora não cortem os dedos, ainda são responsáveis pela palavra dada ao cliente. A experiência me permitiu formular seis erros, cometendo quais, você definitivamente corre o risco de perder o emprego no prazo e o que fazer para cumprir os prazos. Tendo deixado de cometer esses erros, você notará como a qualidade de seus projetos aumentará, quanto tempo será liberado para descanso e como as relações entre os membros da equipe e com o cliente melhorarão.
Você não sabe com quem trabalha
Cada membro da equipe de desenvolvimento é como um personagem em um role-playing game: alguém tem uma abundância de capacidade de se envolver no projeto, mas falta perseverança e concentração, e alguém aprecia o tempo que a tarefa levará. A partir deste último, são obtidos timlids, que geralmente são bons em tudo.
Com tudo isso, tão diferente, as pessoas precisam trabalhar em um estilo diferente. Alguns precisam de incentivo, seja controle rígido ou palavras encorajadoras; outros esperam que você lhes conte sobre o histórico do cliente, seus ideais e perspectivas de vida, o que ele espera da equipe e como ele depende disso; outros ainda trabalham. Se você não fizer concessões ao caráter de um membro de sua equipe, ele será deixado por conta própria e pelos piores hábitos, e o prazo provavelmente será interrompido.
Não menos importante é a experiência de um especialista. Distribua as tarefas de acordo com suas habilidades e coeficiente de produtividade. Caso contrário, junho ou meio falharão em uma tarefa que eles não podem executar inicialmente.
Você não entendeu os objetivos do projeto
O trabalho em um site ou aplicativo começa com
a fase de design . Essa é uma etapa séria: resta saber quem usará o produto, quais objetivos ele pretende alcançar e como trará dinheiro ao seu proprietário. Os resultados desse estágio são registrados na tarefa funcional, e a
tarefa funcional serve como base para a formulação de tarefas para designers e desenvolvedores.
A funcionalidade do aplicativo deve ter um objetivo claro. Se o gerente não entendeu, isso significa que o projeto foi mal executado e a tarefa não será definida corretamente para o contratado. O resultado é imprevisível, porque o desenvolvedor pode começar a pensar no papel da funcionalidade, aumentar e, eventualmente, gastar muito tempo escrevendo e reescrevendo código.
Para evitar isso, realizamos uma revisão do projeto: toda a equipe examina com cuidado e iterativamente o protótipo ou o design resultante e encontra o maior número possível de espaços, erros e telas ausentes. A execução de alta qualidade de uma revisão de design afeta muito o tempo.
Quanto mais precisa e completa a documentação, menos desenvolvedores terão mal-entendidos e bugs durante o desenvolvimento, o que garante a conformidade com os prazos.
Os membros da sua equipe classificaram incorretamente as tarefas
Uma classificação incorreta é a causa da maioria dos prazos queimados. Cada caso de uma avaliação incorreta deve ser discutido em retrospecto, encontre os motivos e desenvolva táticas para abordá-los no futuro.
Alguns juniores e intermediários tendem a superestimar seus pontos fortes. Com a experiência, um bom gerente começa a entender isso e faz ajustes: por exemplo, depois de ouvir uma estimativa de 10 horas, ele multiplica por 2 e obtém um resultado que mais tarde se torna mais verdadeiro.
Um desenvolvedor sênior não é mais velho que o resto, mas sabe que pode levar mais tempo para concluir uma tarefa do que o esperado e admite isso com ousadia a si mesmo e ao gerente. Um desenvolvedor sênior está ciente dos riscos, e você deve. O seguinte erro é dedicado a isso.
Você e seu cliente não estão cientes dos riscos
Riscos são tudo o que você não planejou e que atrasará o trabalho nas tarefas. Eles são externos e internos. A desconexão da Internet, um furacão ou uma inundação, uma alteração nos requisitos de um produto - essas são razões externas que os artistas não podem influenciar de forma alguma. Uma longa busca por uma solução para um problema, um colapso nervoso no desenvolvedor - essas são causas internas e podem ser controladas.
Você pode reduzir a probabilidade de riscos devido à decomposição ou dividir uma tarefa grande em pequenas. 40 horas nem sempre são quatro tarefas de 10 horas cada; durante a decomposição, pode acontecer que, para a integração de um sistema de pagamento dolorosamente familiar em um projeto desconhecido, as soluções prontas para caixas não sejam suficientes e você tenha que escrever sua própria. A decomposição ajudará a avaliar corretamente os prazos e simplificar o controle sobre sua observância.
Algumas das causas externas também podem ser influenciadas, especialmente quando estão no cliente. Quanto mais cedo o cliente der acesso a textos, logotipo, documentação, API (caso o lado do servidor execute o comando no lado do cliente), melhor. E será ainda melhor se você coletar os riscos associados ao cliente e incluí-los no contrato. Este será um ótimo lembrete para o cliente de que ele também faz parte do projeto.
Se o cliente estiver em boa forma, o projeto será fácil. Informe-o sobre o status das tarefas, fale sobre tudo o que pode dar errado e que levará a atrasos, fale sobre o que você está tentando resolver o problema. Em primeiro lugar, você pode se surpreender com a forma como o aproxima e o encoraja a se envolver no diálogo mais construtivo possível. Em segundo lugar, uma possível saída para o prazo e sua reatribuição não será mais uma surpresa para o cliente. Uma boa comunicação é a
chave do sucesso .
Você não tem plano B
Um bom gerente, como um jogador de xadrez, calcula as opções para os eventos com antecedência. Mas se um jogador de xadrez olha para o futuro por apenas alguns minutos, então o gerente - por alguns meses antes do prazo, com certeza. Durante esse período, todos os riscos devem surgir.
Nesse caso, para várias tarefas particularmente complexas, é necessário escolher uma versão mais orçamentária de sua solução, o que não afetará a experiência do usuário, e o resultado geral permanecerá adequado. Isso é chamado de flex. Opção
flexível -
abandone o design personalizado . Mas ainda use as diretrizes da Apple e do Google. Só não esqueça de explicar ao cliente que agora esta é a melhor opção para cumprir o prazo.
Você não pode agregar valor ao cliente aos olhos dele.
Ainda assim, começar com um pedido de desculpas é normal, é uma cortesia básica. Outra coisa é que desculpas precisam ser apoiadas por algo aplicado. Será ótimo se você:
- analisar o problema na reunião com a equipe, tirar conclusões e prometer ao cliente que isso não acontecerá novamente;
- justifique que o prazo fez sentido para o projeto no futuro. Por essas 16 horas extras, você provavelmente testou escrupulosamente o aplicativo e corrigiu os erros que arruinariam irreparavelmente o produto e a imagem do cliente se ele caísse nas mãos do usuário.
Se você não quiser se sentir culpado e cometer um mau funcionamento no ritmo medido da sua vida, não cometa nenhum desses erros. Listei os mais básicos e achamos que as especificidades do seu trabalho levam a outros erros. Vai ser ótimo se você falar sobre eles nos comentários.