我想写这篇文章的目的除了想记录下自己的感受外，更希望给对新西兰产品工作感兴趣的国内的产品经理朋友们一个参考。我记得3年前我曾在各处搜索和咨询产品经理到了新西兰对应的职位是什么。现在我找到了产品相关的工作，有了一些体会，希望我的经历可以给像我我当初一样想寻求答案的人一些启发。
我们公司的PO和国内中初级的产品经理职责比较类似，需要在高级产品经理规划的产品路线图下细化需求，排列优先级，和开发对接需求和排期，跟进开发进度，做验收测试和跟进上线。但是，我们的公司PO的职责还包括兼职Scrum Master。即我还得思考如何让这个团队更好的交付结果，改善工作流程和工具使用，还得组织和主持所有的团队会议。另外一点不同的是，PO是可以跨业务跨团队支持的。例如我目前在支持CMS系统的产品开发，但参与开发这套系统的团队来自于三个地方，其中之一是公司内部员工组成的，另外两个都是第三方。本公司的团队中，我是做全套流程，然而对于第三方我算是业务方PO对接，第三方公司有BA和scrum master，甚至也有PO，我的职责是提需求，给出优先级以及跟进排期和结果即可，细化需求以及团队项目管理就由第三方公司自己做。因此在不同的团队内，我的职责也不一样，这很有意思，我既是甲方也是乙方，真是全新的体验。此外，我仍然在体会在新西兰做产品工作和国内的共同点和差异点，希望在未来的文章中能做一个专题去分享。![]()
（我司惠灵顿办公室产品技术区域就这么几个工位，一般都坐不满）
这边大部分公司都是用Agile的项目管理方式，所用的敏捷框架是Scrum。我司也是用Scrum，两周一个sprint， 每个sprint都会有明确的目标和交付计划。我能想到和之前国内比较类似状态的项目，一个是当年在阿里实习的时候做过每两周迭代，另外一个是在搜狗做销售工具升级迭代的时候。其他大部分项目都是需求评审，排期，开发，上线，以瀑布式项目管理为主，或是瀑布+敏捷混合的方式进行的。而现在，我们主要是敏捷开发，即便是一个大型项目，也是拆解到每个Sprint下，每两周有明确的交付。每个Sprint我们都会做几个固定的事件。
- Sprint Planning：明确Sprint的目标，团队成员认领能达成目标的需求ticket，用时1小时；
- Daily standup：每个成员沟通下前一日完成的事项，今日计划和遇到的问题，用时15分钟左右；
- Sprint Review：和利益相关方展示Sprint完成的内容，一般由PO总结下，然后由每个开发分别展示，用时30到45分钟；
- Sprint Retrospective：类似于项目复盘，团队成员一起总结下Sprint内哪些地方做得好，哪些地方可以改进，并且设置后续的改进计划， 用时15分钟到半小时；
- Refinement：团队一块做需求拆解和评估的过程。我们会一起过下每一个需求ticket，讨论并评估开发时长。这个步骤通常是为未来的Sprint做准备的，以便于在Planning中可以快速的认领需求，而无需再做评审了。这个环节我感觉很重要，我们当下每周都会用1小时做这个事情。
Scrum于我算是全新的东西，我在找这份工作之前也花了一些时间听课学习，但还是实践使得学习的理论落了地。因为在不同的团队，上述几个事件的安排和用时也不太相同，需要找到让团队最舒适的方式进行。另外一个我新接触的东西是Chapter。这个东西类似于一个社区，把一群职位相同的人聚集起来一起学习和分享。我们已经成立了PO Chapter，在这个社区内，我们可以分享自己团队的工作方式，工具使用以及遇到的问题，以帮助自己提升Scrum经验，帮助团队运作更加顺畅。因此我不用担心自己以前没做过，因为有人在教你，帮助你。得益于PO Chapter的帮助，我也快速的适应了这的工作流程。![]()
（Scrum流程，图片来源于网络）
新冠确实让办公方式变得更灵活了，我司当时在JD上还特别将灵活办公作为卖点。我现在是周一和周四去公司，其他时间都在家办公。这不是公司要求的，完全是我自己计划的。主要是刚去没多久，去公司可以和大家做些互动，实际上除了周一，其他时间我在公司见到的同事都比较少。大家都自己选择，一般天气不好的话，办公室基本就没什么人。此外，上班时间也比较灵活。只要完成工作，保证每日8小时的工作时间，几点开始几点结束都无所谓。如果遇上接送孩子的时间，就在日历上把这部分时间预定上，这样其他人不会在这段时间找你。例如我如果去公司上班，一般早上8点前就到公司，下午3点多就躲避晚高峰回家。如果在家，那么早上8点20到9点，下午2点半到3点15就是我固定接送娃的时间，我会在日历上注明。上周大女儿有个学校活动在下午2点并邀请家长参加，我提前计划好，到了时间就和团队说需要离开一小时左右参加学校活动，大家也很理解和支持。这种办公方式让我感觉很舒服，我可以同时兼顾家庭和工作。![]()
（会议室，电视都是用来接入google meeting的）
我的同事们遍布在各地。CPO在悉尼，产品技术团队大部分在奥克兰，一部分在惠灵顿，还有一些零零散散分布在各地。例如我们组，PM在Napier，一个开发在奥克兰，其余人在惠灵顿。我合作的两个第三方公司，一个是瑞典公司，但项目经理在美国，一些开发人员在印度。另外一个合作方是印度公司，但架构师在澳洲。我不仅仅要适应这种时间差，还得适应不同地方的文化以及口音，感觉很有意思的同时确实是一项很大的挑战。![]()
（办公室的休闲区域，我司惠灵顿的办公室很小，因此休闲区域也不大，比李先生公司差远了）
我们的需求管理都是在Jira上进行的，没有PRD，例如一个小工具的需求，会建立一个Epic，Epic下会将不同的需求点拆分到有明确目标且可执行的ticket，每个ticket都要包括需求描述，用户故事以及检验标准。上面也说了我们会做Refinement，即如果我们发现某一个ticket需求逻辑较多，用时比较多，那么就说明不够细化，需要再拆分。我们排产品优先级也是按照ticket排列的。你可以理解成把一个完整的产品文档拆成非常细化的一条一条来判断优先级。这样做的好处是每个需求点都能评估出价值，更有利于分辨出哪些属于MVP，保证最有价值的那部分需求优先输出。缺点是没有一个完成的需求文档用于追溯和继承，像新来的同事（比如我）想知道某些点的逻辑就不太容易。![]()
（我司惠灵顿办公室的茶水间，也比较简单）
这些不同既是机会也是挑战，它们都让我打开了一个新鲜的世界。我能复用以往的经验，也需要学习新的知识，更有时候因为不了解闹出很多笑话，我相信还有更多的不同等着我去发掘，我将一一记录下来分享给大家。
