这是一篇自我审视的一篇文章，记录我从一个执行者到业务owner的一些历程与思考，也希望处于困境的小伙伴带来一些启发。本文指的业务owner就是独立负责一块业务，并且需要协调一些业务的其他小伙伴
背景
今年年初接手A项目，这个时候A项目一个人力完全能cover住，所以当时由我一个人负责项目。每天的工作大概就是评需求，做需求，也没有说对业务有啥思考。后来随着业务不断的扩张，我一个人完全忙不过来，所以后期加了一些人进来。这里也感谢领导哈哈，并没有空降ld，一直让我负责这块大业务。但是手下有人之后，我发现我原来那套评需求做需求的流程行不通了，每天需要做的事情多了起来，做的也比较吃力，所以也在反思在哪方面做的不好
思想转变
首先要明确一个事情，业务owner指的就是你全权负责这块业务，那么这块业务所有的事情都与你有关。人力、团队、技术、业务这些都是需要业务onwer去关心的事情。如何把这个业务做好，如何让团队具有凝聚力，让团队具有战斗力都是需要去关注的事情。在执行者的时候我们可能会想我把我这块业务搞定，不出差错就完全ok了，剩下的我就自己搞自己的，比如我在使用React，但是我想研究一下vue的原理，深入一下个人技术。但是我认为业务owner首要考虑的不应该是这个，业务onwer首要考虑的是在如何把业务组织好，把团队成员组织好。下面我从三个方面来阐述我对业务onwer的理解
业务
首先明确一点就是业务是一切的基础，所以首要目标是把业务搞好。作为业务onwer我理解需要比执行者更加理解业务，才能明白业务当前的痛点，和未来的发展方向。关于这点也是很多程序员所欠缺的，认为功能实现就完事了，产品收益如何那是产品的事情。在实际业务中，我们不能对业务有个准确的认知就会做大量无效的工作，比如说产品想上个功能，但是具体收益他也没想清楚，也不考虑人力成本啥的。导致上线一段时间以后发现效果很差，然后又下线，中途耗费了人力和精力，对于产品和研发来说都没有得到成就感。所以我们需要对我们做的业务需要有所认识，避免上述中的情况，并且能够对自己做的事情了解，更好的和产品合作
如何理解业务
首先直接上手使用这个产品，站在用户角度去看这个产品，并能够简短的列一下这个产品做的好的，做的不好的。我发现大多数研发甚至产品都没怎么用过自己的产品，做完需求只是通过简单的数据回收判断当前的产品策略是否有效。 然后尝试回答下面几个问题：
- 为什么要做这个产品，它做的背景是什么，他的一个简单历史
- 主要目标用户，这些用户的分层，不同层次用户为什么要使用这个
- 产品目前有什么困境？是产品没有亮点还是商业化困难?
- 产品相对于行业的同类型产品具有哪些优势，大概了解一下竞品的经营状况
- 明确未来产品的发展方向，最终期望达成一个什么样的效果
- 了解一下产品运营团队，因为你大量的时间都是需要和他们对接的
- 基于目的，实现路径是怎么样的
回答完上述问题后，就会对产品的框架有一个大概的了解。但是如果需要深入产品，这还远远不够。在每个需求被提出时，我们都应该思考这个需求的背景是什么，目的是什么，他的投入产出比是否是合理的。此外我认为在需求外，研发需要多和产品沟通，研发和产品并不是独立的个体，我们应该达到相互依赖，相互促进的一个状态。
如何做好业务
在对业务有理解后，我们就能够对当前产品说做的事情做出解释，如果说当前需求偏离了业务的目标，我们可以提出疑问，能够及时纠正产品策略，避免做无用功。如果我们了解产品，我们就知道当前产品的困境和当前的主要目标，在需求上能够更好的沟通，能够提升双方的合作效率。例如当前业务的首要目标是增长，那么是不是可以建议拓宽渠道，尝试接入多个平台进行导流。以我们业务举例，了解到当前的目标是激进增长，那我们就通过各种技术手段进行拉新增长，例如官网SEO，接入其他平台的分享sdk，拓宽分享渠道
人力安排
在刚有新小伙伴加入团队时，这个人力的安排确实困扰我很长时间，如何进行比较合理的估分，给到产品当前迭代所需要的人力，如何评估当前业务在短期内需要补充和长期内需要补充的人手
如何对人力进行排期
这个用我当前项目来进行讲解能够更加清楚：我们项目包括跟版项目和非跟班项目，跟版项目实行双周迭代，非跟班需要当前迭代的总共人力 - 跟版需求所需要的人力。比如说现在我们有两个人力，那这个双周一共就是20人力，我们不能说20人力全用来做需求，需要给研发留点喘息的时间，我一般是按一个人力一个迭代1.5d去预留的。意思说除去业务外，每个迭代你有1.5天的时间去做自己的事情。在排某个具体需求的时候，也需要注意给自己留一定的buffer，这个时间我一般给自己预留1/4的时间，因为你不知道自己能踩到啥坑，或者在做需求的时候被其他事情给耽误。
人多了以后，对人力排期的掌握也更加混乱，这个时候需要通过其他方式来记录。我的做法就是弄个表格，能够看到每个成员当前迭代能够剩余的人力，对本次迭代能够支持的需求做一个大概评估，根据优先级和人力确定这个迭代能够派上的需求
人力预期管理
这个部分主要是涉及我们目前的业务应该多少人来支持比较合理，我们应该什么要求老板加人。
比如说当前业务我们两个人每个迭代感觉都能做完，但是没有多少剩余的时间去解决我们积累的技术问题，这个时候就需要考虑加人了。因为一旦业务在继续增长，两个人就无法有效cover业务。那我们应该加多少人才比较合适呢，我理解能够满足业务外每个迭代能够有半个人力去做技术方面的建设。比如说现在这个情况，我可能在加半个人能够让业务迭代人力上不在这么紧张，那我实际上就需要增加一个人力，这多出来的半个人力可能去做技术需求也可能为未来膨胀的业务需求做缓冲
技术
作为团队owner，我们需要建立团队的技术氛围，这个技术我认为是主要是围绕业务来搞，脱离业务的技术其实是高屋建瓴并不实用。在实际业务中肯定是存在很多痛点，例如监控不完善啊，构建很拉胯呀，owner需要对这些痛点总结归纳，确定努力方向，并且把这些目标传递给组内的其他成员。为什么要搞技术，一个是为了服务好业务，第二个是技术人的追求。需要明白的是没有人愿意一直干千篇一律的业务，所以我们需要让大家能够在业务中也能够有技术提升，能够有技术思考。 很多团队就忽略了这个，成员就是纯纯的工具人，业务干烦了就跑路了。所以需要在业务的基础上仍让能够让大家感觉除了业务，技术也是大有可为的。
上述就是我在实际项目中所遇到的问题以及反思，可能有些地方并不够全面，欢迎大家讨论补充