初级产品的一点工作感悟

加入某电商公司一段时间，主要负责用户数据的工作。自从换了工作之后，经常跟前厂同事聊天，总会提到，他们又要加班，节假日泡汤，羡慕我可以早下班……但是自己却怀念从前经常加班的日子，总觉得工作节奏太慢。
静下来再想想，其实也未必不是件坏事，空余时间增多了，可以更多的利用空闲来进行自我填充。想整理一下这段时间的工作想法。

一

首先是team，全组除了老大以外，基本是两年以内的新人配备。团队氛围有一点像是大家各自自行抱团取暖。看似自由度高，实则容易变成无头苍蝇。

曾经在实习的时候呆过一个团队，团队内每两周做一次内部分享讨论。并且中午大家一起吃饭的时候，也会偶尔分享最近又看到一个什么好玩的产品……现在回想起来，也是有点怀念。

那么既然进入了一个分享、学习的氛围没那么浓厚的地方，尽量做到不让周围的环境带着你跑。

1. 每周制定可行明细的学习计划，坚决执行
2. 学会管理情绪，尽量不被周围的环境情绪影响自己对人事物的判断
3. 在完成老大交代的事情之余，考虑能不能创造点小惊喜，比如最后完工时间早于告知老大的deadline；老大给到的需求如果发现各方协作起来有点难度，那么在照常推进之余，想一想有没有另一条路可以通向目的地……

我觉得一个好的leader，应该让大家对团队的整体目标有一个清晰的认知了解，激发大家的自驱力。但是毕竟碰到一个牛逼又愿意带你的leader还是小概率事件……

二

其次，入职以来接手了几个需求，几个感悟：

1. 技术理解力
   和研发沟通的顺畅程度与产品对功能实现逻辑的理解程度成正比，并且如果能够了解技术实现逻辑，能自行大致判断开发成本

2. “不要相信任何人”
   作为产品或者至少是需求的owner，在确认上线前，自己过一遍细节，如果需求涉及到比如数据项的统计，那么就最好是自己写sql跑一遍数据check正确性。

   如果修改涉及到较多的相互关联的逻辑，跟技术沟通的时候，最好的逐级列明涉及到的部分，不要图一时省事。有时候很多事情真的不是你以为的那样。

   如果需求涉及到多个开发team间的合作，他们的支持的部分，有时间最好还是了解一下，小心他们对需求对着对着就把你的需求改了。（发生过一次优化需求，要维持原有取数逻辑，但是后来接口技术和数据组对过数据库跑表结构之后，我突然发现新开的表统计的数据项跟原有有差异。。。）

   再来就是及时跟进确认进度，有问题尽早发现，好过deadline要到了才知道完不成。

三

再来就是，作为一名pm，怎样给出在合理范围内给出解决问题的最优解。当老大提来需求，发现目前现有的开发资源不足以在近期完成上线。这个时候转换下思路，看看是不是有其他的可以利用替代资源的方案可以实现。

最后，还是多读书，多思考吧……