研发岗和产品岗的时间管理策略总结-大局观概述

  每个人都有自己的一套时间管理策略，策略没有好坏之分，因为最终还要靠自己去执行，无论再优秀的方法也改变不了一个懒惰的人。但是，当你觉得工作很多很累，不妨停下来思考一下，会不会是自己的时间管理出了问题。
  下面全是自己总结梳理的经验，策略本身可能对读者没有指导价值，希望分析和梳理时间管理策略的过程和方法可能对读者会有启发。

​ 1、研发岗工作，写代码搬砖，基本是大块时间的安排：【岗位要求：代码质量、按时发布】

1. 用MarkDown把事项分为长期目标、中期事项、近期任务；
2. 长期目标经常回顾对比，中期事项不间断的跟进进度，近期任务优先级安排好；
3. 管理好优先级，基本上按事项优先级串排，做到不遗忘、有反馈就行了；
【时间风险】
1. 通用需求，靠一次性方案实现，会陷入泥潭（例如，疫情数据上传的工作，虽然实现了半自动化，但每天都要做）；
2. 一次性需求，设计通用方案实现，会产生严重时间浪费（例如，卫健委ODPS空间数据迁移的工作，实现了一整套数据迁移工具，结果只用了一次）。

​ 2、产品岗涵盖管理性工作内容：【岗位要求：满足需求、创造价值】

【工作内容】
1. 出文档：PRD、MRD、BRD、白皮书、使用说明、培训文档、架构方案(SA汇报材料)；
2. 产品定位：面向全国推广思考，抽象通用的业务场景和客户价值，梳理与阿里系其他产品的关系，寻求「借力」，避免冲突；
3. 需求分析：引导客户发表诉求，总结痛点，把握亮点；深入业务领域，挖掘需求；
4. 产品设计：好看(选择重点页面投入UI资源)、好用(用户使用习惯分析)、快速迭代(节奏把控)、节约成本(技术方案选择、研发成本和边际成本平衡)
5. 售卖推广
6. 交付客户

【工作模式】
1. 总 客户需求的分析结论 （文档支持：MRD、BRD）；
2. 分 功能拆分、细化设计 （文档支持：PRD、白皮书、使用说明）；
3. 总 把部分汇总成一次研发迭代的版本；
4. 分 前端、后端、UI、测试排期和节奏安排；
5. 总 售卖推广、交付客户 （文档支持：架构方案、培训文档）。

【时间风险】
1. 在「分」的场景下，寻求高并发，避免成为串行瓶颈，要尽量拆分，把工作节点的依赖关系捋清楚，把不存在依赖关系的内容拆出来，不存在依赖关系的节点要积极推动同时进行；
2. 总的时候多沟通，保证方案合情、合理，否则会导致客户满意度低、研发适配度低；
3. 分的时候果断决策，原则上不接受更改意见，否则会导致前后矛盾、推到重来。

【最近比较累的原因】
1. 两个大PD对产品迭代的节奏把控思路不一致，导致返工重做；
2. 对产品定位的思考占用了不少时间；
3. 对研发成本和边际成本平衡方法论的思考上占用了不少时间；
4. PRD设计与研发沟通节奏上没把握好，应该设计一点让研发做一点。

【时间管理方法】
1. 「关键词」梳理和优化，产品的宣讲和介绍，必须总结核心的关键词，围绕「关键词」去解释，尽量避免去理解对方的认知范围，贴合对方认知去解释，除非对方是大领导
2. 「总」 的工作内容列在一起，标记沟通程度，沟通对象或调研方向
3. 「分」 的工作内容放一块，标记细分程度，分派对象
4. 标注优先级和时间节点

【决策质量】
1. 决策的效率和质量，与沟通、调研的程度正相关，沟通次数不代表沟通程度，提高沟通、调研质量是提高决策质量的关键；
2. 沟通程度和调研程度在理论上存在100%，100%代表对政务业务领域（职权、职责、职务）上完整的闭环的摸排。

【遗留问题】
1. 产品定位的纠结如何处理？
2. 如何平衡研发成本和边际成本？

3、大局观

1. 「总分总分总」中的<总>的部分，因为其中涉及到多方协调，需要决策支持；
2. 「产品周期」中的<产品定位/市场策略>的部分，因为其中涉及和市场、其他产品的互动，需要决策支持；

工作流水线

需求调研：
原型设计：
需求评审：
研发节奏：
功能验收：
部署交付：
推广培训：