这是最近做产品的一些杂感。放在 FB 有不少回应所以贴过来。
做产品 = 「解决问题」
很多人做产品，包括我很久以前做产品。其实都犯了一个很大的错误。就是太早写 code，甚至是说太早写 spec。
做产品，精确地来说，就是在「解决问题」。
很多产品之所以会失败，就是可能下决定的那个人（有可能是 Founder，有可能是 PM ）看到了问题，先做了第一个假设性的解法，并决定将之 implement。
因为这个假设性的解法，很可能是有盲点的。但 Founder 或 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，应该具备下列特性
相关文章
