本文系用户投稿，不代表机核网观点
项目管理是个麻烦事儿，我目前在团队中主要担任PM一职，负责项目管理方面工作。通过本次BOOOM比赛对项目管理又有了新的认知。
实际上项目管理是个麻烦活儿，团队中的PM也是几经周转最终落到我的头上。首先作为PM，最先要保证的是作品按时按量完成，在管理项目的时候，你会跟团队成员有许多博弈在里面，当然，这里的博弈是中性的。比如策划期望自己的想法得到贯彻，于是疯狂的加功能或者改功能，而程序期望自己的代码健康又稳定，花的时间也更多，美术也同理。你需要保证尽量满足每个成员的需求，同时又能够让项目正常进行，如果某个改动会影响工期，那么你应该慎重考虑，必要时一定要坚决地坚持自己的观点，说服团队成员将风险项放弃。你的职责是保证作品质量和按时完成，其他人的意见如果与你的核心职责有冲突，你应该坚持自己的立场。假设决议通过而导致项目延期，责任应当在你。
在坚守自己的首要职责外，你需要采取的态度应该是保守的(答应我,做一回老保,就这次)，团队成员的工期的预期是他们根据自己的情况得出的合理估计，是有偏差的，在你这里永远要做好最悲观的估计，即假设所有人的预计都是不可靠的，如果发生此类情况，项目应当如何调整，你需要有风险对冲方案。假设一个功能程序需要3天，那么3天后程序没有完成你要怎么办？当场放弃，还是多给几天？如果多给几天，势必会压缩后续工作进度，那么你就得考虑放弃后续的哪些需求？你要与策划核对他对功能的优先级，保证优先级最高的任务优先完成，跟他说明情况，商量着把需求控制在合理的范围内，多了要砍，少了要加。我根据自己的实践结果表明，游戏开发不论小团队还是大公司，工期延期比比皆是，几乎是家常便饭，所以延期不可怕，但一定要做好准备。
接下来分享一下我的失败经验，本次参赛我组作品虽然最后赶出来了，但最终包却存在恶性bug，这个功能是在11号下午加上的，也就是最终包前几个小时，由于时间紧迫，我在测试时也是草草测完就告诉程序可以打包。实际上在之前我已经告诉了团队成员，在最后一天禁止任何代码提交，全组只做测试工作。但由于我犯了我前面所提的错误，没能始终坚持自己的立场，导致了最后的悲剧，最后一天我们仍然在疯狂加功能，策划不断地在提出修改意见，程序也不断的在反复修改，而我看到一个功能只需要一两个小时就加上的时候，也没有提出反对意见，默许了大家的操作，在一旁专心的帮忙测试，到最后大家都很累，我测试也没那么仔细了，最终发生了预料之类的风险，我才追悔莫及。如果上天肯给我再来一次的机会，我一定会否决掉大家的所有需求，让最终包停留在稳定版。
实际上一个小团队需不需要PM也是值得商榷的事，另外并不是所有团队都是全职开发，如果不全职开发，项目管理也没那么好做。关于这一点，就见仁见智了，这里只提供一点对PM岗对项目管理的小小经验分享，另外我本次的作品《魔女破天轮》，大家有兴趣可以玩玩看，看看是否能找到我遗留在里边的bug，喜欢的话免费的关注和投票也可以来一下，我代表团队对您报以最诚挚的感谢！
评论区
共 条评论热门最新