留一点冗余就是为了应对各种延期风险，而且这种风险在跨部门或者跨公司的合作中非常高发。如果是没有截止时间不固定，那么能延期是最好的。关于制度，项目大小、紧急程度、项目进展不同制度也是不一样的。注意，不在会上展开讨论。周会的话时间不要开太长，一般来说不要超过1小时，太长也容易无效率。周会上不对紧急的事情拍板，不对重大的事情拍板，不对细节的事情进行讨论。每周周报，这个是书面的部分，一般是在
编辑导读：作为产品经理，无法避免的一项工作就是项目管理。一个项目能不能顺利完成，需要靠项目管理来进行约束和保障。本文作者根据自身工作经验，提出了产品人开展项目管理的三个重点和三个工具，希望对你有帮助。
项目管理这个事情吧有点微妙，你要说是产品经理的专业技能范畴吧，好像也不是，毕竟项目经理和产品经理差别还是蛮大的。你要说不是产品经理的范畴吧，很多公司都是产品经理负责项目管理，当然也有技术负责项目管理的。所以这就是一个附加技能。
我们今天就聊一聊项目管理，希望对大家有所帮助。
项目管理重要吗？当然很重要，毕竟项目能不能顺利实施完成也是靠项目管理来进行约束和保障的。
一、那么项目管理具体是管什么呢？从产品经理的角度来说，实际上是三个部分：跟踪项目进度、协调资源冲突、控制产品风险。
1. 跟踪项目进度
这个非常容易理解，任何项目都是有时间节点的，对于项目进度的跟踪其实就是去看项目的实际完成情况和制定的时间表是不是一致，有没有遇到什么问题，有没有延期风险。
在实际的研发过程中，如果是部门内部，其实延期风险很小，一般问题不大，所以这个就不谈了，按照正常排期走就行了。
但是如果是跨事业部或者跨公司的研发项目，延期是非常有可能出现的问题，排期预估的时候要预留一定的冗余。
为什么要预留冗余？因为不同部门的每个研发身上都可能不止一个需求，很可能是多线程并进的。
这就导致一个项目出点问题就会影响到其他项目，跨部门的合作参与的人又多就更容易出问题。
团队协作不是钟表走时，分分秒秒都非常精确，人不是一种精确的机器，项目参与的人数越多变数就越多，你需要提前考虑这种变数。
有些人是不同意这个观点的，认为时间表就是要按照最短时间去预估，不能有冗余，这样项目节奏就快，效率就会高。如果出现跟不上进度那是技术自己的问题啊，因为时间也是技术自己给的啊。
事实的确没错，是技术自己给的时间。但是世界又不是按照事实来运转的，如果出现延期风险，那么固然对造成延期风险的同事会有一个负面的评价甚至扣绩效，但是对于你这个项目管理人来说也是一个负面评价，你负责项目管理，但是你的项目延期了，你负有管理责任。
遇到这种情况你通常会要求对应的同事加班，如果这个同事能加班还行，如果他已经天天加班到极致了，你要怎么办？他已经凌晨下班了，你要求他继续加班？这个不现实的。
提高效率的初衷当然没问题，但是一定要合理和适度。延期是不合理，那么加班就合理吗？也不合理，说明预估的时候就不对啊。
当然我知道很多公司都有加班文化，但这不是一个正常的现象，你不能拿一个不正常的现象去做为一个理由和依据，很牵强的。
另外我说一下，如果仅仅是倡导加班文化，但不是以实际需要为目的的，这种公司不值得长期干下去。
留一点冗余就是为了应对各种延期风险，而且这种风险在跨部门或者跨公司的合作中非常高发。
你一定要记住你的目的是保证高质量、按时完成项目，让排期表尽量紧凑不是你的最重要的目的，你的最重要的目的是高质量且按期上线，然后才是能快就快点，换句话说多快好省，首先是好，然后才是快和省。到了现在这个阶段，好是基准线，快不是了。
当然好不是全，不是说你一定要憋个大招，这个不行，容易出事。好的意思是最小闭环尽量简单和好用，可靠性好。
当然我们在这里说的是一般情况，如果是紧急需求那肯定是用最高的优先级和最短的时间。
2. 协调资源冲突
项目资源冲突，如果是小公司可能这个问题不明显，因为同时并进的需求不会多。有点规模的团队就会遇到这个问题。
这种冲突可能是突然出现个优先级更高的项目，也可能是其他项目突然出了点情况，需要占用更多资源，这就会影响到你的项目。
不管是哪一种情况，都需要协调资源。
产品经理可以拉上对应的项目负责人、各部门领导，然后开个简会讨论下如何调整，一般来说一个人的排期要调整的话就意味一串人的排期要调整，先把优先级定下来，然后再去看被影响到的同事有没有其他同事可以替换，如果有就最好，换一个同事，小调一下就行，没有的话就需要重新定排期。
一般来说公司内部是有通用的判断规则的，按照规则去做就行，譬如业务优先之类的。
这个问题不大，主要还是一个协调的过程，要快速重新定排期，然后向相关的同事进行同步、向相关领导进行汇报。
3. 控制产品风险
产品风险的话，一般是在做的过程中要增加需求，这种的话倒不是一开始没想清楚，而是业务方可能出现了新的场景，所以需要增加需求点，这个是比较常见的情况，业务方也没有预料到；或者之前预想到了，但是约定后续开发，出于某种原因又需要加入到这一期了。
这都是有可能发生的，出现这种情况的话如果需求量不大可以考虑加，如果需求量大的话就一定要把握住节奏，放到后续版本里面，如果说允许业务方随时加需求就可能会对项目管理造成巨大的影响，因为你一动可能其他项目也得跟着动，然后就管理上会非常混乱。
当然按照我的经验来看，有些业务主导的公司其实是很难抵制住这种情况的，所以在日常的过程中需要尽可能多的去沟通和灌输这种不插需求的理念，把坏处讲清楚。
极小概率的情况下会发现原来设计的部分，技术实现有难度或者成本过高，可能会需要变更方案或者重新评估，如果是这种情况那就要根据实际需要去看是调整方案还是调整排期，都可以。
有的时候技术会提方案，说这样这样行不行，这就看能不能达到预期，达不到的就不行。按我的经验来看达不到的时候居多，所以尽可能把这个预期说清楚，然后说明白他的方案为什么不行。
一般来说出现这种情况，我们会优先考虑是否可以追加投入人力，如果可以加人的话优先考虑加人。如果没有剩余人力或者加人也没用，那么就考虑是否一定要按期交付，如果截止时间是固定的，那么就考虑砍需求或者拆分版本。如果是没有截止时间不固定，那么能延期是最好的。
二、那么怎么样才能做好项目管理呢？我们分成制度和工具两块来聊。
工具很简单，JIRA、禅道、teamwork、worktile、封神榜等等，非常多，选一个就行。
制度是关键。关于制度，项目大小、紧急程度、项目进展不同制度也是不一样的。
一般来说制度就三种：每天站立会、每周项目周会、每周项目周报。
站立会，顾名思义就是站着开会，每天早上大概10-15分钟，每个人把进展和遇到的问题讲一讲就结束，这个会的目的就是为了快速过一下进度，看一下有没有出现大的问题，如果没有就结束了，如果有大的问题那么就在会后再拉个专门的会讨论和解决对应的问题，或者再去找需要协调的同事沟通。注意，不在会上展开讨论。
每天开会是一件很烦的事情，所以一定要把这个会的基调定好，不是简单的汇报工作，更多的把重点放在同步信息和协调合作上，以及遇到问题如何快速解决上。
把时间控制在10-15分钟也是为了规避开会效率低下和形式化的问题。
每周周会，这个也很常见，项目每周开个周会过一下整体进度，同时把之前出现的问题强调一下，然后再在会上讨论一些项目相关的问题，最后说一下下周的重点工作或者要关注的时间节点。
周会的目的是项目组的同事相互同步情况，然后把问题和后续工作都明确一下。
开周会的时候不要讲太过细节的事情，把本周内完成的几个重点的事情讲一下，然后讲一下遇到了哪些问题，后续需要哪些部门配合，然后讲一下下周的重点工作或者会完成的工作内容。
周会的话时间不要开太长，一般来说不要超过1小时，太长也容易无效率。
周会上不对紧急的事情拍板，不对重大的事情拍板，不对细节的事情进行讨论。
每周周报，这个是书面的部分，一般是在周会之后写，项目负责人写就行，一般是像上级领导、各部门负责人、项目组同事同步项目的情况，最简单的话可以把周会的会议内容整理成周报内容。
注意，不要让项目组的同事给产品经理写周报，没有这个汇报线的，需要沟通的问题就在周会上沟通。
越是大的项目越要写周报，小的反而不是很重要。
具体的我就不展开讲了，开会和写汇报我想大家还是会的。
最后说一下，我这里讲的是单个项目的制度，如果是多项目的我建议是分开管理，产品经理毕竟不是专业的项目经理，没有能力做综合管理。
三、那么这三种制度怎么应用呢？常规项目周会 周报就可以了，如果项目不大，甚至都不用开正式的周会，简单沟通下，然后整理出周报就可以。
常规项目一般不会超过两周，没有必要搞那么复杂。
如果是长期项目，譬如固定的项目小组，那么就和常规项目一样处理就行，周会 周报。
如果是紧急项目或者重点项目，那么就要采用站立会 周会 周报的形式，紧急项目或者重点项目，一般时间紧任务重，节奏要求比较快，对于管理上的要求就更高一些，而且相关领导也比较重视，最好你就每天简短汇报一次，所以在汇报前你可以先开个站立会汇总一下情况，这样大家心里都有数就不会有什么问题。
额外说一下，有些长期项目或者重点项目在日常是采用周会 周报制的，当临近收尾或者项目出现重大变化的时候可以临时加入站立会的制度，这样可以更好的管理项目。
所以原则上管理要求越高的项目或者阶段就用站立会，日常就用周会 周报就行，如果人数少的话直接用周报就行。
其他相关问题：
项目管理该不该产品经理来做？
没什么该不该，如果有人做了，你可以不用管，如果没有人做那么你就管起来，你的目的是保证你的方案能够上线，这中间出现的任何情况你都需要关注，任何没有人做但是需要做的事你都需要做。
没有管理权怎么做项目管理？
产品经理本身就是一个没有管理权但是需要行使部分管理职能的岗位，譬如设计的同事和技术的同事在界面交互的细节上有分歧，最终是你来决定的。你并没有管他们的权力，但是你需要行使管理的职能。
另外没有管理权并不等于没有领导权，市面上关于领导力的书籍多得很，总起起来就是积极主动、事事关心，出谋划策、落地执行。温和的把话语权拿在手里，逐步的让大家多问你的意见，这就是领导力。
既然大家在很多事情上都会问你的意见，也就表示在做选择的时候你的意见就会影响大家，这就是领导力。
在开展项目管理的过程中，其他同事经常抱怨或者态度不好怎么办？
我想起一件陈年旧事，我记得我在上一家公司的时候我们在早期曾经招过一个做项目管理的新人。
她的工作之一是根据项目的时间节点去向对应的同事确认是否按期完成了，当时个别同事就抱怨说：天天催天天催，烦死了。
时间一长那位同事感觉自己就是个催债的，同事不友好的情绪感受的比较多，所以主动离职了。
这里面就有两个问题，一个是个别同事态度不端正，既然是你没做好，别人催自然是一件很正常的事情，跟项目进度的同事只是做好自己的工作而已，但是他显然没有这样的自觉，遇到这样的同事就只能公事公办；另一个是她的主管上级并没有重视这个问题，没有纠正这种情况，同时也没有让她感受到工作的价值，在肯定工作成绩和进行正向激励上还是没有做好。
所以如果出现这种情况就要尽快找对应的同事谈一谈，纠正错误，同时对管项目的同事进行肯定和激励。
当然，我这是马后炮，当年其实我们都能力不足，没有关注到这个问题。如果是现在遇到自然就能处理好。
项目管理是不是招专门的项目经理做比较好？
如果是小团队完全没有必要，没有那么复杂。
如果是大团队，那么我们也建议尽可能由团队内部的产品或者技术来负责。
我讲一下我的经历，我曾经在一家餐饮saas公司做产品，当时我们有7、8位产品经理，项目管理的工作比较繁重，项目经常冲突和延期，于是招了一位项目经理来做项目管理，但是来了之后还是发现无法解决这个问题，因为发生冲突的根本原因是经常性的压缩排期和加需求，这个的话想不延期都困难，所以找不找项目经理不是重点，合理的排期制度和需求控制才是重点。
项目管理工作不是产品经理的核心技能，但通常也是产品经理的职责范围，所以做好项目管理，确保项目高质量、正常上线是一个产品经理需要关注的核心问题之一。
项目管理的经验可以在日常工作中一点点积累，也不用因为技术的抱怨或者态度不好而感到不舒服，你记住你的目的就行。
工作不是交朋友，有很多摩擦是很自然的，所以不要让这些部分过多的影响工作本身。
以上就是我对项目管理方面的一些简单分享，希望对大家有所帮助。
本文由 @产品人玄青 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 pexels，基于 CC0 协议
