在我刚来团队那会儿，服务端的开发方式很少以项目的方式推进，可能同时对接多个PD，需求显得零散，没有整体的节奏感，且在团队内部不透明，从15年下半年开始，产品需求以单个月为时间节点统一管理，客户端发布节奏控制在每个月一个新版本，上个月我作为PM负责服务端开发的项目推进（轮岗）。
一、以下是项目开展期间遇到的一些问题：
1. 产品方案未细化 ： 前期考虑不完善、产品部分功能对应后台未提及、做了一半的需求被终止、运营需求未进行产品化
2. 改需求加需求 ：沟通不充分，运营策略临时改动，进入预发测试之后还在改产品细节
3. 前端资源节奏不匹配 ：部分功能需要和前端对接，但前端资源投入过晚
4. 时间评估偏少 ：直播技术方案，细节和交互规则多方多次确认，实际耗时更长
5. 依赖方环境不够稳定 ：算法接入环境不稳定增加额外的联调成本
6. 上个月遗留需求 ：实际遗留需求额外工作量比想象的多，无人跟进整理
7. 穿插项目期间的线上问题排查 ：新引入或者历史原因遗留的bug修复优先级问题
8. 项目管理工具没有被用起来 : 只在项目初期罗列了拆解的任务，中间需求变更和新增时被绕过， 项目进入开发后需求情况开始变得不透明
9. 视觉稿影响方案设计：开发阶段以交互稿为参考，但视觉稿出来之后，又新增了改动点，导致设计方案重新考虑
没有包含服务端测试和客户端测试部分，可能还有一些遗漏的地方。
二、以上列举的这些情况，可以抽象地分为几类：
1、根据分工不同，在不同角色进行配合时，分工角色没有充分做好本职工作，导致产品需求或者技术需求没有被充分表达，导致方案在后期不断变更，增加沟通成本，时间成本，频繁修改重新设计，引起参与者的不满情绪
2、不可靠的依赖方，未建立强有力的有效推进机制，表现在两方面，一是合作方互相信息不互通，问题没有及时感知和快速解决，二是前期规则没有定义清楚，导致各方推进节奏不一致，无法及时获取反馈，甚至互相阻塞，耽误时间
3、部分风险点在项目前期讨论被忽视，导致后期时间排期紧张，部分风险点在项目开展过程中产生，但没有被纳入管理，也没有被透明化出来，不断积累项目风险，部分风险点被转移到下一个版本
从整个项目周期来看，每个阶段都有可能遇到问题，有些是人为，有些似乎不可避免，由此也引出一个思考点，项目管理到底是在管什么？
产品需求从提出到落地，主要涉及的角色包括产品、交互视觉、前端、客户端、服务端、测试，项目管理在其中最大的作用，用一句话就是，保证需求在每个环节以可靠的方式被正确地传递和表达。
a. 这首先要求每个环节的参与者都明确地知道自己所承担的职责，清楚每个时间点应该做些什么，参与者要有相应的能力，不能成为整个链路的短板和风险点
b. 其次是在进行需求对接时，各方需要进行充分的沟通，确保需求在前期就考虑完善，明确清晰，且被准确传达，防止后期不断修改，少做无用功
c. 再者是在项目推进中需要有高效的问题解决机制，能快速地发现问题和解决问题，避免风险点积累导致项目不可控
三、本次项目的几个改进方向
1、项目排期的时候，有些细节点未考虑周全不可避免，但是可以尽量减少这部分风险，如更完善的产品方案，在部分产品需求点的细化，其实是被后移至开发阶段的，需要减少这种情况的发生；
2、项目开发中，产品在加需求和改需求的同时，需要考虑重新梳理需求的优先级，砍掉一部分优先级较低的需求，否则项目风险会不断增加，并且这些多出来的工作量，像在本次项目中，都是靠开发同学加班加点赶出来的；
3、基于430项目中出现的以上几点情况，后续项目中都需要考虑到，至少预留一定的时间，还可以每天进行一个简短的会议明确要解决的问题，建立相应的沟通项目群；
补充：有哪些时间是被浪费的，有哪些返工是可以避免的，有哪些节奏是可以配合得更好的，有哪些方法可以兼顾灵活性减少无用功，有哪些行为是坚决制止的？
