作为需求，第一次参与To G的项目，憋了几个月终于收工了，赶在辞旧迎新之时从外部、内部两个方面做下工作总结。
对外：
——【政府客户方】
在ToG的项目中，政府客户通常期望把周期延长，慢慢做、仔细做，把业务细节尽可能想清楚，尽善尽美再上线。这样的思路对项目组无疑是悲催的，意味着工期不断延后、成本超支等风险。想要扭转局面，需求就要冲上去引导客户一下下的拍板。
本次目中，客户方有明确的牵头部门/人员，但需求沟通确认的进度依然缓慢，原因有三：
• 一方面是源于线下的业务不顺畅，没有形成闭环，不适合在移动端上线，但改造影响面很大，可能涉及多部门、涉及多系统改造，对接的客户一方无法快速的推动。或者，需要很长时间去重新定义业务流程并实践成熟后再上线。
• 另一方面是源于客户本身不能确认，需要想上级逐层汇报，这时候要注意了，很可能上级领导的思路完全不同，这会对项目原本的设计思路造成很大的影响。
• 最后一点是客户完全不想自己去定义需求，先让出方案，然后基于方案再进行推敲，这种情况要不是质（定义内容很专业，但非客户专业领域），要么是量（无论专业与否，工作量很大）的问题。
基于以上需求难以推进和确认的情况，总结了三点心得：
• 首先，反复与客户协商，尝试推进，过程中了解停滞不前的原因。若是业务不顺畅导致，可引导客户先将功能简单化实现，待业务流程顺畅后再迭代更优的版本，但是要考虑好功能的可扩展性。也可以将大块头的需求拆散，降低需求颗粒度的同时也降低了确认难度，需要把握好小块需求的关联性，关联性强的放在一起来沟通确认，这样需求进度就不会完全的停滞不前，也能保证开发团队的持续产出。
• 其次，对于客户权限范围内不能直接拍板的需求，积极推进客户向上级确认，更可以准备好方案由客户带领约见上级领导进行汇报，主动帮助客户来做确认，这其实是很好的了解高一层决策者对项目想法的机会，把握好对项目很有帮助。
• 最后，先出方案再反推客户需求的推进方式，也无需头疼。反推型需求方案更有利于把握进度，因为“等客户出方案”主动权在客户，“自己出方案反推客户”主动权在自己，调研的细节逻辑更了解，在方案整理、沟通上花费的时间可以自己掌控，算是利好的情况。
——【数据支撑方】
结合政府部门信息化的演变过程来看，通常小程序/APP都是基于已有业务系统进行建设，大多避免不了要与第三方系统对接数据。此项目也不例外，数据支撑方为PC端，移动端需求与PC端大体一致并端依赖PC端需求的输出。总结一下数据对接工作心得：
• 在前期需求沟通阶段，两方对已有系统了解程度不同、功能实现上也有所差异，所以对客户需求的理解会存在差异，如在对接和沟通过程中没有意识到，就意味着要数据对接阶段要多花一些时间和工作量来纠偏。在项目管理中，这属于可控的风险偏差。最好对每次沟通做录音，会后根据录音梳理出会议记录并同步给数据支撑方，与其确认会议结论，可以有效的避免在对同一事项的理解不一致，也方便后续查找和追溯沟通依据。
• 在项目过程中，需要了解数据支撑方的开发计划和实施进度，根据功能依赖、时间依赖等因素评估项目安排和进度是否ok。所以，需要随时沟通，做到“心里有数”，遇到敏感点最好拉着客户来拍板，不要直接沟通；对于项目过程中客户的需求调整，两方一定要随时同步，保证需求一致，避免后期联调对接时再返工修改功能，影响开发节奏。
• 另外，数据供给方通常还会有其他的开发任务，不能确保是100%投入资源，需要把控他们的配合节奏。可以基于任务项双方共同制定对接计划，明确接口提供时间点、联调时间点，接口跟进过程全程记录，翻车的时候也好有兜底 [捂脸]。
对内：
——【产品经理】
最开始找不准需求和PM的工作边界，不清楚哪些是属于自己的职责范围，甚至觉得需求的工作如果产品经理亲自操刀会更利于产品设计，这可能跟不同公司岗位责定位有一定的关系。本次仅从如何与产品做好配合角度来反思工作过程，先回顾一下与PM配合过程：
• 项目初期，PM根据业务需求、客户想法、已知资源规划功能框架，产出原型并与客户敲定产品边界
• 然后需求介入，对具体功能做更深入调研，分析业务流程、已知系统现状、数据支撑等方面内容，将调研结果同步给PM
• PM据此完善产品设计并反向提出疑问，进行下一轮客户沟通直至需求定义清晰，产品设计与客户达成一致意见。过程中PM通常会考虑几方面内容（包括但不限于）：①功能是否适合移动端、②业务需求清晰度是否满足产品设计、③后端数据是否支持产品设计等等。
经过磨合与实践，工作边界逐渐清晰。需求，是面向业务的，主要负责调研现有业务功能、流程、角色等，以及与第三方对接数据支撑情况，这些工作都是为PM做产品设计的基础；而PM则主要负责产品的交互原型，关注最终用户如何能获得更好的体验，更顺畅的使用移动端办成事，如何更好的展现客户核心、亮点的业务功能。由此，感受到了需求与PM的工作重点事实上是不同的。需求要了解客户思路，也要了解PM的思路，用客户的业务去斧正产品设计，同样也可以用产品思维去影响客户，要做到这样游刃有余的平衡，还需要多多学习和积累，也是下一步努力的方向。
——【自己】
项目分3版上线，在第一版本收尾期介入，这是一件非常难受的事情，对项目和产品的理解相比其他成员存在脱节情况，一时间沟通不畅。经过了一段时间的挣扎和努力，终于在第二版本工作中顺利融入。
• 认真学习项目历史文档，标书、原型设计、需求规划等内容。最好让产品同学全面同步下项目和需求情况，这可能缩短50%上手时间，非常有效。
• 需求版本要做完整的记录，一些细节的调整可能影响全局（基本工作，真的很重要）。留记录方便总览全局工作、可以作为追溯依据，便于总结经验教训，为下一版本输入战斗经验
• 虽是需求，但需要积累一些产品知识，这样可以站在产品的角度与客户沟通和讨论，带回来的需求也会更贴近PM设计需要。从另一个层面讲，岗位职责从来不是一成不变的，工作中适当的延伸和扩展是对自己负责。
以上的内容是对近期项目的回顾和总结，仅做记录，无任何指导意义，非专家非大拿。欢迎交流，有砖轻拍，心眼儿小着呢~