Lean Product Development, LPD, se está convirtiendo gradualmente en una metodología estándar en el desarrollo de software de la misma manera que el ágil, el scrum y el lean se han convertido en estándares de la industria.

Si tiene aplicaciones de software como parte de su cartera de servicios o directamente a los clientes y utiliza metodologías LPD, es importante integrar completamente su equipo de desarrollo. Pero, si está utilizando un servicio de outsourcing, ¿Qué debería esperar? ¿Qué tan importante es integrar su equipo externo?

Un pequeño nivel de ajuste

En el pensamiento estricto, aunque el término “LPD” se utiliza intercambiablemente para el diseño y el desarrollo, hay algunas diferencias en foco entre los dos en la puesta en práctica. Ambos se basan en Lean, los principios que se iniciaron con Toyota Manufacturing han evolucionado para abarcar un un proceso de búsqueda de soluciones a los problemas de los clientes que enfatiza la iteración, la reducción de residuos y la reducción de riesgos. En términos generales, ambos son basados en la Metodología Lean Startup, pero debido a que LPD ha sido adoptada por muchas organizaciones grandes para el desarrollo de líneas de servicios y productos, las lecciones de Lean Startup se reducen al nivel del producto, Son para las startups. Y, debido a que estamos específicamente interesados ​​en el desarrollo de servicios, software y software, en vez de fabricar y desarrollar productos físicos, podemos incluir el hecho de que todas las implementaciones LPD favorecen el uso de ágil, scrum y kanban como metodologías de desarrollo.

Las implementaciones de Lean Product Development tienden a centrarse en las características necesarias para satisfacer las necesidades de los usuarios y las metas del producto. Por lo tanto, aunque ambas implementaciones utilizarán técnicas ágiles de historias de usuarios, las implementaciones basadas en diseño se ubicarán más en el contexto de la interfaz de usuario y la experiencia del usuario. Las implementaciones de desarrollo se centrarán más en grupos de características y objetivos de usuario. En la práctica, las diferencias entre los dos son relativamente pequeñas y dependen más del equipo completo del proyecto y su proceso que nada. Un equipo de desarrollo con clientes que tienden a ser más visuales e inseguros respecto de las necesidades del producto puede ser más fácil ser centrado en el diseño. Un equipo con clientes que trabajan en un proceso de negocios  en donde los usuarios cuentan con opiniones fuertes e informadas pueden encontrar más fácil estar más centrado en el desarrollo. Y ciertamente, hay muchas mezclas de las dos maneras de pensar.

¿Entonces, qué significa esto?

Hay muchas aplicaciones de software que incorporan procesos y principios desde el punto de vista de la gestión de productos de software. ¿Cómo trabajarán para usted si decide utilizar una compañía de desarrollo de software externo para ayudar a llevar su aplicación al mercado? ¿Es uno o el otro mejor para las aplicaciones de software o la integración con los equipos de desarrollo de software? ¿Existen metodologías o puntos a enfatizar con las compañías de desarrollo potenciales a discutir cómo su enfoque de desarrollo de productos y experiencia?

Desde un nivel alto, si su proveedor potencial tiene una buena experiencia en el desarrollo de productos, entiende completamente el ciclo de desarrollo, el software que utiliza para la gestión de productos y la implementación de metodologías agiles que utilizan en su proceso de desarrollo de software no debería importar mucho. Deben ser capaces de ser flexibles y hacer lo necesario para integrar a los equipos. Si están usando algo de un libro o un seminario que realmente han practicado unas pocas veces con un cliente – y que el cliente no estaba totalmente comprometido con la gestión formal de productos – será un desafío que distrae a ambos equipos mientras desarrolla su aplicación.

5 preguntas para su socio tecnológico potencial

Empecemos con algunas preguntas. Es recomendable no hacer preguntas en las cuales su respuesta sea sí o no. Mejor, haga preguntas abiertas que deben ser contestadas con más de unas pocas palabras (si realmente tienen experiencia y servicios formales alrededor del área que están hablando). Si no consigue lo que siente es una respuesta fuerte, otra vez, haga las preguntas que crea necesarias para esclarecer todas sus dudas al respecto.

¿Cómo implementan la metodología ágil en proyectos con clientes que practican Lean Product Development?

La pregunta aquí no es “¿se utiliza metodología ágil?” sino como es que se acoplaría su forma de trabajo con las empresas que practican LPD y qué valor creen que su forma de trabajo aporta a sus clientes. También deben incluir sus prácticas dentro de ágil, como scrum, programación extrema (XP), o kanban. Si no entran en este nivel, haga otra pregunta abierta para más detalles.

En la mayoría de los casos, el scrum será la guía de administración de tareas y de desarrollo básico, pero puede extenderse por las prácticas de XP. Algunos equipos estarán familiarizados con kanban y algunos mencionarán que podrían comenzar con scrum y transición a kanban si el proyecto usa una implementación dirigida al desarrollo continuo. En un nivel alto, la elección entre scrum y kanban se reduce a una filosofía sobre el trabajo y cómo administrar las tareas. Scrum se considera generalmente más estructurado, usando iteraciones de tiempo (sprints) y dependiendo del equipo para estimar apropiadamente las tareas para cada sprint y con la planificación específica y las sesiones retrospectivas para manejar el backlog y las prioridades de la tarea. Kanban tiende a limitar el número de tareas que un equipo puede tener en el trabajo al mismo tiempo y nuevas tareas se reducen al desarrollo tan pronto como una ranura se abre en la cola. Kanban es generalmente más flexible para la inserción de nuevas características y menos estructurado, requiriendo más administración de funciones para evitar la fluencia antes de que se complete la aplicación base.

Es sólo una pauta, pero la mayoría de los equipos encuentran que el scrum es un buen sistema en el desarrollo de aplicaciones y puede usar kanban o una variación después de la liberación completa cuando la aplicación está en mantenimiento o desarrollo continuo. Una vez más, la familiaridad del equipo y la experiencia en el ajuste de su “estándar” de implementación a su equipo es más importante que el sabor particular de la metodología que están utilizando. Las maquetas de proceso y los paso a paso del flujo de información y retroalimentación entre los equipos son una excelente manera de evaluar cómo funcionan las cosas y la facilidad adaptarse a las situaciones que se presenten.

¿Cómo es el proceso de un MVP en el desarrollo de productos lean?

El desarrollo iterativo de un producto mínimo viable (MVP por sus siglas en inglés) es crítico en LPD y probablemente una de las partes menos entendidas del ciclo por no practicantes. También es muy difícil estimar el esfuerzo y el tiempo para el equipo de desarrollo porque involucra un proceso abierto con los principales interesados ​​y usuarios. La cuestión clave es entender lo que esperan y cómo lo ayudarán a hacer iteraciones viables para su validación.

Este es un elemento de su trabajo como un equipo completo en el que realmente puede evaluar la capacidad de su equipo de outsourcing para trabajar plenamente como un socio en el desarrollo de productos. ¿Pueden encontrar maneras creativas de dar una buena representación del producto principal a los usuarios con menos esfuerzo y tiempo? ¿Pueden ver la evolución de las ideas y seleccionar elementos clave en la retroalimentación de los clientes? Si usted espera o tiene que micro-administrar cada iteración usted mismo, no está recibiendo un equipo de desarrollo de software totalmente preparado.

¿Cómo capturaremos y gestionaremos la retroalimentación de los usuarios durante la validación y la publicación inicial?

Ahora bien, un desarrollador podría simplemente decir: “Este es tu problema, no el mío”. Hasta cierto punto, estarían en lo cierto, pero buscas respuestas a nivel de socios que indiquen la voluntad de hacer lo que sea necesario para hacer que el proceso de desarrollo del producto funcione correctamente y para estar en posición a largo plazo si su producto es probable que se beneficien de un desarrollo continuo. Las posibles respuestas pueden estar presentes en todos los servicios adicionales que soportan el servicio de ayuda y la retroalimentación de la aplicación a los módulos personalizados integrados en la aplicación.

Una vez más, lo que está buscando no es una respuesta específica, sino que la compañía que está evaluando para el desarrollo de su producto, esté dispuesta y sea capaz de entender lo que necesita desde una perspectiva de producto y proporcionar soluciones creativas.

¿Cuáles son nuestras opciones para capturar las métricas de usuario?

Este requisito es, por supuesto, muy similar a la captura de comentarios de los usuarios, por lo que las soluciones pueden ir desde informes personalizados dentro de la aplicación a servicios de terceros y bibliotecas de aplicaciones. En este caso, la riqueza de las opciones es clave para que pueda evaluar diferentes aspectos de la adquisición del cliente, el uso de la característica, el tiempo para completar un proceso, etc. Estas características no existen en aplicaciones “promedio”, pero se pueden agregar con relativa facilidad durante el desarrollo, especialmente si se compara el esfuerzo requerido para agregarlos en algún punto posterior. Tendrá que entrar en detalles sobre los tipos de métricas que considere más útiles para su aplicación y su situación, pero un equipo de desarrolladores fuerte debe ser capaz de darle un rango de opciones para la implementación y algún tipo de panel para generar informes.

¿Qué hace usted para asegurar que los problemas de calidad no se interpongan en el camino?

Puede parecer un poco fuera de lugar para discutir la calidad en un conjunto de preguntas enfocadas a LPD, pero la calidad es uno de los mayores problemas cuando se trata de retrasos inesperados del proyecto. No se puede esperar que las partes interesadas y los usuarios participen plenamente en el proceso de desarrollo de productos si las entregas planeadas se retrasan o si las características principales no aparecen completamente conformes como se prometió. Una aplicación muy buena que es inestable o tiene una interfaz de usuario mal diseñada es una gran distracción de los objetivos del proyecto LPD.

Las mejores respuestas a esta pregunta incluyen el desarrollo impulsado por pruebas, la automatización de pruebas, la integración continua y las herramientas que eventualmente podrían entrar en juego si decides entrar en un desarrollo continuo. El mejor caso es tomar esta decisión por adelantado, pero las cosas no siempre funcionan de esa manera. Su principal objetivo debe ser asegurarse de que está en posición de moverse a ese nivel cuando sea necesario sin retroceder o tener menos de la cobertura de la prueba completa y para aprovechar las herramientas de aseguramiento de la calidad y los procesos de manera proactiva desde el principio.

Las respuestas a esta pregunta deben abarcar muchos de los temas de cómo los equipos trabajarán y se comunicarán. Si no lo hacen, empuje las preguntas en esa dirección específicamente. Si ha leído algo acerca de la subcontratación, ya sabe que los equipos ágiles exitosos requieren un fuerte diálogo abierto y colaboración. Entender plenamente cómo su proyecto se ocupará de la calidad, la comunicación y la propiedad de las metas del proyecto.

Hay muchas más preguntas que puedes hacer, pero estas deberían empezar. El punto es tener una conversación con su proveedor potencial y llegar a una comprensión de las metodologías que han utilizado, las capacidades que traen a la mesa, y la experiencia como cliente que puede esperar. Una conversación puede aclarar muchos más problemas que una respuesta escrita y le dará una idea mejor si se trata de un grupo con el que puede ver a su equipo trabajando. Si realmente está buscando un socio a largo plazo y no sólo un equipo para un compromiso corto, sería sabio tener esa conversación en persona – en sus oficinas o la suya. Si requiere algunos viajes, es sólo una parte del gasto de encontrar un buen partido. Es mucho mejor tener sus primeras reuniones cara a cara en un ambiente positivo y con visión de futuro que cuando un proyecto está en marcha y usted se ha dado cuenta de que hay mucho que hacer para resolver los problemas.

En Scio proveemos servicios de desarrollo de software, a nuestros clientes en Norteamérica. Nuestros equipos cuentan con amplia experiencia en Lean Product Development. Utilizamos metodologías ágiles y las adaptamos a la situación y necesidades de cada uno de nuestros clientes. Si estás en busca de un socio tecnológico para su organización para crear un gran conjunto de nuevos productos, ponte en contacto con nosotros. Estaremos encantados de tomar hablar sobre tus necesidades.