02｜小厂创业：做出一个产品，卖给所有人

问题1：有人说客户需求是个哲学问题，而不是与客户沟通的问题，不是客户提到的就是需求。 我的感受如下： 1、目前很多面向B端的项目交付，在宣传的时候，都是按照产品层面去介绍的，落地的时候，就变成了项目，对于小客户来说，买来用就可以，但是对于政府、银行这种来说，内部的用户数量也很大，权限也要有要求，目前定制化的需求就是那些SSO集成认证、数据库适配改造、各种安全审查等等。某些代码的抽象确实不太容易。 2、对于银行这种客户来说，中间件不是Tomcat、数据库不是Mysql，在做产品开发后，都会需要核心的产品开发人员去支持项目的前期交付，以确保项目的稳定上线，和客户的信任，个人的感受就是前期做产品开发交付感觉可以学到一些内容，时间长了以后，就发现每次都是从1-2的过程，而不是互联网化的从1-100这种挑战一直增长的过程，B端项目的量级不会发展的特别快，可能系统上线了几年后，才能迎来技术架构的升级和挑战。 3、B端客户通常认为自己招标的项目给乙方公司做，乙方公司不认为自己是外包，但是对于B端客户，大部分都认为非自己员工干活的公司都是外包，也导致了目前业界对外包的怀疑，以前可能大家觉得外包工资高，现在大家更想的外包没发展，工资高没啥太大用。这个时候的突破，也就是自己出去跳槽或根据当前部门的老板出去寻找更大的机会了。 4、项目的交付过程，通常需要有超过几个5年经验的开发人员，招标的需求中明确要求了，所以导致经常出现核心产品的开发人员，需要各个地方出差去维护前期的支持，这个情况在某些程度上也会影响产品原有的开发进度，尤其是创业类型的小公司。

因为项目太少所以抽象不够，如果有 100 个项目我一定能抽象出一个东西 --------------- 这个深有体会，最后基本上很难落地。 回想起来只是一个美好的愿景。 是自己在一个接着一个重复项目过程中的 前进的动力

目前可能也在重复毕老师早期的路：通过这篇文章倒是让我明白了服务型团队其实应当怎样走路。

🤔☕️🤔☕️🤔 【R】做项目，一直漂泊，很不爽，二来不规模化，每个都要重来。 【.I.】以前做项目，那个还真算很久以前，做些课题类的项目，有种错觉，自己技术不错，做出来就是不太满意，而且还会唠叨，怎么就不能事先把需求提清楚。后来听到一句话，那算是很后来，应该是最近5年内，听到一句话说，需求一直在那里，它一直没变，只是自己没有本事把需求发现提炼到位。这个做项目中，对需求理解转变的跨度，将近15年。 【.I.】如果给需求划定三个框，分别为基础设施型、领域知识 型、业务过程型，当项目里遇到具体需求时，先把需求的类型做个初步判定。如果该需求更多基础设施层面，那么就要看业界当前的技术进展，这部分拿得来就要用好，拿不来自己也很难搞出来。如果该需求更多业务过程型，那它的典型特点，就是能画出过程来，虽然会比较繁琐和场景耦合，但是这样需求的实现，才是客户最终肯掏钱的点。从业务过程里，总结出领域知识，当然在分析需求时，能直接划分为领域知识型就更好，这部分内容在做项目时容易被忽视，尤其在项目时间紧张时，补充说一句，哪个项目时间不紧张，实际上这部分就该是积累起来，而且必须是在项目过程里去积累，就像投资中的定投，项目过程里就要定投时间，投入更多思考去深入理解，进行梳理和抽象，转化为领域知识需求，开发成领域知识类产物，即所谓随项目产出的产品。或者说，做项目时，主线是能够积累的领域知识，辅线是完成项目交付。 【Q】项目和产品，到底有什么差别？表面看，项目是对方明确要哪些，针对性完成这些需求的过程，就算项目。产品是我做成这样，有满足你需求的，那就带个回去，就算产品。也就是说，项目的交付准确对应需求，产品的交付匹配某个需求。项目的主动在需求方，产品的主动在定义方。这是我对项目和产品的粗浅理解，毕玄老师能否再展开和深入谈谈，对于大部分普通软件工程师而言，参与项目类开发，对比参与产品类开发，哪方面更有利于开发人员的技能成长？ ———— by 术子米德@2022.10.06

经营业务的软件能否标准产品化，是个很值得讨论的问题。业界不少软件公司还在做类似的尝试，最近还听一位CTO说过类似的尝试。另外非经营类的，如财务,行政，HR等软件就能较好的产品化，SAP，salesforce 等公司就是代表

很遗憾没有听到毕老师的原声，哈哈

软件产品抽象复用难，saas有机会吗

感觉主持人对这个行业了解很少

说实话，谁还没经历过将toB的软件做成产品的梦想呢？但是文章里说得很对，同水平公司买入产品，肯定想创新，只能往低水平公司卖拷贝

“抽象成产品，卖给所有人” 个人觉得这个产品定位有问题，产品定位的目标人群应该是具象有范围的，譬如老年人/中年人/小孩，而不是泛泛指所有人，做一个面向所有人的产品，极大概率会失败。