Algunas reflexiones sobre la implementación del pensamiento lean en el desarrollo de software bancario
En comparación con la industria manufacturera, el desarrollo de software tiene sus propias características únicas. El "pensamiento Lean" se sitúa en el nivel metodológico y práctico y requiere adaptaciones específicas.
Las diferencias entre el desarrollo de productos de software y el desarrollo de productos de fabricación se pueden clasificar en: 1) incertidumbre de valor; 2) incertidumbre de proceso; La incertidumbre del valor se refleja en: 1) el valor del cliente en sí es incierto, no se puede definir con precisión desde el principio y está evolucionando en cualquier momento; 2) la industria está experimentando rápidos cambios e incertidumbre; La esencia reflejada en las diversas incertidumbres anteriores se puede resumir en un punto, es decir, el "cambio" es un tema central del desarrollo de software, lo que determina que el desarrollo de software eficiente debe resaltar las "capacidades de iteración" y el modelo organizacional debe ser más plano. . En cuanto a la incertidumbre del proceso de desarrollo de software, se refleja en el hecho de que el proceso de desarrollo de cada proyecto de software es hasta cierto punto un proceso creativo, en el que una cantidad considerable de detalles de trabajo específicos no se pueden determinar con precisión de antemano. Es uno de los valores fundamentales de los ingenieros de desarrollo de software.
El pensamiento Lean, cuando se aplica a proyectos de desarrollo de software, consiste en hacer que el éxito empresarial sea el único criterio para probar proyectos de software.
El pensamiento Lean enfatiza la producción pull, es decir, la extracción de valor para el usuario. Es necesario garantizar la transmisión oportuna, precisa y eficiente de las necesidades posteriores a los enlaces de producción upstream. No solo permite que el valor fluya. Hay que garantizar que lo que fluye es el valor deseado por los usuarios. La mejor manera de hacerlo es dejar que el valor del cliente más intermedio (como los pedidos de los usuarios) impulse todo el flujo de valor. ——En relación con la producción de tecnología de la información bancaria, es necesario que el desarrollo de la tecnología de la información y otros trabajos estén impulsados directamente por las necesidades de productos y servicios de los usuarios; aquí, las "necesidades del usuario" y las "necesidades del departamento comercial" son; be Para distinguir, usuarios se refieren a los usuarios finales del banco (públicos y privados).
¿Por qué el trabajo de tecnología de la información bancaria siempre es propenso a caer en una función de soporte de back-end en todo el sistema operativo del banco? Una de las razones fundamentales es que el Departamento de Tecnología de la Información carece de percepción directa del valor para el usuario. Las llamadas necesidades de respuesta del departamento de tecnología responden enteramente a las ideas del departamento comercial. No participan en absoluto y no son responsables de la realización y el flujo del valor para el usuario final.
Esto no puede ser cambiado por el Ministerio de Tecnología de la Información por sí solo.
Por supuesto, el departamento comercial también está muy agraviado. Han estado trabajando muy duro para responder al mercado, captar las necesidades de los clientes y están haciendo todo lo posible para refinar las necesidades y transmitirlas a la tecnología. departamento y promover activamente el departamento de tecnología para rápidamente Otro buen sistema de entrega bajo demanda. Además, para satisfacer la demanda del mercado de la manera más eficaz, la necesidad y la importancia del departamento comercial como vínculo de primera línea son incuestionables.
¿Cuál es el problema? ?
Esto se debe a que la estructura bancaria tradicional determina que el departamento de tecnología está aislado detrás del departamento comercial y no tiene que contactar directamente las necesidades de los usuarios de primera mano, y mucho menos participar directamente en escenarios de entrega de valor al usuario. .
Como señaló He Mian en el artículo "Primeros principios e implementación escalada de Lean and Agile", el patrón de estructura organizacional determinará el patrón de flujo de valor. Por lo tanto, desde la fuente del modelo de estructura organizacional, se deben hacer arreglos generales en función de las necesidades de valor del usuario. Se debe cambiar el orden y la relación entre el departamento comercial y el departamento de tecnología de la información. El departamento de tecnología no debe ser responsable del departamento comercial, y el departamento comercial no debe ser el aceptador final del sistema y no debe ser el único responsable de él. el efecto de mercado final del sistema. El departamento de tecnología y el departamento de negocios deben ser miembros del equipo ágil y actuar como consultores entre sí. El departamento de tecnología es el consultor técnico para el diseño empresarial y el departamento de negocios es el negocio. Consultor del departamento de tecnología. Ambas partes deben trabajar juntas para contribuir directamente al valor del usuario. Asumir la responsabilidad de los resultados finales.
El éxito empresarial (puede pasar de un pequeño éxito a un gran éxito, de un éxito simple a un éxito complejo y sistemático) es el único criterio para probar y aceptar proyectos. Si hay un rol de coordinador, es el de gerente de producto (o gerente de proyecto del equipo ágil).
Extracto 1. Comprender los tres niveles del pensamiento lean: valores, metodología y conjunto de prácticas.
Valores: El "Toyota Way" de 16 páginas "Toyota Way – 2001" publicado en 2001. Afirma que el respeto por las personas y la mejora continua son el núcleo de los valores Lean. Estos dos temas incluyen cinco valores, que son: desafiar el status quo, superación y genchi genbutsu para la mejora continua y el respeto a las personas: respeto y trabajo en equipo; "No cause problemas a los clientes": el siguiente eslabón de la producción es también su propio cliente.
Metodología: "Lean Thinking" resume los cinco principios de Lean, que son también cinco pasos de implementación.
Conjunto de prácticas: desde los valores hasta el conjunto de prácticas, su operatividad es cada vez más fuerte. Al mismo tiempo, las características de la industria son cada vez más fuertes y su versatilidad es cada vez menor. En lo que respecta al TPS de fabricación ajustada de Toyota, sus diversos métodos prácticos exitosos incluyen Kanban (una herramienta importante para respaldar el justo a tiempo), "cambio de molde en un minuto", etc.
Extracto 2. La diferencia entre desarrollo de producto y fabricación de producto:
Extracto 3. Objetivos, metodologías y prácticas del desarrollo de producto Lean:
Objetivo: Suave, valor útil y de alta calidad
Método: explorar y descubrir valor útil, dejar que el valor fluya sin problemas; centrarse en mejorar la eficiencia del flujo de valor
Ohno se centra en el valor para el usuario y en Proceso de flujo de valor. El llamado desperdicio se refiere a todos los comportamientos y esperas sin sentido desde la perspectiva del usuario. Esto es consistente con la afirmación de Drucker de que "el desempeño de cualquier organización sólo puede reflejarse externamente. Esta idea también se aplica al desarrollo de productos".
Centrarse y mejorar la eficiencia del flujo de valor es el principio del desarrollo de productos lean, y también es otra diferencia esencial entre el desarrollo de productos lean y los métodos de desarrollo tradicionales.
Práctica: Dividida en práctica de gestión y práctica técnica.
La primera parte de la práctica de gestión es Lean Startup and Innovation Practice, que resuelve los problemas de descubrir, validar y explorar valor. La segunda parte es la práctica de gestión y análisis de requisitos lean, que resuelve el problema de cómo dividir, planificar, analizar y comunicar los requisitos de manera efectiva. La tercera parte es la práctica del método Lean Kanban.
La práctica técnica se puede desarrollar en torno a DevOps.
Extracto adjunto 4. Auto-卍
1. 卍, la palabra junto al carácter humano, significa auto-卍. La automatización es la base de "Build Quality In", que se basa en cada enlace para garantizar la calidad, en lugar de depender del enlace de prueba final.
2. Puntualidad y autoservicio son unidades contradictorias.
Extracto 5. La intención original de la metodología ágil
Es importante no olvidar la intención original y recordar los objetivos comerciales de la metodología ágil: entregar valor antes y responder a los cambios de manera más flexible.
Extracto 6. La paradoja del software tradicional
Las decisiones más importantes se toman cuando el conocimiento es menos suficiente y se utilizan como punto de referencia para el resto. Esta es la paradoja entre la acumulación de conocimiento. y el tiempo para la toma de decisiones en el desarrollo tradicional.
El proceso en sí tiende a complicarse y se suprime la iniciativa de personas que son muy importantes para el desarrollo de software.