我想对你们说

职场，犹如一个浓缩的社会形态，这里有各种体制和规范，也有复杂的关系网。我们在这种体制和环境下，会遇到各种问题，如何高效妥当地处理，这是一门学问。经过这些年工作经验积累，总结提炼了一下几点，跟朋友们一起分享。

任务管理

任务管理，大家都知道要优先处理重要且紧急，最后处理不重要且不紧急的任务。但是很多人忽略了一点，在我们将这些事情归类之前，是否把所有的待办事项都一个不漏的记下来了呢？你可能会说“我都记在脑子里了”。且相信你今天记得，但是明天，后天呢，当这个项目时间节点多，周期长的情况下呢？这个时候，除了任务分类管理之外，任务的记录（todolist），重要节点跟进变得很重要。市面上有很多的工具可以用：便签贴，word/excel ，印象笔记，notes等软件。可以根据自己的选择选择不同的工具管理。

对于，todolist需要有哪些内容呢？可参考如下：

• Category-任务的类别：对于研发和测试人员来说，包括但是不限于“需求类”、“行动项类”、“大项目”类

• Task-任务的描述：对于重点复杂的任务，如果不描述清楚，可能过几天，自己都忘记了。记录了还有什么意义？

• DDL-任务的截止时间：这点很重要，任何事情都需要有时间节点，方便我们更好的跟进，任务分类和排期。

• Owner-任务的属主：我通常叫owner，当这个任务你不是执行方（Owner），但你需要清楚这个任务的进展情况，我们称关系方（leader，项目经理等），这项就便于你在跟进这项任务的时候直接找到Owner。

• Status-任务的状态：这个很好理解，一般情况下，我将状态分为几种，这里面涉及到需求的跟进，所以会有部分是需求的状态。每个人可以根据实际情况进行调整。

  • 未开始

  • 进行中

  • 处理完成

  • 延期

  • 开发中

  • 已送测

  • 已上线

  • 方案设计

• Remark/Risk-任务描述/风险：任何事情，在进展过程中，需要做一些记录和备忘，当然，也可能会有一些风险情况，你需要这么一个字段来记录并提醒自己。

对应几个英文单词：what，when，who，how。中文就是“什么事情”，“谁来做”，“什么时候完成”，“完成的怎么样了”，“是否有风险或者问题”

综合以上几点，我自己做了一个表单，因为我之前用excel，excel和Numbers有些功能不一样，大家自行去设计下自己的todolist。仅供参考。

todolist-demo.png

俗话说的好“工欲善其事，必先利其器”。有了好的todolist，剩下的就是需要养成良好的习惯，时时刻刻去更新，review你的todolist。

排期管理

研发小伙伴做的最多的就是需求的排期，当然，非研发人员对于一件事情，也是有计划。这个计划在研发这个领域，我们专业的称它为“排期”。

一件事情，或者一个需求，在每个环节需要对需求方有个交代，排期就是个交代。仅以研发场景为背景进行举例，经常会听到如下的反馈：

1、我现在手头上有很多的需求，都还没有做，排什么排？

2、我没办法排，我依赖周瑜部门，他们都还没告诉我粮草什么时候送到，我如何告诉你什么时候出发？换句话说，别人接口什么时候提供都不知道，我怎么知道自己如何排。

针对这些反馈，或者语气差点叫抱怨，下面我会给出建议方案。

首先 ，一个常规的排期涉及到的关联方，如下图所示：

need.png

排期中涉及到的场景太复杂。从产品->研发->测试。这个中间，研发内部，还分前后端和移动端，还有部门之间的协同配合。所以，整个排期链条会拉的比较长。那么对于这个中间的每个个体，或者叫做unit，他如何做好自己的排期呢，如何消除以上的两个核心痛点？建议的思路如下：

1、项目应该是有个统筹的人的。这个统筹的人，可以是这个项目的产品负责人，也可以是这个项目的项目经理，他需要来解决跨端资源协调和跨部门沟通的问题。

2、对于本部门来说，按照大的项目deadline，根据部门内部的资源，进行合理排期。在遇到需要关联部门提供接口的，不太建议完全把这个排期权交由提供接口的关联部门。比较好的做法是，本部门按照现有资源进行排期，对于关联方需要在什么时间点提供接口，给出期望时间。然后，由本部门的某个人对接人，将本部门的整体排期发给项目负责人，以及关联部门的对接人，进行一轮沟通。沟通的结果有两种：过/不过。

过：皆大欢喜。
不过：询问关联部门，他们能提供的时间。

• 如果他们提供的时间，在本部门资源能接受的范围内，不会导致项目 延期，那么就同步修改这个时间，三方达成一致。

• 如果他们提供的时间，在本部门资源能力范围内，可能会导致 项目延期，那么交由双方产品或者升级至业务，进行协调，统筹。可能的结果是砍需求，或者降低其他需求的优先级，或者 是改实现方案 等等。

如上，A部门依赖B部门，就像产品以来研发的落地一样，产品在提需求的时候，也会告知研发一个期望 上线的时间点。所以A理论上也应该告诉B部门，A期望你B给我提供接口的时间点，如果达不成 一致，那么叫上产品再一起沟通方案。

反之，弊端就是B部门会根据他实际情况，给你一个他的排期，那么A部门就很被动，资源完全就取决于B部门的安排了。

3、部门内部，前后端，移动端，加强沟通，方式和第2点类似。需要根据自己手头上时间的安排，给到对方一个 期望提供的时间点，如果无法达成一致，那么升级，进行2轮沟通。

4、对于上面抱怨的第一点，我想强调的是“我们想要的是排期，是个计划，并不是让你现在就做。”所以，第一点抱怨的人，需要去调整下自己的思路。因为每件事情，都需要有个计划。也许对方要的是个计划，不是让你现在就给做。你如果现在没时间排，可以你就告诉对方，什么时候有时间排，这也是个计划。

评审需求

日常我们会听到比较多的反馈诸如，“产品没有需求文档”，“产品需求文档写的不清楚”，“这个是产品PRD有问题，做到后面我才看到的，不是我代码的问题”等。也许这些问题确实存在，但是：在需求评审的时候，为什么不提出来呢？也许你又说“我很忙”，“当时没去”，“当时没认真听 ”，“当时我不清楚这块，不是我负责的”。类似这辩解，循环往复，接连不断。

针对以上的反馈和抱怨 ，一点大家必须要明白：需求评审，是这个体制赋予你的权利，你如果没有认真去行使这个权利，产生的后果你需要自行承担。

如果明白这个道理，还是出现这样的问题，那你是怎么做的呢？扪心自问：

“为什么不仔细去听产品讲的流程？”

“当时有问题，为什么不提出来？”

“产品有没有催快点结束这个评审？”

“产品有没有要求说不明白不可以问？”

“如果很忙，为什么不和产品商量个合适的时间评审？”

“如果是其他方的功能，为什么不叫其他方？如果不归你管，为什么不知会人家？”

所以，你行使权力的时候，充分的去行使权利，哪怕你觉得产品的prd格式你看不懂，你都可以拒绝这次评审通过。但是一旦你认可了评审通过，那后续有关需求的问题，你就需要承担责任了。在此，我想对各位研发小伙伴说一句话：工作中，你必须要明白你有哪些权利可以行使，你有哪些义务要去做。如果不去行使，浪费了不能怪别人。义务不去做，那么就是你失职。

服务意识

每个人都有本位主义，也有“受害者心理”。当问题发生的时候，会首先考虑到自己，说白了，就是“不是我的问题”，“问题在别人那边，这个不是我负责的”，“我是背锅的，是因为你之前的事情没说清楚”。接下来的剧情是，产品或者业务登场亮相，强势的产品或者业务会说“我不管，我只要结果，你今天必须给我解决，否则影响业务开展。”，不强势的产品或者业务会说“好吧。”，然后他/她就去直接找你或者她领导，“汇(投)报(诉)”下刚才推进的情况。可想而知，最受伤的是刚才这个找了一大堆理由的人。

以上的场景，我相信很多人都经历过。坦白说，可能真的不是你的问题。但是大家身处职场，需要明白一件事“大家都是为了解决问题”。如果你坚持这种原则工作，我相信，本小节问题你可以不用继续阅读了。

技术为业务和产品服务，产品和业务对老板和公司负责，大家都是为了把问题解决掉。发生以上情况，不论这个问题是否与你有关，是否是你的责任导致，请和产品或者业务，说大一点范围就是需求方，请和他们站在一个角度，一个阵营，来看待这个问题。

将自己的位置摆正确了，这个时候，我相信大家会有这么几个问题提出来：

1、是我这边的问题么？是或不是。
2、如果不是我这边的问题，那这个问题和谁有关？找到问题关联方。
3、这个事情应该怎么解决？总结问题的解决方案，给到找你的需求方。
4、如果是我的问题，我怎么解决，什么时候解决。
把以上几点总结下，告诉你的需求方，我相信，任何找你的人都会给你个赞。
5、后续这个问题解决的怎么样了？方案运行的结果如何？持续跟进。
如果加上这一点，你的需求方从此就会认为你“靠谱”。因为你给了他一整套解决方案 ，而且在持续跟进解决方案运行的结果，也就是我们通常所说的，将整件事情“闭环”了。

综上，遇到产品和业务找你，或者你的需求方有问题找你，你按照如下步骤来做：

• 将自己摆在需求方的立场。这点很重要，否则，你就会出现“本位主义”和“受害者心理”。

• 帮助需求方分析问题，寻求解决方案。

• 持续跟进方案的效果，并给出建议。

  这个方法论，适用于任何场景。每个人找到你，或者你找到每个人 ，都是去寻求帮助的。他们或者你，都希望从对方那边得到方案或者建议，而不是拒绝。如果想明白了这个道理，问题就迎刃而解了。

  总结

先总结这几点，希望对大家的工作有所帮助。