这是最近做产品的一些杂感。放在FB 有不少回响所以贴过来。
做产品= 「解决问题」
很多人做产品，包括我很久以前做产品。其实都犯了一个很大的谬误。就是太早写code，甚至是说太早写spec。
做产品，精确地来说，就是在「解决问题」。
很多产品之所以会失败，就是可能下决定的那个人（有可能是CEO，有可能是PM ）看到了问题，先做了第一个假设性的解法，并决定将之implement。
因为这个假设性的解法，很可能是有盲点的。但CEO或PM 下了命令，它必须得执行。团队覆对实作手法产生了矛盾大吵特吵。经过了大半天，合作的众人才可能发现。原先被设定的解法，可能是错误的。
甚至当初被武断所下的结论，甚至也可能是错误的。甚至再追溯下去，还可能发现原来的那个问题是假问题。
一旦太早由个人所推出的结论规格化，并且放到整组人马的生产线上。后面自然可能巨幅浪费资源，甚至可能因为其他面子或政治问题再也难以回头。
由这个主题延伸谈下去的部分可以往下继续谈：
创业MVP
写code 是否tdd, 是否需要早期架构封装化
好的称职PM 应该为团队做什么
创业MVP
一些活跃的网路从业人员，创业的pattern 是：因为有着精湛的coding 技术或者其他网路资源，所以想创业时第一想到的就是盖平台=> 找钱。或者是先写code 再pitch 找钱。
事实上这是错的。
创业，实质上就是解决问题并将之商业化。
要先找到了想付钱的买家，再有了初步方案，再透过前几笔的销售确定的这个解决方法可以work。再想要把这个过程automated 化。automated 的这一步才是写code。
之所以为什么很多时候，想发包给接案公司的客户或者是公司内部的PM 连User Story 都写不出来。那是因为他根本连自己的商业模型都没有run 透想通。既然没有想通，何来automated 化。
这中间大部份的实作者（aka RD）都没有错，因为在不知道你想解决什么问题之前，能做的只是能凭借着过去的经历与想像把类似的模型盖出来。
创业与做产品就是在一个一个回覆客诉与处理危机的过程中，慢慢把模型砌出来。
当然，没有人说这个成本很低。
只是大部分没有悟通这件事的人，会选择在一开始就想闪避这件事的风险，例如一开始就创业者「想建立平台让大家上来用」，PM 一开始就写出「详细的规格」。
结果在中间实做Interact 的时候造成了更大的风险，甚至产生结不了案，钱提早用完的悲剧。
开发产品是否需要TDD，是否在早期就需要将架构封装化
实际上写code 的也是会遇到类似的状况。
有些个性过于要求完美的RD，也是会做出类似的事。明明只是一个简单的功能，却Over Architecture。程式码很漂亮，但是改不动。
程式码只是表达解决方案的一种手段。
Over Architecture 或过于封装的程式码往往不是去除程式债，反而是新增的程式债。
因为这些人的过于封装，不是增加Story 的可读性或维护性，他们的修改手法，反而恰恰把User Story 支解到无法辨读。大大造成队友扩充功能或者修改方向的困难。
同理，什么时机写Test
（后补Test ) 你已有了粗略的方案，你想要将之塑形化，并且希望他不会在意料之外的情境下发生。同时避免其他人以后修改这段程式码时，破坏了执行结果。
（先写Test ) 你手上拿到了一个非常清楚只是要重复的方案。你要用结果验证你的automated 方案是无误的。
程式码的干净度与创业成功的因果关系
同理，Code 的干净度与创业成功也没有正相关，至少，在最初期没有正相关。
Code 的干净度与Project 成功的正相关度是受到RD 教育训练的影响产生的迷思。
大多数成功的专案，专案code 都很恶心。至少在一开始很恶心。创业要的是正确的解决方案，而不是优美的coding style。就如同创业公司的Stage 演变。没有人care 你是怎么优美的解决，人人只要买解决，而不是你多优美的解决。
什么时候code会变得干净，当你有A round的钱，B round的钱时候。有钱hire资深人士refactor的时候。
你的「生意模式」需要「塑形化」，需要「水平扩展」化。这时候你的code就会变得干净。
不是一开始你的code 就「先行塑形」「先行水平扩展」，那么就会成功。而是一开始的主意works，由生意驱动的refactor。才带来后面的clean code。
只是人人往往倒果为因。
PM 的职责
PM 的职责是什么？
既然创业做产品是解决问题。PM 的职责是负责去搜罗资源负责让实作者更能设计出正确方案的或者接近类似方案的人。而不是「方案制定者」。
很多烂网路公司的产品会失败，是因为请了不懂实作的PM 乱写规格，导致的黑暗混乱与巨幅浪费资源。之所以这些PM 不懂实作，是许多RD 认为「搜罗资源与需求」不需要技术（他们自己也懒，而且RD 喜欢写code 当战士胜于在前面当坦克）。
而PM 又认为自己是”Manager”，既然他负责搜罗这些资源，就有权力引导甚至是决定专案的方向。
如果你仔细观察，打造出成功产品的PM ，往往有技术背景。
一个成功的PM，应该具备下列特性
能够协助Unpack 问题本身
能够协助引导讨论方向
能够协助搜集帮助讨论方向的资源
具备一定的实作能力知道资源的限制与Tradeoff
引导沟通
紧盯资源的花费与加速或放慢专案的进度
花上大量的时间与专注力在improve 团队沟通速度与方法
因为实作产品，本身就是一件协调众人之力，厘清问题，沟通，Prototype，Implement 并balance resource 的过程。
