¿Cómo evitan los conflictos los gerentes de producto y los programadores?

1. Las tres frases más molestas entre gerentes de producto y programadores

Los gerentes de producto y programadores son como una pareja de amantes, que son inseparables y, a veces, incluso se separan. Cuando están en paz, todo está bien, pero cuando están en conflicto, todo está perdido.

¿Sabes cuáles son las tres frases que más molestan a los programadores?

1. Este requisito es muy simple, simplemente cámbielo.

2. Probablemente deberías conseguir uno primero y dejarme echarle un vistazo.

3. Saldré del trabajo primero. Vamos.

Creo que cualquier programador se pondría furioso al escuchar tales palabras. Sería extraño no destrozarlo. Como programador, ¿cómo responderías a estas tres frases?

1. ¿Es este requisito sencillo? Puedes hacerlo. ¡vamos!

2. ¿Quizás comprar uno primero? Por favor señor (señora), ¿cuánto es aproximadamente?

3. De tu tío

¿Sabes qué es lo que más odian los product managers?

1. Este requisito no se puede cumplir.

2. La demanda es demasiado alta y se estima que tardará tres meses.

3. No tengo tiempo para hacer este cambio. Arreglémoslo más tarde.

El gerente de producto está al frente, con los usuarios, los jefes y las ventas, por lo que hay mucha presión sobre los lanzamientos de versiones. Probablemente no se sintió mucho mejor después de escuchar esto.

1. ¿No se puede cumplir este requisito? No lo mencioné, ni tampoco el usuario de 2B.

2. ¿Tarda tanto? ¿De qué sirve criarte? También podría hacerlo yo mismo.

3. ¿No tienes tiempo para hacer cambios? Pase lo que pase, espera a que el jefe te tome una foto.

2. ¿Cuál es la diferencia esencial entre product managers y programadores?

Papá ha trabajado como programador y gerente de producto. Conoce la diferencia entre los dos trabajos y que cada uno tiene sus propias dificultades.

En términos generales, la fabricación de productos presta más atención a la creatividad y las capacidades de la solución, y no requiere una lógica precisa, por lo que el costo de prueba y error es relativamente bajo y también es asequible cambiar prototipos y soluciones.

El trabajo de un programador es una lógica muy precisa. Un cambio aparentemente pequeño puede tener un gran impacto en el código, por lo que el coste de prueba y error es alto. Si no se hace bien, los cambios en los requisitos pueden llevar a la reconfiguración del sistema. Se puede imaginar la frustración de los programadores en este momento.

En tercer lugar, una lista de relaciones amistosas entre gerentes de producto y programadores.

1 Después de que el gerente de producto recopila los requisitos, durante la etapa de análisis de requisitos, debe intentar eliminar algunos requisitos irrazonables. Comunicarse con los usuarios para evitar retrasos en el lanzamiento del producto y desperdicio de costos innecesarios causado por demandas irrazonables. Por supuesto, esto requiere que los gerentes de producto convenzan a los usuarios, no solo que sean sus portavoces.

2. Al analizar las necesidades, los gerentes de producto deben descubrir con atención algunos requisitos que son difíciles de lograr a nivel técnico según su propia experiencia, dejar que I + D intervenga a tiempo, evaluar la viabilidad técnica y evitar necesidades fijas posteriores. , I+D Habla de cosas que no se pueden hacer.

Por supuesto, esto requiere que nuestros gerentes de producto tengan cierta comprensión y capacidad de predicción de la arquitectura de la tecnología de software. Es imposible para usted involucrar I + D en todos los requisitos durante la etapa de análisis de requisitos, y el costo es extremadamente alto, por lo que obtener este título también es un tipo de habilidad.

3. Los prototipos son la mejor manera de comunicar los requisitos y evitar diferencias en la comprensión de los requisitos entre productos e I+D. Es difícil lograr buenos resultados simplemente escribiendo algunas especificaciones de requisitos por escrito.

Sin embargo, cabe señalar que los prototipos elaborados por los gerentes de producto generalmente no son prototipos de alta fidelidad para mejorar las necesidades de comunicación, por lo que no pueden basarse completamente en los prototipos y deben basarse en los nuestros. Arquitectura front-end para personalizar.

4. Durante la revisión de requisitos, I+D puede tener opiniones diferentes. Después de años de desarrollo, tendrán mucha buena experiencia. Las buenas experiencias deben aceptarse con la mente abierta. No puedes pensar que eres el jefe del producto y simplemente hacer lo que te digo. De esta manera, es fácil crear conflictos, buscar puntos en común reservando las diferencias y lograr el mismo objetivo por caminos diferentes. Este es el mejor resultado.

5. Cuando I+D dice que este requisito no se puede cumplir, se dan dos situaciones. Una es que es problemático cumplir este requisito y él te engaña deliberadamente; la otra es que tiene un punto ciego en el conocimiento y es posible que realmente no sepa si puede hacerlo;

Los gerentes de producto deben poder negociar con I+D, por ejemplo utilizando analogías (hemos impuesto requisitos similares en otros proyectos), como acudir a arquitectos para discutir la viabilidad técnica.

6. La I+D a veces implica mucho trabajo y todo el plan online lleva mucho tiempo.

Los gerentes de producto pueden solicitar una lista detallada de asignaciones de recursos, de modo que podamos ver claramente en cuántas tareas de I+D se divide un requisito y quién es responsable del tiempo de inicio y finalización de cada tarea. De esta manera, el gerente de producto probablemente podrá ver si el contexto de las tareas es razonable. Si la carga de trabajo es razonable, etc.

El responsable de producto no debe decir que llevará tanto tiempo hacerlo tan sencillo. Si algo como esto sucede, definitivamente enojará a la otra parte, por lo que aún debemos negociar de manera racional.

Si es imposible reducir la carga de trabajo y si agregar mano de obra puede resolver el problema, puedes considerar solicitar recursos al líder. Si eso aún no funciona, es necesario reducir la demanda o cambiar los planes.

7. Cuando se determine el plan de versión, trate de no agregar requisitos, ya que esto fácilmente alterará el ritmo de desarrollo. Si debe agregarlo, debe dejar claro a I+D que este es un requisito obligatorio para que los líderes o jefes de usuarios transfieran conflictos. Si es posible, aumente la demanda y retrase los planes de implementación tanto como sea posible.

8. Si los requisitos cambian durante el proceso de desarrollo, el documento de requisitos debe actualizarse a tiempo y enviarse a nuestros compañeros de I + D. De lo contrario, lo más probable es que los compañeros de I+D no lo hagan, por lo que hay que anotarlo en un papel.

9. Insista en trabajar horas extras con colegas de I + D cuando esté en línea, para que todos sean un equipo, ganando y perdiendo juntos.

10. El último punto es comunicar más. No hay problema que una comida caliente no pueda resolver. Todos tienen una buena relación. Naturalmente, será más fácil comunicarse sobre muchas cosas y confiarán más el uno en el otro, por lo que todo estará bien.