Tengo muchas obsesiones, una de ellas es encontrar caminos que me lleven a ayudar a las organizaciones a encontrar la mejora constante y continua de su desempeño y posición estratégica. En esa búsqueda tuve un hallazgo interesante: The Phoenix Project, un libro en el que conocí el concepto de los cuatro tipos de trabajo.[1] A propósito de este nuevo conocimiento, me propuse hacer un experimento, no sin antes compartirles mi aprendizaje.
Los cuatro tipos de trabajos son:
- Proyectos de negocio: Están diseñados para darle valor al cliente, en términos de productos o servicios.
- Proyectos de operaciones: Existen para entregar recursos o capacidades a los proyectos del negocio. Proveer insumos, hacer mejoras, capacitarse, reflexionar o innovar son algunos de los asuntos posibles en este tipo de trabajo. También se incluyen asuntos de corte tecnológico como tunnings de bases de datos, actualizaciones de componentes o mantenimientos preventivos, entre otros.
Cambios: Son los trabajos que tienen como objetivo hacer que lo construido finalmente sea utilizable por las personas para las que se construyó. Por ejemplo: Las actividades que se ejecutan desde que una funcionalidad de un software está desarrollada, hasta que el usuario final la pueda utilizar. [2] - Trabajo no planeado: Este trabajo se presenta cuando debemos solucionar alguna situación para restablecer a un estado anterior el servicio o los productos que proveemos. No confundir «trabajo no planeado» con imprevistos no causados por errores, como aquellos en los que un cliente nos hace una solicitud inesperada. En la industria del software la principal causa del trabajo no planeado es la falta de calidad, que conlleva a la deuda técnica. Si tenemos una deuda técnica creciente, no la gestionamos y la dejamos crecer indefinidamente, este trabajo terminará ocupando todo nuestro tiempo, y no podremos dedicarnos a los otros tipos de trabajo.[3]
Si tenemos una deuda técnica creciente, no la gestionamos y la dejamos crecer indefinidamente, este trabajo terminará ocupando todo nuestro tiempo, y no podremos dedicarnos a los otros tipos de trabajo.
El experimento
Ahora que conocemos los cuatro tipos de trabajo, llegó la hora del experimento. Consiste en responder a cada una de las preguntas propuestas. Una vez que lo hagas, tendrás elementos reveladores para enfocar mejor el tiempo y esfuerzo de las personas de tu organización.
- ¿Qué porcentaje del tiempo y de las inversiones le estamos dedicando a los proyectos de negocio? Es decir ¿qué porcentaje de nuestro tiempo se va en generar valor directamente para el cliente?
- ¿Qué porcentaje del tiempo y de las inversiones le estamos dedicando a los proyectos de operaciones? es decir: ¿Qué porcentaje de nuestro tiempo le estamos dedicando a la mejora en las capacidades de nuestras operaciones? y ¿qué porcentaje de nuestro tiempo e inversión le estamos dedicando a la disminución de la la deuda técnica?
- En cuanto a los cambios: ¿cuántos cambios hacemos por período de tiempo?, ¿llevamos control de qué cambiamos?, ¿hacemos cambios pequeños y con alta frecuencia[4]? o ¿son grandes y poco frecuentes?, ¿controlamos el por qué y el para qué de cada cambio?, ¿tenemos claro qué tipos de cambios hacemos?, ¿cuánto tiempo nos toma hacer cada tipo de cambio?. Los cambios que hacemos, o que no hacemos ¿a qué posición estratégica nos llevan?, ¿son cambios para defendernos de la competencia?, ¿para innovar? ¿retener a nuestros clientes?, ¿lograr nuevos clientes?, ¿crear nuevas y mejores experiencias?
Te invito a investigar de Devops[5] para profundizar en este tema. - En cuanto al trabajo no planeado: ¿Sabe cada persona, cada equipo y la organización qué porcentaje de tiempo dedica al trabajo no planeado?, ¿qué tendencia tiene este porcentaje?, ¿sabemos cuál es el porcentaje de tiempo que le debemos dedicar a el trabajo no planeado idealmente?, ¿cuáles y cuántos trabajos de proyectos de operaciones hacemos para disminuir la deuda técnica? ¿qué impacto tienen estos proyectos en la disminución del trabajo no planeado?
Las respuestas a estas preguntas y el análisis de las tendencias en cuanto al análisis de los tipos de trabajos pueden tener un impacto positivo y disruptivo en el desarrollo de tu trabajo individual y de tu organización.
¿Estás de acuerdo?, ¿se te ocurren más preguntas?, ¿Te animas?
Finalmente quiero contarte algunas expansiones que propongo a los conceptos de proyectos de negocio y de operaciones planteados por los autores:
En cuanto a proyectos de negocio:
- Prefiero el término trabajos o productos a proyectos. Me gusta más su aplicación en el día a día que en un proyecto con un principio y un fin.[6] [dt_gap height=»20″ /]
- Puede ser aplicado a todos los interesados (Stakeholders) de la organización, además de los clientes. Es así como también se tiene en cuenta a empleados, proveedores, accionistas, la comunidad y el gobierno.
En cuanto a Proyectos de operaciones:
- Nuevamente, prefiero los términos trabajos o productos a proyectos, por las razones anteriormente citadas.
- Pienso que no debe ser sólo referente a operaciones o tecnología e informática, sino a cualquier equipo que trabaje por adecuar o mejorar las capacidades que se le dan a la organización o por disminuir la deuda técnica.
_______________________________________
[1] Literalmente dice“Bill mentioned the four types of work: Business projects, operations projects, changes and unplanned work.Left unchecked, Technical debt will ensure that the only work that gets done is unplanned work”. En: Behr, Kevin; Kim, Gene; Spafforg, George, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, 2018
[2] He reflexionado sobre este tema y, aunque fue retador considerar el trabajo de cambios como un trabajo más, sin embargo terminé por estar de acuerdo con los autores.
[3] La deuda técnica es el coste y los intereses a pagar por hacer mal las cosas. El sobre esfuerzo a pagar para mantener un producto mal hecho y lo que conlleva. Para más info visitar este artículo de Javier Garzas
[4] Los cambios pequeños y frecuentes son una característica de la agilidad, es por esto que la agilidad y DevOps están profundamente relacionados.
[5] Ver: https://www.goodreads.com/book/show/17255186-the-phoenix-project
[6] Reflexión inspirada en el libro PROJECT TO PRODUCT How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework de MIK KERSTEN
Imagen del artículo: Photo by krakenimages on Unsplash
Mantente al tanto de nuestras publicaciones a través de nuestras redes sociales: LinkedIn, Instagram y Twitter.
