大部分互联网公司都没有一个定岗的项目经理来专门负责项目进度，这项职责逐渐被产品经理揽下；那么在管理过程中，有哪些“坑”是需要避免的呢？看本文给的9个建议吧~
大部分互联网公司好像都没有一个定岗的项目经理来专门负责项目进度。
更多时候，管理项目进展的职责落在了产品经理身上。久而久之，好像很多产品经理都会自发积极跟进项目进度，尽自己最大努力保证项目顺利上线（起码我认识的和我身边的好像都这样）。
遇到成熟的公司还好，版本和特性都规划得比较好，项目成员也有足够的时间完成各自的模块，人人都留有余地。不过这样的理想情况实在是少之又少，回首做过的项目，大多都是赶时间赶进度，项目成员疲惫不堪。
特别是现在的项目组，每一个项目进行的时候，都会下意识认为：熬过这次，下次就好了。
但事实上，好像这种节奏一直都没有多大变化。
今晚再一次面临回归跑不通的窘境，导致项目成员的心态都有点炸裂，时间越来越晚，我自己也变得有点急躁。虽然最后发版成功，下班路上想了一下，其实是有不少问题可以避免的，记录一下。
一、项目成员权责清晰
负责的业务和业务结合得比较紧密，带领的项目组会收到各个业务方的需求。
在那之前，各侧业务流程不够清晰，也没有明确的规范和边界，业务方会经常直接给研发同事提需求，研发同事有不清楚的地方，也有时候会直接找到业务方，某些需求没有经过产品经理梳理和确认，导致进行中的项目有的特性和别的特性冲突或是遗漏，这些风险又往往只能在发版前产品经理最后验收的时候才会冒烟。
每每遇到这样的问题，不能按时发版不说，还会导致项目成员互相之间有怨念。
在这样的事情发生几次之后，实在是有点忍受无能，针对几个出现问题比较大的项目，在发版之后进行了长时间的详尽复盘（过程各种纠结不表），最终和各侧负责人一起确定了几条规则：
1. 重新界定各侧权责
比如业务方只需要提出业务需求，至于产品方案怎么设计是产品同事的事情，业务方可以提供建议，但是严禁过多干涉产品方案细节。
为了确保产品方案能够满足业务方需求，会在需求评审之前和业务方沟通确认。另外，需求评审也会邀请业务方一起参与。同时，也会在各个验收环节邀请业务方参与验收。
2. 单点串联单点负责
如上文所述：项目进行过程中，多方决策多方意见容易造成信息不同步以及遗漏的问题，后来就限定项目参与方单点负责，涵盖了设计、研发、测试全过程。
一旦完成需求评审并完善方案最终交付进入设计研发之后，除了设计师征求设计风格之外，业务方基本不再参与项目细节。
设计、研发、测试过程中，有不确定的点相关执行人员都会找产品同事确定。设计验收、发版验收等环节，产品经理会在验收确认直到没有什么问题之后，邀请业务方参与验收。我们通常采用邮件通知验收，预留验收时间，文档收集修改建议的方式进行。
经过一段时间的执行和不断强调之后，大家都形成了比较好的责任意识和边界概念，知道什么事该找什么人，各行其是，起码协作效率提高不少。
二、产品经理要有用于说不的勇气和气魄
可能是因为我们业务变化比较多的原因（部分也是因为业务方新人较多，需求不清晰，泪目），产品侧会时常接到一些比较匪夷所思的需求，而且业务方在前期提需的时候还容易出现表述不清的情况，所以会发现产品同事在耗费大量时间需求预研，方案设计，最终完成需求评审之后，还常常接到业务方一些灵机一动的小脑洞。
看起来，这些小脑洞确实能够带来一些体验上的小提升。但是对于整个项目规划来讲，真的就很容易是灾难了。
部门新入职的产品小哥哥刚开始还比较心软，认为好好和下游同事求个情临时加上一点点需求也蛮好的，所以妥协好几次，直到发现现象越演越烈，终于不堪其扰义开始正严辞拒绝。
作为业务方，当然是希望体验越好越棒，但是当产品同事接收到一些临时需求之后要学会评估和判断。有些看起来很小的特性，给体验带来的提升非常有限，但给整个项目组带来的麻烦是没有穷尽的。
业务方和产品同事，看起来很小的东西，可能需要研发同事变更整体设计思路。不断新增或变更需求，光是扰乱规划影响研发宝宝们的心情，就够被打死的了。所以，下次再在项目研发进程中，有临时需求加进来，快速判断及时say no吧。
三、让所有同事养成有问题及时反馈的意识
过往项目中，见过挺多，尤其是研发同事，是真的不喜欢把问题“捅”出来。
上个月的某个项目，研发同事遇到其他项目组的数据问题，导致他自己的研发进度一直走不下去，憋了快两天，直到早会上问起才暴露出来。
好像挺多职场小伙伴并不太会借力，运用自己身边的资源，遇到问题习惯性的自己憋着，直到别人问起。
在那之后也会多次强调大家遇到问题一定要及时反馈，需要产品同事们协助解决的，直接提要求给相应的产品同事即可。有时候，遇到不能解决的问题，还是要学会上升，也许在自己层面不能解决的问题，上升一下，其他人一两句话就能cover掉。
四、更好的特性分类和关联规划
这个很重要，但因为我确实不懂技术，有兴趣的可以和自己的研发同事讨论一下，当一个特性因为关联特性有问题不能发版的那种等待，也是很折磨人的。
五、约定好确定的发版窗口
原本，我司有规定每周二和每周四是确定的发版窗口。但是项目多的时候，大家好像赶着赶着就会忘记一些规定，导致业务方也好、项目成员自己也好，并没有相对严格的时间线，在项目进行过程中，没有那么强的“仪式感”和进度感。
当天没有完成任务之后不自觉抱一种无所谓的心态，今天不能发版，那就明天发版好了，久而久之，就容易出现比较随意的工作状态，缺少一些敬畏心。业务方不在意发版窗口之后，在业务节奏安排上就没那么严格，项目成员面对项目延期，也变得无所谓，这是很不好的。
六、尽可能的预留buffer
虽然，每个人都希望项目能够顺利进行，严格按照规划好的时间向前走。但是事实上，久经风霜的人会告诉你，那基本是不太可能的。
看起来多么顺利的项目，也都会在最后出现一些诡异的关卡。
不管是多赶的项目，也要习惯性预留20%-30%的buffer。项目能够提前完成当然是好事，但是相信我，基本上这里那里总会出现一些让人崩溃的bug。预留buffer，给自己预留一些余地，总是没错的，毕竟，谁还没有个想要摸个鱼的时候呢（buffer绝对不是用来摸鱼的：））。
七、保证良好的测试环境
业务复杂的时候，稍微大一点的特性都有可能需要跑通整个流程，绝对不会是说只需要针对当前特性“象征性”的测试一下即可。
比如要验证购买结果之后的某一运营位，就必须要验证整个购买流程。
我司共有六个测试环境，但凡设计到整个业务流程的时候，经常（非常经常）出现其他流程跑不通阻碍整体测试的情况。比如今天晚上那个特性，我们自己侧的业务和代码都没有什么问题，但就是在回归的时候，其他部分流程跑不通，不能完整测试，其他侧同事因为忙于自己的事情，又是周五，整整延误了三四个小时，才最终跑通整个流程。
如果是重要特性需要测试，保证良好的测试环节，是一件非常提升效率的事情（在此，表白一下我司测试小妹妹，温柔漂亮专业又性格好）。
八、有变更及时邮件通知、jira记录
需求评审虽然已经足够细致，大家也通常会在会上提出不少问题，但是设想和真正实施中间的差距还是不少的。
所以有一些问题一定会是在研发过程中才会真正出现，比如少了的某个交互，遗漏的某个逻辑。
遇到这种时候，一定不要过分相信口头沟通，大家事情多的时候，往往上午才说的事情，下午都不记得了。发生的关于需求所有变更，及时、准确备注在jira，并在群里@相关人注意，不仅仅是为了显示正式和专业那么简单。前期沟通时候保证准确性和有文字记录，能减少很多验收过程中的不确定和撕。
九、不要周五发版
最后，最重要的也是最需要铭记的：不要周五发版！不要周五发版！不要周五发版！
一是双休的公司，周五发版，一旦出现线上问题，整个team的人周末就完了，这件事不少人应该都体会过。二是，周五发版，真的，太考验人心了，想想，所有同事都提前下班欢度周末去了，你还要留在办公室百无聊赖的等待发版，项目成员想砍你，也是很容易理解了。
每一个项目都有很多坑，虽然踩过越多坑才越有底气，但还是希望每个踩过的坑都是有意义的，也希望每个产品经理负责的任务都能够发版顺心、顺意、顺利。
例行申明：发版这件事，说来，每个人都有很多自己的经验，这些讨论更多是我个人的一些复盘总结，不代表别人或我司观点，有不同意见，欢迎探讨，但是不接受杠精宝宝哦。
