本周入职了新公司，加入了新的产品团队。因为我是前一天从老东家出来，第二天就立马入职了新公司，所以我对这种工作环境的变化带来的冲击特别的敏感，就趁此机会将最近观察到的一些内容记录下来。
很早的时候我养成了写文章的习惯就是因为有一种很深刻的感受：
懂了某些知识的人，很难理解不懂这些知识的人在面对这些知识的时候是怎么样的心境。
同样的道理，入职一家公司久了，其实就很难体会到新入职的人是怎么样的心态和感受，所以难得有机会自己当新人，就应该想办法及时用文字记录下来。未来当自己需要针对此场景做一些优化事项的时候，例如自己组建新团队，自己创业，自己招聘新人等，这些细节的记录会让你做得更好，更加从容。
由于我刚加入这个新团队不久，所以我不对新团队的内容做评价，怕不太客观。而是对原原由网来团队内容做评价，因为这个团队是我搭建起来的，我比较熟悉，评价也更加客观。这些评价与感悟有助于我查缺补漏，完善自己组建产品团队的方面的知识，也希望对各位读者朋友们有所帮助。
他山之石，可以攻玉。
1、文档方面
产品团队的文档沉淀很重要，尤其是针对复杂多变的业务。之前我在WS的时候就很重视这一块的输出，所以我制定了一套的文档写作要求，包括强制要求使用Markdown，让大家学习阮一峰分享的技术文档写作手册，学习标点符号的标准指导并给出了一些特殊的标点符号的使用要求介绍等。
总体来看，这些要求在小产品团队（6人以下）都很容易铺开执行，大家做出来的东西也会很统一，具有美感。
所以产品文档除了要求要多写，多沉淀之外，在美观性上也要有所要求，最好是能统一标准。
2、新人指导方面
WS的新人入职指引我更新了四个版本，基本上就是入职一个新人就更新一版本，而我做的内容其实也挺简单的。无非就是一个思维导图，一个系统和资料的导航页，几份公司主线业务的流程图，还有渐进式的单独沟通。
思维导图：主要介绍了新人入职的时候要看哪些内容，组织结构是怎样的，然后接下来的一些沟通计划是怎么样的，还有最后会留一个问卷回访调查，例如这份指导手册有遗忘什么？还有什么是不懂的？是否需要改进和补充什么？
导航页：导航页有所有的业务系统的快捷入口，还有一些共享文档和手册的入口。新人入职之后就可以快速的了解到大概有多少系统，然后各个系统是怎么登录的，域名地址分别是什么……
流程图：一方面会介绍公司的主要系统的发展历程，例如什么时候开始开发的，目前是什么版本，另外一方面也会解决主要系统间的业务流转是怎么样的，看不懂没有关系，只要有一个大体的印象就好了。
渐进式的单独沟通：一般刚入职的前一个月，每周会有一次面对面的非正式访谈，聊一下入职的感受，是否遇到困难或者有什么做得不好的也可以在此刻沟通。然后第二个月到第三个月大概就是一个月一次的沟通会议，主要就是沟通一下团队协作过程中做得好与不好的地方，也可以询问一www.58yuanyou.com下入职之后的一些心得或者意见的。
3、需求分析与评审
WS的需求分析和评审做得都不太好，这里面有很多是我的因素导致的，还有一方面是业务特性的问题。
一方面是没有太注重数据和上线后效果、价值的体现。更多的是为了应付客户或者业务的要求，上线后没有及时做回顾和总结。经常有一些需求上线了很多人不知道，至于是否有什么效果和作用那就更难把控了。
另外一方面是没有很好的需求评审制度，很多需求基本上都没有拆解的很细。而且也没有产品组内部评审的流程，很多时候都是独立负责某个模块的产品自己梳理好了之后就直接找研发过需求迭代计划会议，然后顺带着就评审完了需求。所以在实际研发过程中，开发遇到问题需要经常和产品沟通，这个其实没什么坏处。最大的坏处就在于其实很多需求可以在评审期间就毙掉或者发现不合理的地方，但是由于已经流转到了开发手里，这个时候走回头路就比较麻烦了，费时费力，还影响团队协作的信任感。
通过这几天的观察，我发现需求分析和评审的节奏把控还是得花时间和心思重点打磨。如果总是忙于交付开发，那么必然就会做出很多考虑不周全的场景，也会有很多返工的情况出现。
4、产品规划与总结
我对产品的规划也很重视，之前在WS的时候基本上月度规划，季度规划，年度规划我都会持续性的去做。最终的结果就是，我的规划能力提升上来原由网了，但是其他同事则越来越舒适了，规划能力就开始下滑了。因为大框架我都搭建好了，大家就自己想办法往里面填充东西就好了。
所以有一段时间我特意跟大家搞了几次的培训会议，包括OKR知识的培训，写了一篇规划相关的文章，启用TAPD的看板功能等，都是为了提升其他产品经理的规划能力。
在产品总结方面，2020年开了很多次的分享和总结会议。基本每个月月底的时候有一次月度总结会议，每三个月（季度）搞一次季度总结，每六个月（年中和年终）会有一次总结。总结会议应该鼓励大家都发言，无论对与错，都应该确保每个人都能完整的发言，然后大家一起做点评和总结输出。
5、需求跟进方面
WS是使用TAPD作为需求管理的工具，也是以敏捷迭代的方式来规划需求。但是随着业务的推进，我们遇到了一些小难题或者有几个点没有做好。
第一个就是需求拆解的粒度不够细，需求拆解的不够细，那么就不方便估算工时，迭代进度也就不太好把控；
第二个是每日站会开得越来越少，因为团队的人数比较少，有些时候一天下来没有什么明显的迭代进度，所以就不太爱开晨会，结果可能慢慢地大家都开始懈怠式的不开了；
第三个是成本估算和进度把控不够严谨，需求评审了之后没有主动意识去估算准确的工时和成本，也没有相关的项目经理来跟进成本和进度方面的管控；
第四个是上线前的产品宣讲不够到位，由于迭代启动的时候就没有让相关业务方及时知晓迭代的内容，导致产品快要上线的时候产品宣讲大家也不够积极，感觉上线了什么功能与我并不是很相关；
以上问题有些解决了，有些还没有解决，我也一直在思考和记录相应的解决办法。某些难题相信未来会有解决方案，而有些可能当下的「不合理」也算是一种最优解了。
6、项目立项
项目立项的制度在WS没有形成，虽然有这样的历史案例，但是没有规范化。很多时候开启新项目的时候都是IT部内部几个人知道，然后开个小会议就开始干了，至于干完了之后有什么作用，要达到什么目的最后是否达到了，然后其他部门是否要参与配合，是否有什么风险，是否值得做之类的都没有完善的制度来管理。
虽然从结果上看最后做完的东西基本上都是有用的，但是随着团队越来越大，如果还是这样做的话，踩坑的成本太高了。一旦项目失败了，那么付出的成本就很高，还有一堆要擦屁股的事情。既影响士气，也带来很多负面影响。
所以未来如果有相似的大型项目，那么制订一套项目立项流程制度还是很有必要的，可以参考PMP的项目管理知识来组织。
7、会议方面
网上有段子吐槽产品经理基本上白天都是在开会，只有晚上的时间是自己的，所以从晚上开始才算是真正的工作时间。
这个现象有一定的道理，也契合某些团队的实际情况。但是站在我个人的角度来看，我是www.58yuanyou.com不太喜欢开会的，尤其是一些长会议。
很早的时候，如果是我开会作为主讲人，那我可能也会情不自禁就叨逼叨过去了1小时，后来我自己作为台下的听众去听别人叨逼叨很久的时候，我发现好煎熬。
于是后来我开会作为主讲人的时候，我都会下意识地去控制时间和节奏，因为我很容易就讲High了，一下子就过去了挺长的时间，但是下面的听众可能并没有听进去多少，反而起到了负作用。
产品的会议多是事实，但是有一些会议制度可以提前制定并宣讲，是能解决一部分会议多的问题的。大家要主动参与规则的制定，并严格遵守，不然会无限制地延长开会时间，最终感觉开了很多会议但是其实成本并不高。
我更加认同的是小范围的私下沟通，先把大方向定好了，细节也可以自己私下沟通原由网，会议只是来做决策和表决的，而不是来「做题」的。
另外一个难点就是产品内部的会议怎么把控和切割的问题，例如产品组内部如果按照系统模块或者业务线切割的很碎，那么基本上大家都是各自螺丝钉，我不知道你在做什么，你不知道我在做什么。但是如果切割不够细或者不清晰，那么就会演变成一个会议你要参加，他也要参加，最后发现这两个人都不是主角，都是来旁听的，浪费了很多时间。
大团队的产品内部如何切割我不太熟悉，但是如果是少量团队的情况下，我建议是采用「1+N模式」。「1」就是某个业务线或者系统模块的主负责人，「N」就是其他一同协作的产品经理。开一些相关的会议的时候，让一个人出面做代表，剩下的人专心做事；开会的人回来后再私下沟通讲解就好了。这个「N」具体是多少看大家怎么划分，我个人觉得「N」在4以内就会很舒服。
结尾
最近公众号的产品圈有一阵怪风，我称之为「月薪50K的产品」工具人。这个「月薪50K」的产品是谁我没见过，但是这个广告我是见了太多了，感觉挺无奈的。产品行业真没有那么多文章和知识能写的，写来写去感觉都是新瓶装旧酒，但是不写呢又怕被时代给抛弃，「50K」这个词太让人焦虑了，我看到真的是头皮发麻。
最后结尾小小地吐槽了一下最近的一些感悟，其实也不是我装清高，不让大家接广告或者对接广告有偏见。只是感觉这个标题真的越来越咋呼了，整这么大的架子，结果出来的是一个对产品新人的培训课程。以后产品行业越来越「内卷化」，咱们这些打工人只能自食恶果了……
溜了溜了，最近上班距离变长了很多，感觉对自己的情绪和心态都产生了影响。
希望以上分享对大家有所帮助，如果你也想在产品方面有所成长和积攒，除了报班，也可以试着写点东西记录记录。搞不好就变成了斜杠青年，转手就可以接一个「60K」的广告了。
