Gestión de proyectos, Categoría 30+

¡Detente, detente, límpialo de inmediato! Para cerrar un proyecto fallido, necesita dos cosas: debe comprender que el proyecto ha fallado y debe cerrarlo. Pero no tan simple.



Este artículo se basa en un informe de Maria Belkina de SEMrush, del OKR-mitap en San Petersburgo : "La experiencia de cambiar de OKR a Spotify Rhythm". Aunque el título del informe implica una demostración de las deficiencias de OKR, las ventajas de Rhythm y la forma de reemplazar una por otra, su tema principal fue la pregunta: "¿Qué hacer con los proyectos fallidos?". Este es un tema agudo y doloroso que es interesante de entender.

La cultura de inicio está comprometida con el éxito. Si puede lograr el objetivo, debe continuar con el mismo espíritu. Pero no todos los proyectos tienen éxito, en la mayoría de los casos solo se pueden lograr resultados mediocres, o algo peor. ¿Qué pasa con tales proyectos? - Siguen. Para todos: tanto para la gerencia como para los artistas intérpretes o ejecutantes, es mucho más fácil continuar invirtiendo en un proyecto fallido que reconocer su fracaso. La escalada del problema puede generar conflictos en el equipo, por lo que puede arruinar la relación con los colegas. Nadie necesita esto. Pero si no hace nada, el desarrollo se atascará en proyectos inútiles y el producto se convertirá en una mezcla sin soporte de características inútiles. Esto tampoco es bueno.

El dinero siempre es importante, pero las personas son un recurso clave para el desarrollo. Durante un mes de trabajo, un grupo de cien personas quemará una cantidad igual de dinero, independientemente del resultado. Por supuesto, organizar el mejor resultado es lo principal en la gestión del desarrollo. Pero cuando aparece una nueva idea, "¡esto es lo que tenemos que hacer!", A menudo resulta que no hay nadie para abordarla. Todos los desarrolladores están ocupados con las tareas actuales, y eso no es lo más importante, pero no puedes dejarlas. Esto es típico de un producto maduro.

Cuanto más antiguo sea el producto de software, mayor será la proporción de recursos gastados en su soporte y más lento será el nuevo desarrollo. Incluso si las características son utilizadas por doscientos usuarios de cada cien mil, el error aún tendrá que repararse. La introducción de nuevas tecnologías requerirá corregir todo el código, independientemente de si el método se llama cada milisegundo o una vez al mes. Un proyecto iniciado es mejor terminar que dejar sin terminar. Cualquier cambio global requerirá pruebas completas, etc. Todo esto es un poco aleccionador y te hace pensar críticamente sobre las perspectivas.

No todos los proyectos serán exitosos, esta es la realidad. Puede vivir con esto, pero en algún momento, la gerencia debe comprender que no puede continuar esparciendo juguetes en el piso. Periódicamente, deben recogerse nuevamente en la caja, de lo contrario habrá un desastre. Sí, ordenar es aburrido. Si, lleva tiempo. Sí, alguien puede estar molesto porque su juguete favorito fue devuelto a la caja. Pero somos adultos.

¿Qué significa cerrar un proyecto fallido? No es solo cancelar diez años-hombre de trabajo con pérdidas. Toda la funcionalidad desarrollada también debe eliminarse del producto, y esto es trabajo adicional y costos adicionales. También habrá usuarios insatisfechos a quienes, por alguna razón, les gustó la funcionalidad del proyecto. No te olvides de las oportunidades perdidas. Parece que el tiempo y el esfuerzo invertidos en cerrar el proyecto se pueden usar con mayor beneficio. Cerrar el proyecto - caro. Para dar ese paso, necesita la voluntad, la determinación y la comprensión de que la salud del producto a largo plazo es más importante que el ahorro táctico. Pero incluso si existe la voluntad de implementar medidas tan drásticas, aún se necesita el desencadenante, se necesita una forma de entender que el proyecto ha fallado.

Criterio de falla del proyecto. Por lo general, se acostumbra definir un criterio de éxito. Parece que si se definieron los criterios de éxito y el proyecto no los alcanzó, entonces fracasó. Absolutamente no. Entre el éxito y el fracaso se encuentra una gran área gris. Al no alcanzar los valores de los indicadores que determinan el éxito, siempre existe la sensación de que "simplemente no hemos hecho lo suficiente", "solo un poco más y luego todo saldrá bien". Quizás esto sea así. Pero evaluar un proyecto de acuerdo con los criterios de éxito plantea solo la pregunta "¿continuar o no?", Y esa pregunta no implica una respuesta "¡cierra y destruye!".

El criterio para el fracaso del proyecto es ese límite inferior de indicadores, que cae por debajo del cual el proyecto debe ser destruido. Al igual que un barco que tiene un agujero debajo de la línea de flotación, debería hundirse. Con todo el orgullo, grandeza y profesionalidad posibles.

Así como el éxito no debe conducir a la envidia, el fracaso no debe incitar al odio en un equipo. A la larga, todo esto es una rutina del proceso de trabajo. Para que el fracaso del proyecto no conduzca a conflictos, los criterios para el fracaso deben determinarse y acordarse de antemano, así como los criterios para el éxito. Además, un plan de terminación del proyecto debe prepararse con anticipación, incluso antes que el plan del proyecto en sí. Luego, habiendo determinado que el proyecto ha fallado, no habrá duda de qué hacer en esta situación. Puede proceder inmediatamente a la acción decisiva. Todo de forma adulta.

Es razonable argumentar que nuestro cerebro está tan organizado que, pensando en el fracaso de antemano, nos preparamos para el fracaso. Tal vez. Pero la capacidad de pensar sobre las consecuencias es un signo de pensamiento maduro. Y las dificultades asociadas con esto, como parece, pueden superarse.

---

Dmitry Mamonov,
Wrike

PS. Continuando con el tema sobre cómo, por qué y cuándo eliminar las funciones del producto, puedo recomendar un informe de mi colega, Yuri Andreikovich.