Más de 50 revisiones de problemas comunes de gestión de proyectos (medio)

antecedentes

Si sus requisitos se han retrasado, si la calidad de la entrega no es buena y si el contenido por el que ha trabajado duro se está rectificando indefinidamente, cada uno parece ser un problema humano, pero en realidad es un problema de gestión de proyectos, un problema de cognición insuficiente.

Hay tres artículos en esta serie: primero, medio y segundo.

Mesa de inducción

Fenómeno razón Acción (método de mejora)
Después del desarrollo y la entrega, las pruebas o el producto, se presentan requisitos más detallados y luego se requiere que se implementen, y todos estos son necesarios. 1. El equipo en su conjunto no tiene suficiente control sobre la revisión de requisitos 2. Los requisitos del producto no se entienden completamente 1 Durante la revisión, se requiere que para revisiones importantes, el TL del producto y el TL técnico controlen los detalles, extraigan los detalles y determinen el contenido de los detalles.2 Antes de que el producto entre en la etapa de investigación y desarrollo, el equipo de producción e investigación debe hacer suficientes subdivisiones de demanda y detallar los detalles por adelantado.Perfecto 3 De acuerdo con los detalles de los requisitos, se divide en tres, seis, nueve, etc., y el contenido sin importancia irá a iteraciones posteriores
El efecto de entrega de I+D no es bueno, pero el efecto no es bueno o no es lo suficientemente detallado 1. El efecto no es el esperado 2. El departamento técnico no está en su lugar  1 Para las necesidades a lograr dar los posibles resultados de la solución técnica 2 Para los resultados listar los pros y los contras para ver si la parte aceptante la acepta
La investigación y el desarrollo han realizado un tipo de producto, el producto piensa que esto no es bueno, esto no está bien 1 Espera la diferencia 1 Alinear el consenso, además de las iteraciones diarias, los productos y las tecnologías deben reunirse con frecuencia para resolver algunos problemas comunes de consenso, sobre qué tipo de demanda se puede lograr, en qué medida y qué defectos serán (no se pueden resolver en el corto plazo o debe resolverse solo a través de la investigación) de)
Una vez entregada la I+D, se proponen los requisitos derivados que se realizarán en esta iteración. 1 Es un requisito que no está relacionado con este tiempo 2 Está relacionado con este tiempo pero es opcional 3 Está relacionado con este tiempo y debe ser el soporte subyacente 1 No lo haga 2 No lo haga, colóquelo en la siguiente iteración 3 Esta iteración se pospone o la movilización de recursos se completa (Nota: no importa cuál, debe hacer una revisión por el motivo)
La calidad de la prueba no es alta. 1 Consideración incompleta de los casos de uso 2 Ciclo de prueba insuficiente 3 La calidad de I+D es realmente problemática 1 Agregar casos de prueba perfectos 2 Evaluar el ciclo de prueba adecuado en función de la experiencia iterativa, siempre que sea posible para garantizar la calidad
Problemas frecuentes en línea 1 Datos sucios 2 Protección lógica 3 Casos de prueba incompletos durante el período de prueba 4 Datos históricos 1 Análisis regular de datos en línea 2 Para excepciones, protección de datos, protección de acceso 3 Mejorar los casos de prueba, especialmente los datos en el entorno previo al lanzamiento se pueden simular pruebas de función Copiar irregularmente datos en línea a fuera de línea)
La eficiencia de depuración conjunta de front-end y back-end es baja 1. El documento de la interfaz y los datos simulados no están definidos de antemano 2. El front-end no está familiarizado con el negocio y el uso de la interfaz. 1. Tanto el front-end como el back-end deben ser sensibles a los datos 2. Tanto el front-end como el back-end deben ser sensibles a las páginas y las interacciones 3. Tanto el front-end como el back-end deben ser sensibles al negocio, e implementar la lógica y tener una comprensión clara del impacto de cada interfaz.
La parte delantera está suelta y apretada. 1 El front-end es principalmente el front-end, y es posible que no haya una depuración real de la interfaz durante el ciclo de desarrollo de la interfaz de usuario, y algunos procesos no pueden realizar el enlace dinámico. 1 El front-end debe comunicarse con el back-end para proporcionar documentos de interfaz y datos simulados por adelantado, de modo que, al menos en la etapa inicial, se pueda lograr la estabilidad del uso de la estructura de datos y el código correcto puede ser escrito para la parte comercial, también se recomienda que si la ui está completa, se puede hacer primero.
La parte trasera está apretada y suelta. 1. El front-end y back-loose son principalmente el back-end, la etapa inicial es el sistema, el diseño y la implementación de la interfaz, pero después de que la interfaz se prueba una sola vez, se sienta y espera la depuración conjunta, y espera a que el front-end responda el problema. 1 El back-end debe considerarse en combinación con el producto y proporcionar un método de llamada amigable y una estructura de llamada para el front-end. Después de que el front-end complete algunas funciones, puede ayudar al front-end a completar la prueba juntos. de simplemente esperar a que intervenga su propio error de back-end; otro punto es muy importante, además de garantizar el humo de una sola interfaz, el backend puede garantizar la fluidez del enlace de la interfaz en términos de capacidades, como realizar un pedido , al seleccionar un producto, agregar un carrito de compras, realizar un pedido y pagar varias llamadas consecutivas de varias interfaces, el backend está preimplementado La interfaz relevante es estable y está disponible
Se requiere perfección, y se requiere restauración a nivel de píxeles en ui; y la función es consistente con un determinado producto 1 Exigir ciegamente la perfección 2 Plagiar tanto como sea posible 1. Obtenga más información sobre dónde se encuentran las capacidades del equipo. 2. El plagio es deseable, pero no es necesario copiar cada detalle. Piense claramente en las partes importantes. Repita y pula los detalles lo suficientemente bien.
No hay correlación antes y después de la iteración. El producto no está planeado 1 Hacer una planificación trimestral 2 Cada iteración cumple con la planificación trimestral y los objetivos generales
Un requisito similar se modifica repetidamente 1 No supe qué hacer 2 Después de prueba y error, no sé cómo volver a jugar 1 Hacer más estudios de mercado sobre productos competitivos 2 Para cada iteración, debe haber indicadores para medir la calidad, el efecto y los beneficios de esta iteración 
El descubrimiento en las etapas media y tardía de I + D no se puede realizar. Capacidad de evaluación insuficiente 1 邀请大佬参与评审,确定错误边界,能力边界,周期2 做技术细分,评价风险点,如果实现不了,思考相应的替代方案3 每一次有问题的迭代都去复盘,最终有没有实现,如何实现的,实现的缺陷在哪里4 后续思考,还有没有可能倒退,当时还可以如何讨论这个需求
需求责任扯皮 责任边界不清楚 1 每个人负责什么,不可以做什么,明确清楚 2 敏捷,敏捷教练参与
具体需求的具体研发时间与评估有出入 1 不够细化  如果出入很大,一定要针对不确定工时的需求做足够的细分,可以不出完整的成果,但要有相应的原因列表,采坑列表 ,方案列表
技术系分做了没用 1 有能力没经验 2 超出能力 3 不会系分 1 提供模板2 提供优秀的案例,是如何通过系分解决的3 提供优质的资源,带领团队实现系分,而不是坐等
偶现问题 1 常规研发对交互对数据不敏感 2 没有监控机制  1 提供前后端的监控体制2 有完整的链路在具有监控数据后复现场景
多人协作,某些思想不一致 团队磨合 1 敏捷培训 2 求同存异 

原文

Supongo que te gusta

Origin juejin.im/post/7087128224328597511
Recomendado
Clasificación