阶段论

有一个很有意思的事儿，任何个体、团队、公司或者其他带有成长属性的事物，它们都有类似的生命周期。比如著名SWOT 分析法（也称TOWS分析法、道斯矩阵）即态势分析法，20世纪80年代初由美国旧金山大学的管理学教授韦里克提出，经常被用于企业战略制定、竞争对手分析等场合。

如果大家真的了解这4个字母的意思，S是优势，W是弱势，O是机会，T是威胁。按照企业竞争战略的完整理念，战略应是一个企业能够做的（即组织的强项和弱项）和可能做的（即环境的机会和威胁）有机组合。

强与弱，机会与威胁，都是不断的在转换的状态，在不同的阶段都有其独特的价值，有事你觉得你觉得是威胁让你有了危机意识，很有可能它会变成你一辈子里最难得的机会，有时你觉得非常强大，可能只是巅峰时的转瞬即逝的辉煌。生命里最好玩的就是不确定性，能够让你身在其中却捉摸不定，如果把握好趋势，你得到的将是更多美好。

还有一个类似的概念，叫波士顿矩阵，就是我们常说的四象限分析法。明星产品、现金牛产品、问题产品、瘦狗产品。上图也涵盖了这些，首先从最右上角的问题产品开始，这其实是创造期，它可能会失败（威胁），也可能会变成明星级产品（机会），如果是明星级产品，它可能是一失足成千古恨，也可能是变成现金牛产品。现金牛的产品，你要做的是维持好这个状态，让它足够长，将巅峰辉煌延长，越长越好。瘦狗型产品要方式它过快消亡，你能做的就是降低这个可能性。

你会发现所有过程都挺难的，从无到有的创造很难，做到现象级的明型产品依然很难，做成现金牛产品又要担心盛极必衰，到了止不住衰亡时（瘦狗），你又要大手一挥，从中攫取最后更多利益。

人之渺小，多得意于此刻。处在任何一种状态，它都不是绝对的，更多的时候是要能够清楚自己所处状态的阶段是什么，才能在趋势里更好的做出决策。现时是公平的，它给了每个人一样平等的选择，只是有的人懂得早有的人懂得晚而已。有时，我喜欢一个人在高速上开车，我看到的电光火石间的机会与威胁，我更喜欢面对心跳的刺激而能够做出更好的选择。

如果你迷惑，一份清单，一页纸里画好四象限，足够了！

技术人通常都短缺产品化思维

了解PMP的人大多都知道项目干系人的概念，它指的是积极参与项目或者其行为能影响项目的计划与实施或其利益会收到项目执行或者完成情况影响的个人或组织。识别干系人是项目管理时最重要的准备。我一直都觉得，干系人更多的是利益平衡中的重点。

那么，我们看待项目里的事儿，如何去识别重点？

对于精于运营之道的公司来讲，必然会大量的做各种营销活动的。按目前的做法，几乎一个活动要5人/天的工作量，也就是说每个月至少有1到2个人被搭进去。短期看，这是没问题的。但问题却也是极为明显的。现在是运营迁就开发，不敢安排更多活动。且不论商业损失，就是开发自身也是极为难受的。

那么更好的做法是什么呢？

关于创业，《rework》一书里讲的最为直接，抓自己的痒处。比如自己缺少erp系统，写了一个，然后做成erp服务提供给更多人使用。首先是满足自己，然后抽象成通用需求，其实更准确的讲是，开发一次，复用的价值就非常大了。这和生产是类似的，买个机器10000，投入5年可以赚10万，投入是一次性的。以后的投入是日常的生产投入，都是赚钱的生意。

对于现状而言，如果有很多人精力投入，而且是无止境的投入，那么它就是瓶颈。它就是目前的干系最大的迫于解决的问题。如果不解决，你没法有更多精力做更多的事儿。技术本身并没有价值，支持好业务它才有价值，如果能过技术创造业务价值，那就是更大的价值。

活动类的需求做成系统的非常多，比较典型的是h5场景应用，还有更高级的以表单形式切入市场的金数据等。对于营销活动类型是可以枚举的，对于活动页面的复杂性是可以预见的，对于给运营用的系统可以再简单一点，甚至不客气的讲能用就好，他们是你的同事，能够给你一定的耐心让你成长。

• 页面切图非常麻烦，花费很多精力，通过psd、sketch生成h5页面也不是难事，以后能够让运维直接上传，然后处理一点事件和显示组件，是否更高效？瓶颈出现在技术这边，技术就应该解决它，让别人变成瓶颈。否则终生无出路的。
• 静态化，放到cdn上，可以更低成本的抗压，转移压力到服务商，其实就是能用钱解决的问题都是小事
• 限流，给后端更多保护。秒杀类活动高并发，瞬时流量非常大，你能做的就是更好拆分，利用缓存来限流
• 分而治之，举例活动入口和查看活动结果是可以分开的，错误页、指引介绍页面页是独立的。
• 切面为了技术而技术，看到好的优点，也要面对它的缺点。比如vue在h5里应用并非那么理想，压缩后20+kb的大小还是非常大的，是否开启了分块加载，是否编排页面加载顺序，是否能够使用bigpipe等优化，在弱网络环境下，才是最考验人的时候。技术情怀是没用的，落地的都是实实在在的东西，合适的才是最好的。
• 配置化，比如限流的redis是阿里提供的服务，运维并不在我们这里，如果单台或者高配版本也扛不住怎么？能够多加几台？按照请求数和台数求余数，来判定走哪台缓存机器。在后台，针对单个活动可配置是非常重要的，弹性伸缩是一方面，其实基础建设做不到位也是白搭的
• 数据可视化，趋势可以预估，流量其实很难预估，实时统计数据会显得尤其重要，任何决策没有数据作为依据，都是拍屁股想的。一遍看着数据量上上涨，一遍调整配置信息，在活动预热阶段就已经准备好要用多少台服务器了。

想要把这些写好并不容易，麻雀虽小，五脏俱全。技术人通常都短缺产品化思维，这是非常可怕的，有非常好的需求明确自己的痒处，不去解决，那么技术的意义又何在呢？在不同阶段中识别瓶颈并解决，我想，这才是好的技术人的价值。

人还是要有危机意识的，年底了，你有什么能拿得出手的东西向老板拿红包呢？勤勤恳恳的支撑好业务是一方面，如果能锦上添花，一定是更好的。让老板看不到你的天花板，你才有更多升职加薪的机会。

管理模式

小作坊式的管理通常都是头痛治头脚疼治脚，永远都是应急，被需求追着跑。无数的血泪史都已经给我们敲响警钟了，但还是会发生，让人心痛不已。我们先不要完全否定，再回到阶段论看，它的问题到底在哪里。

公司初期，人员不多，业务也不多，来一个需求接一个需求是非常正常的事儿，事实上，公司在生存线上挣扎，哪有精力给你做技术规划。公司成长期，人员突增，你会发现之前的模式依然适用，就是10人对接11个项目，依然能够做的很好，每个人忙的时候是不亦乐乎，闲的时候也是不亦乐乎。但是，这阶段的SWOT是什么呢？优点是沿用已有成功经验，大家很舒服，缺点忙的忙闲的闲，不像一个团队，威胁是在有诱惑的情况容易离职，其实最大的问题是大家的存在感，要让大家有团队意识，能够集体去应对困难，已经不是个人英雄注意的阶段了。上面SWOT里唯一没讲的就是O机会，你只要知道了症结点，害怕无解么？

团队人数一定，工作量一定，10个人应对20个需求，每个人2个，一定会闲的闲死忙的忙死，需求的难易程度是无法做到平均的。那么换一种方式呢？5个人一组去应对10需求，所有人是同进退的，要么都闲要么都忙。明显是以团队方式更优。

再说一下归属感的问题，独立完成某个项目是孤独的，并非每个人都具有这种能力，技术人在技术上并非全栈，并非都善于沟通，所以诸多因素结合在一起是非常痛苦的事儿，有时候郁闷了，不懂又无人可问，别人没做过这个项目，你问了也白搭，于是只能自己扛。另外一个问题就是个人成长，个人因项目经验的成长是非常小的，我之前曾经总结的学习三法，第一的就是跟人学是最快的，其次是读书，最差是自悟。如果沟通尚且不多，又何来的交流学习呢？有人要离职也是非常正常的。

统一大家的思想，做共同的事儿，荣辱与共，利益相关，那就从一个team做起吧！