Cómo definir el alcance de sus proyectos de software de forma eficaz

Desde que comencé mi carrera como ingeniero de software, he aprendido que el alcance es una de las cosas más difíciles de lograr. Desafortunadamente, los programas de informática en las universidades realmente no le enseñan cómo enfocar proyectos. Así que aquí está mi intento de consolidar lo que he aprendido sobre este tema.

El alcance no es algo en lo que pueda pasar un día durante el proyecto y nunca volver a pensar en ello. De hecho, para determinar el alcance de un proyecto con precisión, debe prestar atención durante todo el proyecto durante:

  1. La fase de planificación: las primeras etapas de la definición del proyecto y sus objetivos
  2. La fase de determinación del alcance: el momento en que la mayoría de la gente piensa en la determinación del alcance Aquí es donde intenta enumerar el trabajo que debe realizarse dados los objetivos del proyecto y estimar cuánto tiempo se requerirá para realizarlos.
  3. La fase de ejecución: cuando realmente está implementando el proyecto.

La fase de planificación

Una de las cosas más importantes que se deben hacer durante este tiempo es definir metas muy específicas para el proyecto . Por ejemplo, en lugar de "mejorar X para que sea más escalable y eficiente", un objetivo mejor y más específico podría ser "mejorar X agregando pruebas unitarias, admitiendo 20.000 consultas por segundo y reduciendo la media limitada de latencia del usuario a <= 200ms . "

Tener objetivos muy específicos le permite eliminar sin piedad cualquier cosa que no contribuya a estos objetivos, para que no sufra de alteraciones en las funciones. En este sentido, también podría considerar definir explícitamente los anti-objetivos y separar lo imprescindible y lo agradable .

Minimice el tamaño del lote del proyecto (1) estableciendo hitos claros y puntos de control para el proyecto, y (2) facilitando el lanzamiento de solo una parte del proyecto. Esto no solo ayuda a desglosar el proyecto, sino que también permitirá que el equipo pause o corte el proyecto antes si surge otra tarea de mayor prioridad.

Elimine el riesgo del proyecto lo antes posible . Dos formas comunes de eliminar el riesgo de un proyecto incluyen (1) trabajar en las partes más riesgosas por adelantado y (2) crear prototipos de las partes más riesgosas utilizando datos ficticios y / o andamios. Cada vez que se utiliza un nuevo sistema de código abierto o un servicio externo, eso suele representar un gran riesgo.

No optimice la cantidad total de trabajo realizado. En su lugar, optimice la cantidad total de impacto a lo largo del tiempo . Una vez que haya eliminado la parte más riesgosa, priorice el trabajo en la parte del proyecto que resultaría en la mayor cantidad de impacto de inmediato.

Aquí hay una forma de pensar en esto: grafica el impacto de un proyecto a lo largo del tiempo, donde el eje Y es el impacto y el eje X es el tiempo. Al inicio del proyecto, el impacto es del 0% y al final del proyecto, el impacto es del 100%. Desea maximizar el área bajo la curva realizando primero tareas de alto ROI.

Trate de evitar reescribir grandes sistemas desde cero tanto como sea posible . Al hacer una reescritura, tendemos a (1) subestimar cuánto trabajo sería, (2) sentir la tentación de agregar nuevas características y mejoras, y (3) construir un sistema demasiado complicado porque estamos demasiado enfocados en todas las deficiencias de el primer sistema.

En lugar de hacer una gran reescritura, considere la posibilidad de reemplazar subsistemas de forma incremental. Tenga buenas capas de abstracción que admitan el intercambio de una parte del sistema anterior a la vez, por lo que no necesita esperar a que se haga todo para probar el nuevo sistema.

La fase de determinación del alcance

  • Solo los ingenieros que escriben el código deben ser los que definan el alcance de las tareas. Ni sus gerentes, ni el PM, ni las partes interesadas clave de la empresa.
  • Resista la tentación de reducir el alcance . Sea honesto acerca de cuánto tiempo tomarán las tareas, no cuánto tiempo usted u otra persona (como su gerente o el equipo de Go To Market) quieren que tomen.
  • Divida el proyecto en pequeñas tareas, cada una de las cuales tomará dos días o menos . Cuando tiene tareas cuyo alcance es de “ aproximadamente 1 semana ”, a menudo terminan demorando más porque no enumeró todas las subtareas que podría necesitar hacer.
  • Defina hitos medibles para alcanzar la meta del proyecto. Programe cada uno con una fecha de calendario específica que represente cuándo espera que se alcance este hito. Luego, establezca algún tipo de responsabilidad externa sobre estos hitos, por ejemplo, comprometiéndolos con su gerente y estableciendo registros de hitos.
  • Piense en las estimaciones de tiempo del proyecto como distribuciones de probabilidad , no como en el mejor de los casos. En lugar de decirle a alguien que una función estará terminada en 6 semanas, dígale algo como “hay un 50% de probabilidad de terminar la función en 4 semanas y un 90% de probabilidad de que la terminemos en 8 semanas . ”Esto tiende a obligar a las personas a ser más realistas.
  • Agregue búfer para tener en cuenta: (1) ¡Tiempo de desarrollo! = Tiempo del calendario, debido a reuniones, entrevistas y días festivos. Por lo general, multiplico el tiempo de desarrollo por 1,5 para llegar al tiempo del calendario. (2) Tiempo de tareas de proyecto inesperado, ya que siempre hay tareas que no se dio cuenta de que tenía que hacer hasta mucho más tarde, como refactorizar código antiguo, depurar comportamientos aparentemente inexplicables, agregar pruebas. Cuanto más experiencia tenga en la determinación del alcance, menor será este multiplicador.
  • Utilice datos históricos. Lleve un registro de si ha tendido a sobrepasar o sublimar proyectos en el pasado (la mayoría de las personas tienden a sublimar). Ajuste su alcance en consecuencia.
  • Tenga en cuenta que 2X el número de personas no significa 1 / 2X el tiempo de desarrollo , como resultado de los gastos generales de comunicación, el tiempo de aceleración, etc.
  • Considere la posibilidad de establecer un marco temporal en partes abiertas del proyecto . En lugar de "encontrar el mejor marco de procesamiento de transmisión para este sistema", que puede llevar meses de investigación y creación de prototipos, márquelo para "encontrar un marco de procesamiento de transmisión adecuado en una semana". Utilice aquí su criterio para equilibrar esto con los gastos generales operativos a largo plazo.

La fase de ejecución

Cambie el alcance periódicamente durante la ejecución del proyecto. Para cada tarea, haga un seguimiento de cuánto tiempo estimó que le tomaría la tarea, luego cuánto tiempo realmente le tomó completarla. Haga esto para cada hito medible. Si su alcance está desviado en un 50% para las primeras partes del proyecto, es probable que su alcance también disminuya en un 50% para el resto del proyecto.

Utilice hitos para responder "¿cómo va el proyecto?" Como ingenieros, es tentador responder "estará listo la semana que viene" o "hasta finales de este mes". Pero este tipo de respuestas vagas tienden a crear proyectos que siempre están a 2 semanas de estar terminados. En su lugar, use los hitos (rediseñados) para dar una respuesta concreta basada en cuánto trabajo queda.

Si el proyecto fracasa, asegúrese de que todos comprendan por qué el proyecto fracasó. Luego, desarrolle una versión realista y revisada del plan del proyecto . Dejar el proyecto o acortarlo es una opción potencial que debería considerarse. Lea más sobre La falacia del costo hundido si tiene curiosidad por saber por qué las personas tienden a sesgar en contra de cortar un proyecto a la mitad.

Dando crédito a quien se lo merece, mucha información aquí proviene de hablar con ingenieros y gerentes como Spencer Chan y Nikhil Garg, leer libros como The Effective Engineer de Edmond Lau y analizar personalmente muchos proyectos con diversos grados de precisión.

Por último, si soy honesto, de ninguna manera soy un experto en el alcance y todavía cometo errores con regularidad, como no seguir algunas de las mejores prácticas anteriores. Simplemente pensé que documentaría mis aprendizajes hasta ahora para poder referirme a esto en el futuro.

Si te gusta esta publicación, sígueme en Twitter para obtener más contenido sobre ingeniería, procesos y sistemas de backend.