——然而这个原本计划十一上线第一期的产品，仍然没有能在十一前上线。
这是我接手的第二个产品，因为紧迫性排在了最前面，因此成为了预计可以第一个完成的产品。然而尽管大家都努力地投入精力在这个产品中，然而由于合作方的这个产品也没有开发完成，还在不停地变动，而且我自己也缺少经验做得很不足，因此掉进了一个又一个坑。
通过这个产品，我算是真正的体验了一把大公司的工作氛围。原本我以为 MZ 就是大公司，如今才体会到了真正的“大”公司是什么样——第一就是分工之细，每个人安守自己岗位的本分，一个功能可能需要多个团队才能完成，这样在沟通过程中就会有一些困难和磕碰，而且也多出许多时间成本；第二，对“流程”比较重视，我觉得大部分人虽然痛恨所谓的“流程”，但是在工作中更多适应了大公司的员工则会善用“流程”来维护自己。在这个项目中，我接触到了多个部门的多个团队，也走了很多冗长的流程，每天白天都在不停的开会和跑来跑去沟通，只有下班后才有时间好好写一下需求文档，在和合作方沟通过程中，由于对方也是这样的大公司，而且对方对流程更加重视，因此沟通中花费了更多的时间成本。
我所在的团队的风格是擅长执行，在写需求等书面性的事情上面则比较偏弱。我认为这一点在这次产品的实施中也造成了比较多的磕绊。由于商务和老板对这个产品都比较看重，leader 便希望可以快速上线一版，因此在提需求时，直接都是含糊的“第一版按照另一个XX产品做就好”这样的需求，而没有自己留出一点时间认真的思考和解构一下需求、完整地思考一下用户场景，更没有仔细地研究合作方的平台究竟有什么特殊性和限制，就直接向其他团队和开发提了需求。导致提的需求随着不停地发现各种坑而不停地变动，或者就是讨论讨论着突然发现另一个特殊的使用场景下会有问题才现想如何弥补。另外就是 PRD 的重要性，原本我以为文档一类东西不是很重要，很多产品经理的 blog 里面也说产品经理不应当纠结文档，没想到其实 PRD 还是很重要，其一是这个是“流程”上必不可缺的东西，如果没有的话其他团队会因此为借口不去为你排期；其二是，PRD / 需求文档是一个“证据”，究竟团队中成员做什么、出问题了时候按照什么办等等都是按照落实在纸面上面的东西，开发并不会为了产品去想，所以流程是否合理、流程中是否缺失了某个环节他们也不会考虑，都是产品要写清楚的，而不应该期望别人按照你认为的“正常逻辑”做。在项目快上线前，我偶然看到了我们这里一个项目经理的文档，里面的需求拆分的极细，让我大为触动。
产品好不容易通过立项进入了开发，渐渐的许多问题又浮现出来。我才恍然大悟：即使真的是“像素级复制”的产品，仍然会有很多不同，永远不要轻信别人说的话而轻视了产品的复杂度！即使一些小小的编码问题、长度限制、人工审核松紧度这类看似很小的不同，也会由于蝴蝶效应产生很大的差异。
同样我还体会到，作为产品经理，不应当像公司内其他职位的员工一样只着眼于自己职责范围内的事。作为产品经理，我们的目标应当首先是推动产品完成，因此即使某些工作并不属于产品的范畴也应当随时关注、想办法完成。不得不说，我有点偷懒，并且为了防止自己给别人留下太 pushy 的形象而在某些环节没有跟紧。例如，这次之所以没有在节前发布成功，说起来是因为合作方在十一前 2 天才告知原来给错了一个接口，实则我自己在刚拿到接口文档时也没有监督负责这部分的团队的开发仔细测试，只是含糊的被告知“你们的需求这个接口都能调通”，而没有和 RD 明确地提出。当然这个事情很多方都有问题，然而如果我进一步问一句，这个问题或许就可以避免。
另外就是那些最后一步的操作，不要留在最后一步，如果可以完成就提前完成。留出一段时间给可能出现的问题。做产品最应该信仰的是墨菲定律——觉得会发生的不好的事，真的一定就会发生！
总结下来，即是对于我这样的 0 岁初级产品经理一定要掌握的两种基础能力——
- 对于产品的推动能力
- 对于需求的解构能力
这两点如同武功高手在童年时期练习的基本功，虽然看似简单，但是想要做好，并不容易。
节后还有更多的项目需求需要提出。希望可以保持精力不停挑战！
