转型到产品后，做了好几个项目，主要以to B定制产品为主，从这几个项目的复盘来看，我对定制产品有了新的定义标准——就是客户觉得你帮他解决了问题，并开心的为之愿意付费，还能进行扩展的进行下一步合作。
产品做失败了？谁之过？
技术经理不行，没有把控好项目周期，没有把控好产品质量？是产品经理不行，没有挖掘好用户的实际需求，做出来的东西，用户不买账，需求变更一茬接一茬？
如果没有找到双方合作的最大的问题症结，结局注定肯定一拍两散，谁也不买账。
举例一个失败的项目，靠老板的关系拿的实验室的一个项目，给一个实验室的生产体系做一套内部管理系统，流程管理、业务逻辑都有一定的门槛。
说白了，就是我们没有接触过的业务。
一开始我们做toＢ的系统时候，既然是定制产品，而且他们业务员比我们懂，那我们做的岂不就是既定的需求，只要他们说什么，我们做什么就行了？在各种需求对接的时候，业务方通常会直接说你给我一个什么什么功能，我们按他说的做，不就已经满足需求了？
接下来，跟传统做项目的方式一样，完整的做系统流程我们都照做了，也有交付验收，那到底问题出在哪里，客户把一期的费用付后，再也不想付二期的钱了，迫使我们不得不关闭这个项目。
复盘下过程问题：
一开始，我们做需求，对接的都是一线人员，最了解业务的人，应该是最懂业务逻辑的，侃侃而谈，我要一个什么明确的功能。
很多时候，我们因为甲方太强势，依赖于甲方业务员的最后的验收报告，傻傻的给他们做了——实际上根本不能解决他们的实际问题。
他们不知道这个业务对企业管理有哪些提升价值，他们提出来的90%的问题只是业务数据展示要清晰，方便调取他平常工作中excel中记录的数据，还有就是操作要在系统上进行，会比手工更方便一些。
产品经理会认为有些详细数据，可以放到详细里去，主页面只保留基本核心数据展示，这样保持页面整洁，而且也不用滚动条上下，左右滚动；同时不同的数据业务展示在不同的模块中，是合理的。
但是业务如果不给他做一个一下子就能看到全部数据的页面，会跟你争的面红耳赤，直接提出没有满足需求，系统不好用。他们不能理解为什么这么一个简单的功能就是不给我做。
当然业务人员很多都是只站在我的业务层面上思考问题，不一定会关注产品宏观层面的价值、业务流程的标准化、管理规范的问题等。
比如：真实目的是要做一项数据统计，但提过来的需求只是某个页面加个导出功能，或者某个列表加个什么字段之类的。最后我们是每个页面都有个导出功能，也是无语了。
我们做实验室，好多平台做实验，每个平台都有自己单独的业务管理员，每个平台实验的某一个步骤也是单独的一个业务员，在单独沟通的时候，他也只会说我负责哪个步骤，就完事了。
比如：一个单独的DNA提取，提取的需求很简单，把提取数据导入进来，保存提交就完事了。他不会考虑你如果后面的其他平台的实验，提取需要区分是后面一代实验做的，还是二代实验用的。
比如：建文库失败，要重新提取，如果样本没用完，如果第一次提的数量不够，还可以再补提，剩余样本量要保存还是处理掉。这些问题也是后面慢慢后面挖掘出来的，但是耽误的周期实在是太长了。
一开始我们不了解业务，听他们讲，跟他们一个个沟通后，一个版本出来后，导致我们只能维持他们70%的情况，还有特殊30%的情况，根本没有办法满足。
但他们并不能理解做产品是有迭代的，以为产品上线和传统企业的交付一样，一次性做完形成最终版然后给他们用。
——反正没100%满足我们的业务，就死活不用。
产品从0到1的过程我们会规划MVP，先上线基本功能并持续迭代，但他们看了会说这个怎么没有我要的什么什么功能，一定要等我们把他们要的都做完了再开始使用。
改变他们的习惯真的很难，尤其是线下操作已经成熟了，反而说我已经有办法处理这些问题了，不理解我们为什么还要去改这些功能。
尤其是他们习惯用传统excel来记录数据，安排任务的时候，打印出来审报告的时候，你让他一下子用系统，根本就不适用，还不如用excel来的方便。
最后系统上线后，评估系统竟然做了一个统计：80%操作人员不想用系统——这个数据我们自己都惊呆了。
明明他们的业务逻辑至少95%我们都包含了，花了这么多时间调研/开发，都已经做成了行业的专家了，而且我们的系统已经这么复杂了，功能这么全了，为什么还要用这么low的方法工作？
这个结果让我们惊呆了。
在经历了这个项目那么多业务人员的对接过后，含泪总结了下几点教训：
一、自上而下，梳理需求
多跟一线沟通，没有错，这个时间不能省，但是首先我们沟通的是高层，最好是懂互联网产品的时候。
我们需要知道他们企业为什么要做这个系统，主要要解决他们企业的什么问题，现在企业最大的问题在哪里，在3-5年里，企业的发展方向是什么。
我们应该怎么做，能帮到企业解决这些问题，我们优先要解决什么问题，哪些做了后还需要扩展。懂互联网的可以节省一大部分沟通成本，甚至能描绘出具体的使用场景。
接下来一定要找部门经理对接，他们对整个部门的业务是最熟悉的，而且会有跨部门的协作。
对部门业务员的整个流程，会站在整个部门的发展角度去说，这样比较全局，能清楚的描述一条完整的流水线，主要还有哪些异常情况的处理；哪个流程之间有不一致想法，他都会去协调。
最后是一线人员，慢慢跟你讲业务细节，怎么样能把提高他们的工作效率，怎么样提高他们的用户体验。改变了之前的习惯后，会得到什么好处。
当然这边一定有工作流程图。
二、走进实际业务中去，别光听他们说
别老听他们讲，甚至让他们写，谁知道他们写的就是你理解的呢，一千个人还一千个哈姆雷特呢。
每个人的专业背景不一样，认知不一样，性格不一样，表达方式不一样。
对于同样一个需求，我们走进他们的实际业务中去，做一次角色扮演——我是这个岗位的，我是这么做的，有没有更好的解决方法了。
只有了解他们需求的本质，然后想一种更好的方式满足他们的需求，并且可以直接告诉业务方我们方案，以及这样做的好处，相信他们不会拒绝。
了解到一定程度后，我相信产品经理一定比他们更专业，考虑的细节比他们多，简单的问题他们想到了，我们早就帮他们解决了，难缠的问题他们没有想到的，我也帮他想到了，还帮他想到了一个好的解决方案。
这样才能让他们信服——人只会听他们更厉害的人。
当然这变一定要有文档和原型图。
三、划清边界，多保持沟通
合作做一个项目，是为了共赢，甲方提高的工作效率，解决了管理问题。乙方得到了回报，并成为了这个领域的行业专家。
但是做项目立项的目的就是项目的周期，成本、预期、风险控制等，任何一项延期或者超出预期，都可能使整个项目失败。
这个时候很关键，一定要通过建立本期项目目标和价值来引导用户确定项目范围，如果涉及到高层汇报，就一定要协调本公司的高层参加，通过高层对话最终确定项目范围。
除了把人管理好，最重要就是要控制需求，防止需求蔓延，引发大规模的需求变更，控不好需求已成为项目失败的关键因素。
我们做的这个项目，到后来，业务人员不断的需求变更，不断的发生需求增加，导致双方都很累，产品就成了被客户和开发人员喷的对象。
当然，市场是不断变化的，有可能我们在开发的时候，市场已经悄然的发生了变化；变更可以，但一定要核算成本，不然客户和技术都不会承认，那么注意这个锅就是产品的。
交付一定要需要签字，才会引起重视；有这么一个形式，才会把责任落实。
啰嗦的这么多，失败的产品做的比成功的多，下期再分享一个C端的失败案例，请各位同行大家指正。
作者：丁小彧
