Alternativas a las metodologías de seguimiento del tiempo [cerrado]

12

Pregunta primero: ¿Cuáles son algunas alternativas factibles para el seguimiento del tiempo de los empleados en una empresa de desarrollo web / software y por qué son mejores opciones?

Explicación:

Trabajo en una empresa donde trabajamos así. A todos se les paga el salario. Tenemos 3 tipos de trabajo, Contract, Adhoc e Internal (No facturable). Adhoc son solo pequeños cambios que demoran algunas horas y simplemente facturamos al cliente a fin de mes. Los contratos están firmados y tenemos este gran proceso largo, el habitual.

Calculamos cuánto cobrar obteniendo una estimación del tiempo involucrado (del diseño y los desarrolladores), multiplicándolo por nuestra tarifa por hora y eso es todo. Digamos que estimamos 50 horas para un sitio web. Tenemos software de seguimiento de tiempo y tenemos que registrar el tiempo en 15 que pasamos en él (7:00 a 7:15 por ejemplo), el nombre del proyecto y darle algunos comentarios.

Ahora, si pasamos las 50 horas, ambos estamos perdiendo dinero y somos ineficientes.

Ahora que he explicado cómo funciona el sistema, mi pregunta es cómo se puede hacer si existe un método mejor (que estoy seguro de que uno debe). A nadie aquí le gusta el sistema actual, simplemente no podemos encontrar una alternativa. Estaría más que dispuesto a trabajar después de horas más horas en un proyecto para hacerlo a tiempo, pero estoy muy inclinado a hacerlo con el sistema actual. Me encantaría poder resumir (o vincular) a esta publicación para que mi gerente les muestre por qué deberíamos usar el sistema abc en lugar de este sistema.

Brandon Wamboldt
fuente

Respuestas:

8

Las estimaciones de software siempre son difíciles. El software es un negocio creativo, y la creatividad aumenta y disminuye. Estoy empezando a recuperarme después de una semana de agotamiento severo; la otra noche me llevó horas hacer una tarea que debería haber sido de 15-30 minutos ...

También considere que cada desarrollador tiene diferentes habilidades de estimación. Los desarrolladores más disciplinados o senior tenderán a ser más precisos y los desarrolladores más junior o indisciplinados son menos precisos. Además, su precisión cambia con el tiempo (no siempre para mejor).

En mi experiencia personal de consultoría trato de combinar una estimación realista con un techo. Básicamente decir "Espero que esta función tarde entre 7 y 10 horas, pero podría llegar a 18; a lo sumo, incluso si lleva 40 horas, se le facturarán 18". Por lo general, este tipo de enfoque es nuevo para los clientes y algunos lo rechazan rotundamente con "dame un precio firme": esos clientes obtienen la estimación máxima (o rechazo cortésmente su negocio). Para los clientes que aceptan este enfoque, entienden que honestamente rastrearé el tiempo, y su factura final real reflejará mi tiempo invertido (pero no excederá mi límite máximo). Esencialmente, este es un enfoque lean con una garantía agregada; y el cliente es consciente de que cualquier cambio en los requisitos introduce cambios en las estimaciones.

En general, ese enfoque ha funcionado bien para los clientes dispuestos a aceptarlo. Mi objetivo personal es ganarme su confianza y repetir los negocios, por lo que me interesa ser honesto y tratar de entrar por debajo del límite, y es de su interés ser útil para mantenerme por debajo de mis estimaciones (evitando la incertidumbre, cambios tardíos, etc. - Reviso las estimaciones si los cambios son más que menores).

Si no lo ha hecho, sugeriría leer el Mes del hombre mítico

STW
fuente
7

Eche un vistazo a la programación basada en evidencia . Realmente puede ayudarlo a ver cuán precisas son sus estimaciones.

Durante el último año más o menos en Fog Creek hemos estado desarrollando un sistema que es tan fácil que incluso nuestros desarrolladores más gruñones están dispuestos a aceptarlo. Y hasta donde podemos decir, produce horarios extremadamente confiables. Se llama Programación Basada en Evidencia, o EBS. Reúne evidencia , principalmente de datos históricos de hojas de horas, que retroalimenta en sus horarios. Lo que obtienes no es solo una fecha de envío: obtienes una curva de distribución de confianza, que muestra la probabilidad de que enviarás en una fecha determinada. Se parece a esto:

http://www.joelonsoftware.com/items/2007/10/26ebs1.png

Cuanto más empinada sea la curva, más seguro estará de que la fecha de envío es real.

Así es como lo haces ...

Karl Bielefeldt
fuente
2
Un enfoque muy bueno e integral. La parte difícil de poner en marcha estos enfoques es hacer que los desarrolladores comprendan que está bien que sus estimaciones sean erróneas, por lo que deben comprender qué se hace con sus estimaciones y hacer que confíen en que no se tienen en cuenta las inexactitudes honestas ellos es un primer paso crítico
STW
0

El problema con este método es que no tiene en cuenta el riesgo inherente en las estimaciones. Una mejor práctica para cualquier estimación es expresarlo como un rango de tiempos, por ejemplo, 50 horas ± 15 horas, o algo similar. El término del error es difícil de encontrar, pero nadie cree que tomará exactamente 50 horas de todos modos.

Hay otros enfoques además del modelo de precio fijo; podría usar una tarifa más baja y facturar horas seguidas, pero en estos días, sus clientes probablemente querrán transferirle el riesgo. Eso está bien, pero significa que debe cobrar una prima de riesgo razonable según el rango de estimaciones de tiempo que se le ocurra.

James McLeod
fuente
0

Hacemos estimaciones con un factor de "incertidumbre", en lugar de intentar estimar con factores "+/-". Los programadores pueden decirte fácilmente cuánto tiempo tomará algo "suponiendo que nada salga mal". Lo que no pueden decirle fácilmente es cuánto tiempo llevará si algo sale mal. Por lo tanto, agregamos un factor de incertidumbre: "L" significa "agregar 25%" - "M" significa "agregar 50%" y "H" significa "agregar 100% - podría duplicarse". El tiempo real tiende a estar entre el tiempo estimado y el estimado más el tiempo de incertidumbre.

En cuanto al SEGUIMIENTO de su tiempo, el método más preciso es escribir un programa que muestre un cuadro de diálogo cada minuto y le pregunte "¿qué está haciendo?", Con un cuadro de lista desplegable de posibles tareas. La única entrada que realmente necesita en ese cuadro de lista desplegable es "tiempo de seguimiento", porque si se interrumpe cada minuto, en realidad nunca hará nada más. El mismo principio se aplica a intervalos de 15 minutos también, pero no es tan malo.

Lo que hacemos es ejecutar un pequeño programa que nos permite agregar tareas a una lista y seleccionar en qué estamos trabajando, lo que permite que sume el tiempo. Si olvidamos mover el selector a la tarea correcta, los totales son editables. Cualquier cosa que no esté en una de las filas va a "misc". No es totalmente preciso, pero la precisión total es menos importante que obtener el tiempo de flujo.

SESummers
fuente