El Instituto enseña algoritmos, estructuras de datos, OOP. En un buen caso, pueden hablar sobre patrones de diseño o programación multiproceso. Pero no escuché sobre cómo evaluar correctamente los costos laborales.

Mientras tanto, cada programador necesita esta habilidad todos los días. Siempre hay más trabajo del que se puede hacer. La evaluación ayuda a priorizar correctamente y a abandonar algunas tareas por completo. Sin mencionar cuestiones del hogar como el presupuesto y la planificación. Las estimaciones incorrectas, por el contrario, crean un montón de problemas: subestimados - situaciones de conflicto, procesamiento y agujeros en los presupuestos, exagerados - cancelando proyectos o buscando otros artistas.

Para ser justos, debe tenerse en cuenta que la subvaloración es mucho más común en el desarrollo. Por qué Alguien piensa que los programadores son demasiado optimistas por naturaleza. Agregaré una razón más a esto: ser un buen programador y ser un buen tasador no es lo mismo. Para convertirse en un buen programador, un deseo no es suficiente. Necesita conocimiento y práctica. ¿Por qué la evaluación sería diferente?

En el artículo hablaré sobre cómo ha cambiado mi actitud hacia la evaluación de tareas y cómo se están evaluando los proyectos en nuestra empresa. Y comenzaré con cómo no necesita evaluar. Si ya sabe cómo "no", vaya directamente a la segunda parte del artículo .

Patrones anti evaluación

La mayoría de las evaluaciones en los proyectos se realizan al comienzo de su ciclo de vida. Y esto no nos molesta hasta que comprendamos que las estimaciones se obtuvieron antes de que se determinaran los requisitos y, en consecuencia, antes de que se estudiara la tarea misma. En consecuencia, una evaluación generalmente no se realiza a tiempo. Este proceso se llama correctamente no evaluación, sino adivinar o predecir, porque cada punto en los requisitos es un juego de adivinanzas. ¿Cuánto afecta esta incertidumbre a los resultados finales de la evaluación y su calidad?

Un poco, pero desagradable.

Supongamos que está desarrollando un sistema de ingreso de pedidos, pero aún no ha podido desarrollar los requisitos para ingresar números de teléfono. Entre las incertidumbres que pueden afectar la evaluación del programa, podemos destacar de inmediato lo siguiente:

¿Necesita el cliente que se verifique la validez del número de teléfono ingresado?
Si el cliente necesita un sistema de verificación de número de teléfono, ¿qué versión preferirá, barata o cara?
Si implementa una versión barata de verificar números de teléfono, ¿el cliente querrá cambiar a la costosa más tarde?
¿Es posible usar un sistema listo para verificar números de teléfono o, debido a algunas restricciones de diseño, necesita desarrollar el suyo propio?
¿Cómo se diseñará el sistema de verificación?
¿Cuánto tiempo lleva programar un sistema de verificación de número de teléfono?

Y estas son solo algunas preguntas de la lista que surge en la cabeza de un gerente de proyecto experimentado ... Como se puede ver incluso en este ejemplo, las posibles diferencias en la definición, diseño e implementación de las mismas oportunidades pueden acumularse y aumentar el tiempo de implementación en cientos o más veces. Y si los combinamos en cientos y miles de funciones de un proyecto grande, obtenemos una enorme incertidumbre en la evaluación del proyecto en sí.

Otro excelente ejemplo de una "hinchazón" parecería ser un requisito elemental, lea en el artículo " ¿Cómo son dos semanas? "

Cono de incertidumbre

El desarrollo de software, y muchos otros proyectos, consta de miles de soluciones. Los investigadores encontraron que las estimaciones del proyecto en diferentes etapas inherentes a los niveles proyectados de incertidumbre. El cono de incertidumbre muestra que las estimaciones se vuelven más precisas a medida que avanza el proyecto. Tenga en cuenta que en la etapa del concepto inicial (donde a menudo se hacen estimaciones y se hacen obligaciones), el error puede ser del 400% (¡cuatrocientos por ciento, Karl!). Es óptimo hacer compromisos después de completar el diseño detallado.

Mítico hombre-mes

Todavía hay ejecutivos que creen que si la funcionalidad se fija rígidamente, se puede lograr una reducción en el tiempo en cualquier momento agregando personal que haría más trabajo en menos tiempo. El error de tal razonamiento radica en la unidad de medida utilizada en la evaluación y planificación: hombre-mes. El costo se mide realmente como el producto de la cantidad de empleados y la cantidad de meses gastados. Pero el resultado no se logra. Por lo tanto, el uso de meses-hombre como unidad de medida del volumen de trabajo es un concepto erróneo peligroso. Todos los investigadores estuvieron de acuerdo en que reducir el período nominal aumenta la cantidad total de trabajo. Si el término nominal para un grupo de 7 personas es de 12 meses, entonces un simple aumento de personal a 12 personas no reducirá el período a 7 meses.

En grupos grandes, los costos de coordinación y gestión aumentan, y el número de vías de comunicación aumenta. Si todas las partes de la tarea deben coordinarse por separado entre sí, entonces el costo de la comunicación aumentará de forma cuadrática y el "poder" del equipo crecerá linealmente. Tres trabajadores requieren tres veces más comunicación por parejas que dos, cuatro por seis.

imagen

El equipo del proyecto está tratando de hacer frente a las nalgas // Ivan Aivazovsky, 1850

Si 8 personas pueden escribir un programa en 10 meses, ¿pueden 80 personas escribir el mismo programa en un mes? La ineficiencia de los plazos de ajuste extremos se hace especialmente evidente en casos extremos, como 1.600 personas que necesitan escribir un programa en un día. Lea más sobre esto en el libro del mismo nombre de Frederick Brooks .

Patrones de evaluación

Entonces, con los problemas todo está claro. Que se puede hacer

Descomposición

En lugar de evaluar una tarea grande, es mejor dividirla en muchas pequeñas, evaluarlas y obtener la calificación final como la suma de las calificaciones iniciales. Por lo tanto, matamos inmediatamente hasta cuatro pájaros de un tiro:

Comprendemos mejor el alcance del trabajo. Para descomponer una tarea, debe leer los requisitos. Lugares inexplicables surgirán de inmediato. Se reduce el riesgo de malinterpretar los requisitos.
Durante el análisis de un análisis más detallado de los requisitos, el proceso de pensamiento de sistematización del conocimiento comienza automáticamente. Esto reduce el riesgo de olvidar alguna parte del trabajo, como la refactorización, la automatización de pruebas o el esfuerzo adicional de diseñar e implementar
El resultado de la descomposición se puede utilizar para la gestión de proyectos, siempre que se haya utilizado una herramienta para ambos procesos (este tema se analiza con más detalle más adelante en el texto).
Si medimos el error promedio de la estimación de cada problema obtenido durante la descomposición y comparamos este error con el error de la estimación total, resulta que el error total es menor que el promedio. En otras palabras, dicha evaluación es más precisa (más cercana a los costos laborales reales). A primera vista, esta afirmación es contra intuitiva. ¿Cómo puede ser más precisa la evaluación final si cometemos un error al evaluar cada problema descompuesto? Considera un ejemplo. Para crear un nuevo formulario, debe: a) escribir el código en el backend, b) hacer el diseño y escribir el código en la interfaz, c) probar y diseñar. La tarea A se evaluó a las 5 horas, las tareas B y C a las 3 horas cada una. La puntuación total fue de 11 horas. En realidad, el backend se realizó en 2 horas, el formulario tomó 4 y la prueba y la corrección de errores tomó otros 5. La carga de trabajo total fue de 11 horas. Ideal para ser calificado. Además, el error al evaluar la tarea A es de 3 horas, la tarea B es de 1 hora y C es de 2 horas. El error promedio es de 3 horas. El hecho es que los errores de subestimar y sobreestimar las estimaciones se cancelan mutuamente. Las 3 horas ahorradas en el backend compensaron el retraso de 1 y 2 horas en las etapas de front-end y prueba. El trabajo real es una variable aleatoria que depende de muchos factores. Si se enferma, le será difícil concentrarse y, en lugar de tres horas, puede tomar seis. O aparecerá un error inesperado que deberá buscarse y repararse todo el día. O, por el contrario, puede resultar que en lugar de escribir su propio componente, puede usar uno existente, etc. Las desviaciones positivas y negativas se cancelarán mutuamente. Por lo tanto, el error total disminuirá.

Características y tareas

En el corazón de la descomposición que tenemos está la Característica. Una característica es una unidad de entrega de funcionalidad que se puede poner en producción independientemente de los demás. A veces, este nivel se llama User Story, pero llegamos a la conclusión de que User Story no siempre es adecuado para establecer tareas, por lo que decidimos usar una formulación más general.

Un miembro es responsable de una característica. Alguien puede ayudarlo con la implementación, pero una persona pasa a la prueba. La tarea también le está siendo devuelta para su revisión. Dependiendo de la organización del equipo, este puede ser un líder del equipo o directamente un desarrollador.

Desafortunadamente, a veces hay grandes características. Llevará mucho tiempo trabajar solo en ese volumen. Y durante mucho tiempo tendrá que probar e implementar el proceso de aceptación. Luego cambiamos el tipo de tarea a Epic. Epic es solo una característica muy gruesa. No empezamos nada más que una epopeya. Es decir Las epopeyas pueden ser grandes, enormes o gigantescas. En cualquier caso, la epopeya se envía en partes (características) a la aceptación.

Para evaluar con mayor precisión, las características se descomponen en subtareas separadas (Tarea). Por ejemplo, una característica podría ser el desarrollo de una nueva interfaz CRUD. La estructura de las tareas puede verse así: "mostrar una tabla con datos", "ajustar el filtro y buscar", "desarrollar un nuevo componente", "agregar nuevas tablas a la base de datos". La estructura de tareas generalmente no es nada interesante para los negocios, pero es extremadamente importante para el desarrollador.

Evaluación en grupos, planificación de póker.

Los programadores son demasiado optimistas sobre la cantidad de trabajo. Según diversas fuentes, la subvaloración con mayor frecuencia varía en el rango de 20-30%. Sin embargo, en grupos el error se reduce. Esto se debe a un mejor análisis debido a los diferentes puntos de vista y la evaluación del temperamento.
La práctica más común con la creciente popularidad de Agile es la práctica de " planificación de póker ". Sin embargo, hay dos problemas asociados con la evaluación grupal:

Presión social
Costos de tiempo

Presión social

En casi cualquier grupo, la experiencia y la efectividad personal de los participantes variarán. Si el equipo tiene un equipo / tecnología fuerte, el programador líder / líder, otros miembros pueden sentirse incómodos y deliberadamente subestimar las calificaciones: “Bueno, ¿cómo puede Vasya hacerlo, pero estoy peor? ¡Yo también puedo hacer eso! Las razones pueden ser diferentes: el deseo de parecer mejor de lo que realmente es, la competencia o simplemente el conformismo. El resultado es uno: una evaluación grupal pierde todas sus ventajas y se vuelve individual. Timlid da marcas, y el resto simplemente asiente a él.

Durante mucho tiempo presioné al equipo para obtener clasificaciones más consistentes con mis expectativas. Esto condujo invariablemente a una disminución de la calidad y un desglose en términos. Como resultado, cambié mi actitud y ahora mi calificación suele ser la más alta. Durante la discusión, señalo problemas potenciales que me vienen a la mente: "aquí la refactorización no dolería, aquí la estructura de nuestra base de datos está cambiando, sería necesario hacer una prueba de regresión".

Hay varias recomendaciones principales:

La mayoría de las calificaciones están subestimadas. ¿No puedes elegir entre dos clasificaciones? Toma el que es más grande.
No estoy seguro acerca de la evaluación: tire la tarjeta "?" o una gran calificación Quizás casi nunca lleva.
Siempre compare plan y hecho. Si sabe que no encaja dos veces, calcule dos veces más de lo que cree. Comenzó a exagerar? Multiplica en tu mente por uno y medio. Después de algunas iteraciones, la calidad de sus calificaciones debería mejorar significativamente.

Costos de tiempo

Conoces la frase "¿Quieres trabajar?" ¡Reúna una reunión! No solo un programador intenta predecir el futuro en lugar de escribir código. Ahora todo el grupo lo hace. Además, resolver una decisión en un grupo es un proceso mucho más largo que tomar decisiones individuales. Por lo tanto, la evaluación grupal es un proceso extremadamente costoso. Vale la pena mirar estos costos desde el otro lado. Primero, en el proceso de evaluación, el grupo se ve obligado a discutir los requisitos. Esto significa que tienes que leerlos. Ya no está mal. En segundo lugar, comparemos estos costos con los que incurre la compañía debido a la subestimación del proyecto.

Hace muchos años, un día de noviembre, cambié mi trabajo a una gran empresa. Inmediatamente me di cuenta de que el trabajo estaba en pleno apogeo. La mitad de la compañía trabajó para lanzar el producto antes de fin de año. Pero después de aproximadamente una semana me pareció que para fin de año no tendrían tiempo. Con cada día siguiente, las posibilidades de éxito de esta empresa se hicieron cada vez más ilusorias ... El proyecto se entregó realmente en diciembre, aunque el año próximo. Me enteré de esto mucho más tarde, porque en el verano los problemas comenzaron con el pago de salarios a los empleados y renuncié junto con aproximadamente la mitad del personal. Puedes decir "bueno, por supuesto, los gerentes son tontos, tenías que ir a lo seguro". Se aseguraron a sí mismos. Seis meses no hubo problemas con el pago de los salarios. Mantener un stock de capital de trabajo durante medio año de financiación no es una tarea fácil. Creo que si la evaluación fuera más precisa, habría otras decisiones de gestión en el nivel de alta dirección.

Si consideramos la inversión en la evaluación como una inversión en la adopción de decisiones de gestión acertadas, entonces dejan de parecer tan costosas. El tamaño del grupo es otro asunto. Por supuesto, no es necesario obligar a todo el equipo a evaluar la cantidad total de trabajo. Es mucho más razonable dividir la tarea en ~~módulos~~ , ejem, microservicios y proporcionar a los equipos autonomía. Y en un nivel superior, use las estimaciones obtenidas por cada equipo para elaborar un plan de proyecto. Lo que sin problemas nos lleva al tema del siguiente párrafo.

Diseño de dependencia, diagramas de Gantt

Si los programadores generalmente dan evaluaciones, entonces la elaboración de un plan de proyecto es la tarea de los gerentes intermedios. Recuerde, escribí que estos tipos pueden ser ayudados si se usa una herramienta para la descomposición y la gestión de proyectos. La evaluación y el tiempo del calendario no son lo mismo. Por ejemplo, para mostrar una tabla de datos simple, necesitaría:

Tabla DB
Código de fondo
Código Frontend

Realizar tareas en este orden es más fácil desde un punto de vista técnico. Sin embargo, en realidad hay diferentes especializaciones. Un especialista de front-end se puede programar para liberar antes. En lugar de estar inactivo, es más lógico comenzar a desarrollar la interfaz de usuario reemplazando la solicitud del servidor con datos simulados o codificados. Luego, cuando la API esté lista, solo queda reemplazar el código con una llamada a un método real ... en teoría. En la práctica, el nivel máximo de paralelismo se puede lograr de la siguiente manera:

Primero nos jactamos rápidamente para acordar la especificación API
Luego codifique los datos en la parte posterior o frontal, dependiendo de quién esté a la mano.
Al mismo tiempo, hacemos bases de datos, backend y front-end. La base de datos y el backend se bloquean parcialmente entre sí, pero la mayoría de las veces estas competencias se combinan en una sola persona y el trabajo en realidad va secuencialmente: primero una base de datos, luego un backend
Recolectamos todo y probamos
Arreglamos errores y probamos de nuevo

Es importante que los pasos 1, 4 y 5 se ejecuten lo más rápido posible para reducir el número de bloqueos. Además de las limitaciones tecnológicas y las restricciones sobre la disponibilidad de especialistas con la competencia necesaria, ¡todavía hay prioridades comerciales! Y esto significa que después de tres semanas se programó una demostración para un cliente importante y quería escupir en la primera mitad del plan de su proyecto. Quiere ver el resultado final, que estará disponible no antes de dos meses después. Bueno, entonces tienes que preparar un plan separado para esta demostración. Agregamos al plan para introducir los datos necesarios en la base de datos, insertar nuevos enlaces para las transiciones a la interfaz de usuario, etc. También es deseable que al final fuera necesario tirar el 20% del código, y no toda esta demostración.

El corte artístico de tal plan no es una tarea fácil. Construir dependencias simplifica enormemente el proceso. Antes de continuar con el módulo de informe, debe crear un módulo de entrada de datos. ¿Es lógico? Agregar una dependencia. Repita para todas las tareas relacionadas. Créeme, muchas de las dependencias te sorprenderán.

En las tareas de automatización de procesos comerciales, generalmente se obtienen varias "serpientes" largas de tareas relacionadas con varios nodos de bloqueo grandes. Muy a menudo, el plan inicial no es efectivo en términos de utilización de recursos y / o demasiado largo en términos de calendario. La revisión de la evaluación de los costos laborales sucederá más rápido, no es una opción. La evaluación, por lo tanto, es probablemente optimista. Tenemos que volver a la descomposición, buscar cadenas que sean demasiado largas y agregar "horquillas" adicionales para aumentar el grado de paralelismo. Por lo tanto, debido a un aumento en los costos laborales totales (más personas trabajan simultáneamente en un proyecto), se reduce el período calendario del proyecto. ¿Recuerdas el "mítico hombre-mes"? Es poco probable que un plan se reduzca más del 30%. Para que el presupuesto y la fecha límite se acuerden, el plan puede revisarse varias veces. Hay varios trucos para que el proceso sea más rápido y fácil.

Bloqueo de tareas

La primera razón para el bloqueo (dependencias) ya la hemos considerado.Además, puede haber simplemente requisitos incomprensibles / inexactos. Se necesita una herramienta para bloquear tareas y hacer preguntas. Con la especificación de requisitos, puede desbloquear tareas y ajustar la calificación. Este proceso, por cierto, casi siempre continúa durante el proyecto, y no antes.

El camino crítico, riesgos por delante

. , ( ), , , , . , , , , , , . , .

, , , , . " ". , , . - . , , .

, , «» , , .

,

: , — — . . , , - .

? . , , , - , . . .

aka time tracking

El tiempo y la asistencia han sido durante mucho tiempo el estándar de facto en la industria. Es altamente deseable que se produzca en la misma herramienta que la evaluación. Esto le permite rastrear la desviación del tiempo real gastado de lo estimado. Es bueno si el administrador del proyecto también usa esta herramienta. Entonces, todos los retrasos de la ruta crítica se notarán de inmediato. También es posible una variante con diferentes herramientas, pero requerirá costos de mano de obra significativamente mayores para el mantenimiento del proceso, lo que significa que habrá una tentación de perder el tiempo. Ya sabemos cómo termina esto. Usamos YouTrack . Todo lo que escribí en el artículo está actualmente disponible de fábrica, aunque requiere un pequeño ajuste.

Conclusión

La evaluación es difícil.
La descomposición le permite encontrar lagunas en los requisitos y mejorar la calidad de la evaluación.
Los puntajes grupales son más precisos que los individuales, usa el póker
Los bloqueadores, los casos de prueba y los criterios formales de aceptación mejoran la comunicación, lo que a su vez aumenta las posibilidades de éxito del proyecto.
Debe comenzar con las tareas más riesgosas en la ruta crítica del proyecto
La evaluación no es una acción única, sino un proceso inseparable de la gestión del proyecto.
Sin tener en cuenta el tiempo de trabajo, es imposible mantener actualizado el estado del proyecto y ajustar sus estimaciones.

¿Quieres saber más sobre la evaluación de proyectos?

Lea el libro de Steve McConnell " Cuánto cuesta un proyecto de software " y otros artículos sobre este tema en Habr

Acerca de la evaluación y gestión del desarrollo de productos de software