失败之路 - 医疗初创公司的九死“一生" (Part 3)
Part 1&2的链接：
失败之路 - 医疗初创公司的九死“一生 (Part 1) - 简书
失败之路 - 医疗初创公司的九死“一生" (Part 2) - 简书
关于产品研发
关于初创公司研发的几个大的阶段
首先是演示版阶段，这个阶段的目的是proof of concept.唯一正确的方式就是在最短的时间内，以最小的成本，来证明正式产品最核心的功能。要做到这一点，包含几个要素。首先，要对目标产品的核心功能有非常清晰的定义。一个产品的核心功能通常就是一两句话就能概括出来的，如果你洋洋洒洒讲了半个小时还没讲完，那肯定是扯淡。
然后就是团队，此时的团队就是能解决核心技术的少数那几个人。
在开发方式上，要让他们专注在写代码上，所有的文档和研发流程都不是必须的。但注意这一条仅适用于这一阶段，而且是在你是在没有钱找到一个有产品经理经验的人的时候，不然可以产品经理一个人先并行准备文档。
前面说过，这个阶段要尽量快，团队全职的话，3个月以内是最好的。但是请注意，要实现快，重点不是让程序员不睡觉。实际上，程序员什么时间工作和休息，应该很大程度上由研发团队自己决定和内部协调。要实现快，根本还是在于对核心功能的清晰定义，并且公司的其它任务都不要干扰到开发。这里就是取舍，抓住对核心的，其它的都放在后面。
演示版完成后，尽快拿去给少数几个重要的，你最信任的，能给你专业意见的人去看。但是这里又要注意，你找的人要真正能够跟你说实话。。。如果你跟他有其它利益关系，他会不会跟你说实话，这在中国文化里就是个问题。这个你细细品。。。所以，有的时候，你找个行业大牛，还不如去找一个跟你没什么利益冲突的，了解具体工作的人。
然后是正式产品研发阶段。这一阶段的重点是不断平衡开发进度和结果可控之间的矛盾。如果演示版阶段没有这么做的话，这一阶段需要开始有最核心的研发流程：需求-开发-测试，然后是下一个版本的迭代，又一个需求-开发-测试。。。但是注意我这里说的研发流程，并不是大公司那种大而全的流程，所有研发文档标点符号都不能错才能开始写代码。。。那样就是流程偏离了开发任务的根本目的，因为流程是工具，更好的完成开发才是目的。这又是一对矛盾，解决矛盾需要的是平衡和经验，另外也要考虑团队对研发流程的认知经验。很多初创公司的开发，虽然个人技术能力很强，但对于正规的开发流程了解并不多，甚至国内很多成立多年的公司这方面做的也不好。
这一阶段仍然要围绕开发现有的习惯和认知去工作，报证他们把至少90%的时间花在写代码上。
我的具体作法是在这一阶段放弃给开发讲任何不必须的开发流程的抽象概念，而是从能做的具体工作开始，比如我写一个需求列表，可以说这是我们下一步的开发任务，计划什么时候完成。同时需求可以在开发过程中更改，跟代码一起迭代。此时项目经理或产品经理都要每天和开发一起解决问题，一旦发现有些技术问题可以通过调整需求来解决，这是可以接受的。
这一阶段的设计文档我也不会强迫开发去写，我自己可以写，形式也不重要，可以以任何方式记录下来。只要抓住最核心的技术问题写清楚。
但是，这一阶段唯一不可妥协的，也是老板最容易忽视的，是一定要引入一个独立于开发的有专业经验的测试。测试对产品和产品经理负责，是保证开发结果符合需求的闭环环节。
没有测试，谈开发版本开发完成了就是然并卵。
而这一环节也是初创公司最容易忽视的，因为不产出代码，而且看上去还拖慢了研发进度。但是这个成本和慢却是必须的！
为了说服老板招一个测试，我甚至会承诺人来了可以同时干别的岗位。。。将来可以出去做售前，给公司赚钱。。。
当然，在测试的具体执行上，仍然需要灵活和平衡，对测试发现的问题做细致的筛选，把优先级低的问题放到后面。。。实际上，操盘水平高的时候，测试并不会拖慢研发进度，而长远来看，必然是大大的降低了产品不按时交付的风险。
最后一个环节，产品释放到市场上，并不代表研发的完成，而是新的轮回的开始，甚至要面对更大的压力。因为产品还要持续改善，而且一旦到了客户那里的真实应用场景下，发生任何问题的成本以及快速解决的压力都比前面的阶段更大。这里又要call back到前面说过的，为什么测试是一个个事半功倍，必须重视的环节。研发阶段测不到的问题，到了客户那里，付出的代价就是成倍放大的。回到市场release后的阶段，这一阶段研发团队面临的冲击可能远远大于前面的阶段。产品出来了，老板会在心里对研发过程进行“复盘”，特别是成本核算，然后根据复盘来调整研发团队。这时候又是看人品，经验和价值观的地方。我亲身经历的是9月份产品出来，10月份我带着产品去展会发布，一边解答客户问题，一边手机看到研发和老板在家里打架的邮件，然后就是研发离职。。。
究竟发生了什么？
在一个公司没有产品可卖的阶段，研发就是公司的宝。在产品出来以后，老板一复盘，发现居然研发成本这么“高”，当然实际老板没有相关产品的研发经验时（这里又对应了我前面Part 2说的对公司创始人的要求），也不知道什么是“高”，什么是“不高”。另外，人品，用人朝前，不用人朝后，过河拆桥，卸磨杀驴，过去为一些小事看不上眼，为了产品还没出来，忍了。现在产品出来了，能开掉省钱的就开掉。然而，即使不从人品角度来说，这个阶段虽然产品上市了，但是研发的工作并没有结束，后面大量的维护，升级都需要直接参与过产品研发的人员经验，开人换人都不是时候。可见，无论是做人角度，还是做事角度，过河拆桥怎么说都是目光短浅，格局狭小的做法。
另一种比较好的情况。
产品出来了，研发团队稳定。公司发展的需要，开始上新项目。这里最好的办法仍然是依赖原有团队，辅以新人，逐渐过渡。这时实际压力在研发团队身上，但是从公司角度，保持了有产品经验的团队，效率才是最大化的。
关于研发团队
技能角度，这就像一个拼图游戏，但是你总要以自己公司的方式拼凑起团队所需的各项主要开发技能。实际情况是很因公司而异的，要使用各种方式，包括外包，实习生，劳务，兼职。但核心都是让你需要的人花时间在你的实际产品开发上。
工作方式上，好的研发希望专注在他擅长和感兴趣的开发工作上，“其它”问题都会转移他们的注意力，所以管理的目的也应该是让他们尽量专注在开发上。但是这不是说把每个工程师锁在他们的座位上。而是允许某种程度上的研发团队自治，这包括何时开项目会，何时哪些人要参与哪个具体技术问题的讨论，何时需要代码审核。要做到这点，首先你要雇来优秀和值得信任的人，然后老板要以某种方式让老板自己能信任自己招来的人。具体方式又是因人而异的。如果你懂产品，那看测试结果和demo.如果你懂开发，那看设计文档，随机选择参与一场技术讨论。如果你都不懂，那找一个你信任的人来管理研发。如果你谁都不信任，自己又不懂。。。那请你再次去看Part 2对公司创始人的要求，然后再考虑一下自己是否够资格创办一家技术公司。
另外一个很重要的事。好的研发通常是对自己的技术发展有追求的人，所以我们会有一些定期的新的技术方向的分享，结合开发工作。时间不需要占用太多，但会提高员工满意度，而且也会提高团队之间的沟通协作程度。
