CustDevOps — Sostenibilidad en el desarrollo de productos de software

El desarrollo de producto pasa constantemente por las fases de design sprint, desarrollo y producción.

Me guardo la historia, ya citada 1.000 veces, sobre el fracaso de proyectos debido a una mala planificación, a la falta de requisitos o a una definición insuficiente de los mismos, a un control de calidad deficiente, a un personal inadecuado, al uso de tecnologías equivocadas o, por último, pero no por ello menos importante, a la necesidad de ahorrar dinero del departamento de compras, con las consecuencias que ello conlleva. La cantidad de recursos que se consumen y la decepción del personal, clientes, socios, etc., que conlleva es inaceptable. Si no ves esto como un reto, sino como una situación con la que “hay que vivir con ello”, entonces deja de leer en este punto. No formas parte de mi grupo objetivo. Lo siento mucho. Quiero cambiar algo y no misionar.

Me gustaría escribir sobre sostenibilidad. Sobre la sostenibilidad en el desarrollo de productos, donde los recursos deben ser considerados y claves: No me refiero a las personas, aunque a menudo se las llame de forma abstracta como tales recursos, sino al trabajo de las personas y a la vida útil invertida de los profesionales implicados (tanto trabajadores como clientes), a las tecnologías utilizadas, así como a nuestro entorno y al futuro asociado a él. Me gustaría que cada proyecto fuera un éxito o, al menos, allanar el camino para que pueda tener éxito con toda probabilidad.

La sostenibilidad comienza con la orientación al cliente

Cada proyecto comienza con un reto. El objetivo es cambiar algo, hacer algo mejor. Siempre se trata de recursos, personas, entorno y, por último, pero no por ello menos importante, de dinero. Tal vez incluso el poder en todas sus variaciones y manifestaciones. No siempre, pero a menudo. Alguien ve este desafío y le gustaría tenerlo resuelto, o acepta el reto por sí mismo y trabaja hacia una solución. Esto también se aplica a los proyectos de software. Aquí se quiere modificar el estado actual, no importa si se trata de una sustitución o de una modificación de un sistema existente o de la creación de uno nuevo. Se desea recuperar el control de una situación. Innovación es la palabra. Incluso cuando se crearon los programas Cobol. Con todos los sistemas de software que conozco, la gente siempre se ve afectada. Ya sea internamente en la empresa, aquellos que tienen que trabajar con ella, o externamente como clientes, es decir, aquellos que pagan para que se les permita trabajar con ella. Clientes que tienen necesidades. Si es así, ¿por qué no involucra a las personas de manera suficiente y continua para que lo que obtengan sea lo que quieren y puedan utilizar con éxito? Queremos seguir este enfoque por nosotros mismos para poder ofrecer siempre exactamente lo que nuestros clientes necesitan al final, a la vez que conservamos los recursos. Y para seguir desarrollándonos a nosotros y a nuestros productos y servicios junto con nuestros clientes.

Por lo tanto, siempre preguntamos y cuestionamos las necesidades del cliente, las definimos y las probamos. Nos proporcionan requisitos validados para nuestro producto, que podemos definir como una historia de usuario en nuestra cartera de pedidos. Como método utilizamos los Design Sprints creados por Google Ventures, que han sido adaptados, condensados y mejorados tanto por muchos como por nosotros. El cliente está involucrado en esta fase y nos permite utilizar los recursos proporcionados de forma moderada e involucrar a las personas de forma adecuada. No se duplica nada y no se crea nada superfluo. Sólo los resultados validados y específicos nos permiten pasar a la siguiente fase. Sólo cuando sabemos exactamente lo que el cliente quiere, el equipo de desarrollo sabe lo que tiene que hacer para producir estos resultados y, sobre todo, para probarlos adecuadamente de acuerdo con las necesidades del cliente. Si el cliente acompaña el desarrollo y responde a las preguntas planteadas, el equipo no puede tomar un camino equivocado. Al final, tenemos la funcionalidad que el cliente desea. En esta constante iteración entre el cliente y el equipo, la sostenibilidad se crea en primer lugar.

Después de haber usado este ping pong de retroalimentación con suficiente frecuencia, podemos lanzar confiadamente las funcionalidades proporcionadas en el mundo como MVP (producto viable mínimo). Esto significa que el producto entra en producción. Este paso también tiene junto con el cliente, que realiza todas las pruebas de aceptación. Nada sale al mercado que no haya sido definido, discutido y probado con el cliente de antemano. Todo en pequeños pasos. La agilidad en cualquiera de sus formas y modalidades es la base para la proximidad al cliente y el conocimiento de los recursos.

CustDevOps: La constante iteración del Design Sprint, el desarrollo y la producción

Las cinco fases del design sprint inician el desarrollo de producto orientado al cliente.

A esta iteración constante de Design Sprint, desarrollo y producción hasta el próximo Design Sprint es lo que llamamos CustDevOps. La diferencia con BizDevOps desde nuestro punto de vista es que no tenemos el negocio en mente, sino el cliente, y que esto debe ser parte del término empleado: Desde el negocio (Biz) dirigimos el foco lejos del cliente (Cust). Los resultados de nuestros Design Sprint proporcionan historias de usuario muy valiosas y validadas para el desarrollo. La estrecha colaboración con el cliente en la fase de desarrollo y el estrecho apoyo en la producción dan lugar a la creación de un producto validado que ahorra recursos y valora a las personas y su trabajo. No se crea nada superfluo. Todo parece ser casi mágico. Teóricamente. Pero atención, trabajamos con personas y con tecnologías y, por último, pero no por ello menos importante, con métodos. El equipo debe encajar en esta forma de trabajar y vivirla y amarla al cien por cien. El equipo debe actuar como un equipo. Y el cliente también debe verse a sí mismo como parte del equipo. Los éxitos deben ser celebrados y los errores deben ser corregidos y aprendidos. ¡Hay mucho por hacer! Pero es factible y tú puedes abordarlo como nosotros. Los resultados son prometedores.

Escrito por José Díaz, CEO de trendig technology services. trendig — get your best ideas with us!

--

--

trendig blog — get your best ideas with us!
trendig blog — get your best ideas with us!

Published in trendig blog — get your best ideas with us!

trendig's team and partners blog about software development, software testing, agile practices and innovation. trendig — get your best ideas with us!

trendig
trendig

Written by trendig

We set trends and design digitalization through innovation, engineering, knowledge & events. 🔎 get your best ideas with us! 💡 trendig.com