Clasificación. Calcula y conoce

La previsibilidad de los plazos juega un papel importante en el desarrollo de proyectos de TI. Y debido a la alta complejidad de los procesos, la evaluación de tareas es un problema difícil, que no tiene un algoritmo explícito o un plan simple. Esto se ve agravado por el hecho de que en el proceso de comunicación sobre evaluaciones, negocios, gestión de proyectos y desarrollo pueden hablar diferentes idiomas, no entienden y no quieren entender los problemas y valores de los demás. El resultado es "darse de baja" en lo que se gastan esfuerzos, pero no producen el efecto necesario. 

El artículo será útil para los desarrolladores que quieran mejorar y hacer que el proceso de evaluación sea más cómodo para ellos. En él, compartiré el enfoque desarrollado, que nos permite aumentar la comprensión mutua con otras unidades, así como reducir el nivel de nuestros propios esfuerzos de evaluación. Analizaremos por qué necesitamos estimaciones, cómo evaluar tareas grandes y subtareas descompuestas. Y, lo más importante, qué hacer para entrar en estas evaluaciones.

La versión en video de la presentación está disponible aquí .

Bueno, ahora al grano.

¿Por qué dar calificaciones?


imagen

En la vida de cada desarrollador, ese momento desagradable llega cuando "ellos" vienen a nosotros y nos exigen: "¿cuándo estará listo?". "Ellos" son gerentes, productos, líderes de equipo, jefes ... La pregunta es, ¿por qué son "ellos"? ¿Qué harán "ellos" con esto? Si entendemos esto, podemos darles exactamente lo que necesitan y ahorrarles tiempo. Hay varias opciones, y aquí están las principales.

  • El gerente necesita evaluar el alcance del trabajo (entrega, lanzamiento, sprint): el calendario y su volumen total. En este caso, es importante entrar en la evaluación general, no importa en cada tarea específica (en algún lugar gastado más, en otro lugar menos, generalmente acordado). En el futuro, el trabajo de otros departamentos está planeado sobre esto, y los indicadores que administra el negocio dependen de ello. Y las empresas necesitan previsibilidad: para reducir riesgos y mejorar la capacidad de gestión.
  • . , . /. , , (, , ) . : , - . , . .
  • ( ). , . , : , . , /, , ( ), . (, , ), .

Bueno, ¿por qué este "ellos" se desmanteló? ¿Pero necesitamos esto? Imagine que su gerente se fue de vacaciones. Siempre. Y entonces te sientas, trabajas en silencio, un día, dos, a la semana. Nadie necesita calificaciones, la vida es buena. ¿Te evaluarás a ti mismo?

Darles o no es un asunto personal, pero aquí están los argumentos para ello.

  • La evaluación muestra cómo completar la tarea. El cerebro humano es algo costoso, y a una persona no le gusta pensar, es difícil. Por lo tanto, el deseo natural de pensar lo menos posible. ¿Pero como hacerlo? Puede dividir la actividad en una más estrecha. Compartimos planificación y ejecución: primero pensamos en el método (durante la evaluación), luego cambiamos a ejecución y pensamos en la ejecución (en el proceso). 
  • , «» . , — . , () ( ) , . , - . 
  • — . — . , , . . , . 2 . 2 , -  , . . , , — . , , — . ( /), . , , : « , !!». , , . ? . «», , . , , — - .
  • El efecto psicológico. Si la tarea es compleja, cambia durante el proceso de desarrollo o nuestro conocimiento al respecto cambia. Si no dimos una evaluación inicial, la tarea en el proceso se superpuso con nuevos detalles, y como resultado no llegamos allí, no recordamos por qué. Después de varias iteraciones, el efecto de un impostor golpea la cabeza. Y si hubieran dado una evaluación inicial, la razón se habría solucionado: pensaron que se necesitaban 5 loros, pero resultó 10. Por qué resultó ser la segunda pregunta, lo recuerdan bien. Y la razón no es siempre ("Los desarrolladores siempre no hacen nada" / "Estos productos no pueden pensar en nada para siempre, y luego aparece").

Entonces, decidimos: las evaluaciones son necesarias tanto para "nosotros" como para "ellos". Tiene sentido continuar leyendo más el artículo.

Propósito de la evaluación


Es inútil adivinar cuánto tiempo llevará la tarea. No puedes adivinar exactamente, y si puedes, no podrás decirlo de manera confiable hasta que lo hagas: así que lo adiviné o no lo adiviné. Y en esta etapa, nadie está interesado en la evaluación.

Por lo tanto, una evaluación no es un intento de adivinar cuánto tiempo llevará una tarea. La evaluación es un acuerdo entre el cliente y el contratista sobre el marco y (posiblemente) la forma en que se realiza la tarea .

Por lo general, una empresa adecuada no tiene una tarea que aplastar en un período de tiempo específico; una empresa necesita previsibilidad y control de riesgos. El tiempo se caracteriza no por la velocidad de trabajo del programador, sino por la cantidad de trabajo que dedica a la tarea. Y también puede saludar a un colega: si recibo una tarea con una evaluación inadecuada, esta es una ocasión para pensar, ¿son nuestros métodos exactamente iguales? ¿Quizás vio una manera más fácil de resolver? O tal vez por el contrario, ¿no notaste algo grande? En cualquier caso, un motivo para consultar el reloj.

Proceso de evaluacion


imagen

La base del proceso de evaluación es ver el valor de la tarea empresarial, así como los principales riesgos de la tarea y el volumen de la rutina. Y luego evaluarlos, encerrando el marco: no se sabe exactamente qué es, pero definitivamente es mayor que X y menor que Y. Y, por supuesto, lo evaluamos con la precisión con la que es necesario (porque la estimación exacta es costosa y el cerebro es perezoso). 

Composición de la tarea:

  • - ( ). , . smoke-test . , , , « ». , ! — . , : « - , ».
  • , - , . «» -. , , ( , , , , ), — . 
  • . - , , - . , ( ). : , , , (, . — - . : ( , , : , , , , ), , , , ( ) , , zero-tolerance , , , -, . , (//), (//). 
  • Todo lo demás .

El procedimiento para evaluar la epopeya.


El esquema nace del hecho de que cualquier tarea puede realizarse en cualquier cantidad de tiempo . La afirmación es exagerada, por supuesto, pero en su conjunto refleja la esencia. Por ejemplo, un cliente viene a mí y me dice: "Quiero facebook. ¿Cuándo estará listo? " El tiempo mínimo para resolver un problema que logré encontrar es de 15 minutos. Voy a Facebook, tomo una captura de pantalla, hago una página con una imagen de captura de pantalla, la pongo en mi servidor. Satisface las condiciones del problema. Incluso puede mejorar la implementación: no tome una foto, pero haga un iframe con Facebook (aunque, como esperaba, Facebook ya se encargó de esto) Dado que la evaluación del tiempo determina la forma de completar la tarea, puede reducir el tiempo para completar cualquier tarea de 2 a 3 veces (sucede 5 veces). Es curioso que esta ley empírica se compruebe constantemente en la práctica.

  1. Descomponemos la tarea en subtareas. Resulta algo así como esta imagen (lo llamamos el "árbol de Navidad"): evaluar horizontalmente las tareas a tiempo, verticalmente - prioridad.
    imagen
  2. Ordenamos las subtareas por prioridad (primero valor de negocio + "carga", luego arriesgado, luego el resto en orden de importancia).

    imagen
  3. Si es necesario reducir la estimación, recortamos el problema desde abajo. ¿Por qué podemos reducir? Algunos de los riesgos funcionados y el aumento o el valor comercial no eran exactamente los mismos que se suponía que debían ser. Estas son cosas importantes y sin ellas la tarea no se puede pasar. Es necesario arreglarlo. Entonces podremos entrar en la evaluación haciendo las partes principales de la tarea (dependiendo de la falla, se realizará una parte mayor o menor de la tarea).

    imagen

Proceso de evaluación de tareas


Ok, la epopeya se descompuso. ¿Y cómo evaluar el tamaño de una tarea específica?

  • Si ya hemos hecho exactamente esta tarea . Tenemos estadísticas en alguna parte, cuánto tiempo pasó en una tarea similar. Si no lo hicimos, sino un colega, entonces podemos tomar su resultado y multiplicarlo por el coeficiente de diferencia entre ese momento y ahora (nivel de desarrollador, conocimiento del sistema, conocimiento de riesgos). Subimos a las estadísticas, multiplicamos, obtenemos. 
  • . , . , 60%. , 60% , . , — , 1.5-2 .
  • . R&D. — , . — . (1, 2, 4 ), — . , , . , R&D, 1-2 , R&D . — R&D. - — , , . — N — - ( ). , — , . , , — .

:
  • , ( ) , , . , , .
  • Planning poker. , . : -, , , , -, , ,
  • (/ ), . . , . , , 70% .
  • PERT. , (-) 5 . .
    minrealmax
    <>28209

    — , , — , ( ), — , , ( ).
    :
    imagen

Los coeficientes 4 y 6 se toman, según tengo entendido, del supuesto de que, en el caso general, la probabilidad de riesgo se distribuye normalmente, y las colas (min / max) son igualmente probables.

El proceso de entrar en calificaciones


imagen

Dar una evaluación es la mitad de la batalla. Lo más valioso es entrar en esta evaluación. Y el proceso de completar una tarea es un proceso activo, de la participación en la que el resultado final depende más que de una estimación acertada al principio. Y adhiérase a un aspecto similar en áreas completamente diferentes. Vi muchos casos en los que, después de hacer una evaluación, el desarrollador toma una posición pasiva "bueno, a dónde ir ahora, pase lo que pase", dobla las piernas y sigue la corriente. Y ahora es el momento de actuar.

Técnicas útiles en hit:

  • 6. : . — , - , . /, . ( «» - ). , , - . — . . ? N.
  • «».
  • , (- + ) — , . 30%.
  • .
  • , ( ) . ( ) — , . — , . — , . .
  • ( ). . , , , . , , . « » — 20-30%, 50. . ( ) , , , .


Y para empezar, existe el efecto de enderezar los plazos asociados con las evaluaciones de tareas. Se describe con más detalle, por ejemplo, aquí , y por lo tanto no lo repetiré. Tal como se aplica a las evaluaciones, tiene la consecuencia de que es necesario evaluar tareas y monitorear el golpe, si es importante que lo completemos en algún momento. Incluso si la tarea es pequeña, y hay mucho tiempo antes de su entrega (como con el desarrollador mencionado anteriormente, abrumado por el trabajo, a quien no le gustaba dar calificaciones). Y si no representamos exactamente qué es la acción (y nos guiamos por el hecho de que es grande y "el estado no se empobrecerá"), obtendremos un exceso incontrolado de términos. Y no importa qué búfer se coloque: 2x, 5x, 100x; si no lo manejas, se comerá de todos modos.

Conclusión


Con este enfoque, los desarrolladores pueden optimizar y simplificar el proceso de evaluación. Y las fuerzas se gastarán menos, y el estrés disminuirá, y el resultado final será mejor. Y también podemos presentar sorpresas menos desagradables a "ellos", y luego descubriremos que "ellos" comenzaron a hablar el mismo idioma con "nosotros".

imagen

All Articles