Alternativas às metodologias de controle de tempo [fechado]

Pergunta primeiro: Quais são algumas alternativas possíveis para o controle de tempo dos funcionários de uma empresa de desenvolvimento de web / software e por que elas são melhores opções

Explicação:

Eu trabalho em uma empresa onde trabalhamos assim. Todos recebem salário. Temos 3 tipos de trabalho, Contrato, Adhoc e Interno (Não faturável). Adhoc são apenas pequenas alterações que levam algumas horas e apenas faturamos o cliente no final do mês. Os contratos são assinados e temos esse grande e longo processo, o de sempre.

Nós descobrimos quanto cobrar, obtendo uma estimativa do tempo envolvido (do design e dos desenvolvedores), multiplicando-o pela nossa taxa horária e é isso. Digamos que estimamos 50 horas para um site. Temos um software de rastreamento de tempo e precisamos registrar o tempo em 15 que gastamos nele (das 7:00 às 7:15, por exemplo), o nome do projeto e fazer alguns comentários.

Agora, se passarmos as 50 horas, estamos perdendo dinheiro e somos ineficientes.

Agora que expliquei como o sistema funciona, minha pergunta é de que outra forma isso pode ser feito se existir um método melhor (do qual tenho certeza). Ninguém aqui gosta do sistema atual, simplesmente não conseguimos encontrar uma alternativa. Eu estaria mais do que disposto a trabalhar após horas mais longas em um projeto para concluir o trabalho a tempo, mas estou muito inclinado a fazê-lo com o sistema atual. Eu adoraria poder resumir (ou vincular) a esta postagem para que meu gerente mostre a eles por que devemos usar o sistema abc em vez deste sistema.

As estimativas de software são sempre difíceis. O software é um negócio criativo, e a criatividade aumenta e diminui. Estou apenas começando a me recuperar após uma semana de exaustão severa - na outra noite, levei horas para realizar uma tarefa que deveria ter durado 15 a 30 minutos ...

Considere também que cada desenvolvedor possui diferentes habilidades de estimativa. Desenvolvedores mais disciplinados ou seniores tendem a ser mais precisos e desenvolvedores mais juniores ou indisciplinados são menos precisos. Além disso, sua precisão muda com o tempo (nem sempre para melhor).

Na minha experiência em consultoria pessoal, tento mesclar uma estimativa realista com um teto. Basicamente, dizendo "Espero que esse recurso leve de 7 a 10 horas, mas pode chegar a 18 - no máximo, mesmo que demore 40 horas, você será cobrado por 18". Normalmente, esse tipo de abordagem é novo para os clientes e alguns rejeitam-na com "me dê um preço firme" - esses clientes recebem a estimativa do teto (ou eu recuso educadamente seus negócios). Para os clientes que aceitam essa abordagem, eles entendem que honestamente controlarei o tempo, e a fatura final real refletirá meu tempo gasto (mas não excederá meu limite máximo). Essencialmente, essa é uma abordagem enxuta, com uma garantia adicionada; e o cliente está ciente de que qualquer alteração nos requisitos introduz alterações nas estimativas.

No geral, essa abordagem funcionou bem para clientes dispostos a aceitá-la. Meu objetivo pessoal é ganhar a confiança deles e repetir os negócios, por isso é do meu interesse ser sincero e tentar entrar bem abaixo do limite - e é do interesse deles ajudar a me manter sob minhas estimativas (evitando incertezas, alterações tardias, etc. - reviso as estimativas se as alterações forem além de pequenas).

Se você não tiver, sugiro ler The Mythical Man Month

Dê uma olhada no agendamento baseado em evidências . Pode realmente ajudar você a ver a precisão das suas estimativas.

Nos últimos anos, em Fog Creek, desenvolvemos um sistema tão fácil que até nossos desenvolvedores mais ranzinzas estão dispostos a segui-lo. E, até onde sabemos, produz agendas extremamente confiáveis. Chama-se Agendamento Baseado em Evidências, ou EBS. Você reúne evidências , principalmente a partir de dados históricos do quadro de horários, que realimentam suas agendas. O que você recebe não é apenas uma data de envio: você obtém uma curva de distribuição de confiança, mostrando a probabilidade de envio em qualquer data. Se parece com isso:

Quanto mais íngreme a curva, mais confiante você fica que a data de envio é real.

Aqui está como você faz isso ...

O problema com esse método é que ele não leva em consideração o risco inerente nas estimativas. Uma prática recomendada para qualquer estimativa é expressá-la como um intervalo de vezes, por exemplo, 50 horas ± 15 horas ou algo semelhante. É difícil encontrar o termo do erro, mas ninguém acredita que levará exatamente 50 horas de qualquer maneira.

Existem outras abordagens além do modelo de preço fixo; você pode usar uma taxa mais baixa e faturar horas seguidas, mas atualmente, seus clientes provavelmente desejam transferir o risco para você. Tudo bem, mas significa que você precisa cobrar um prêmio de risco razoável com base no intervalo de tempo estimado.

Fazemos estimativas com um fator de "incerteza", em vez de tentar estimar com fatores "+/-". Os programadores podem facilmente dizer quanto tempo levará algo "assumindo que nada dê errado". O que eles não podem dizer com facilidade é quanto tempo levará se algo der errado. Então, adicionamos um fator de incerteza - "L" significa "adicione 25%" - "M" significa "adicione 50%" e "H" significa "adicione 100% - pode dobrar". O tempo real tende a ficar entre o tempo estimado e a estimativa mais o tempo da incerteza.

Quanto ao controle do seu tempo, o método mais preciso é escrever um programa que abre uma caixa de diálogo a cada minuto e pergunta "o que você está fazendo?", Com uma lista suspensa de possíveis tarefas. A única entrada que você realmente precisa nessa caixa de listagem suspensa é "tempo de rastreamento", porque se você for interrompido a cada minuto, nunca fará mais nada. O mesmo princípio também se aplica a intervalos de 15 minutos, mas não tão ruins assim.

O que fazemos é executar um pequeno programa que nos permite adicionar tarefas a uma lista e selecionar em qual deles estamos trabalhando, aumentando o tempo. Se esquecermos de mover o seletor para a tarefa correta, os totais serão editáveis. Qualquer coisa que não esteja em uma das linhas vai para "misc". Não é totalmente preciso, mas a precisão total é menos importante do que obter tempo de fluxo.