公司成立初期，我与合伙人商议以上什么样的方式完成产品验证版本的开发最合适。当时我们基于以下原因，决定将产品外包给我合伙人的一位友人的公司做：
- 我们没有工程师团队
- 他们有专门的软件外包开发团队（开发经验相对丰富，服务水平相对专业）
- 报价合理
- 工作量申明符合我们的上线要求
由于曾长期担任乙方项目管理者角色，我深知需求梳理质量对项目质量的深远影响，哪怕采用敏捷开发模式，没有对产品功能和业务流程的细致梳理，产品最终也很有容走偏甚至失败。于是我们要求他们能参与到需求梳理工作中来，并协助我们挖掘需求。很遗憾，由于种种原因，我们的这种要求被他们委婉地拒绝了，主要的理由是人手不够。当时我心里嘀咕，“这完全不是做乙方的姿态嘛！”。由于进一步商议也没有什么进展，加之当时也没有其他合适的团队可供选择，我主动承担了主导需求梳理的任务。经历了几十次的讨论和打磨，我们花了一个月时间整理除了一份比较详尽的需求说明书，并对UI设计也提出了自己的要求。尽管很多细节上仍需进一步探讨和明确，但用作系统设计和基础应用架构的搭建我认为绰绰有余。为了确保能及时发现并解决项目推进过程中的问题，我还提议成立一个项目协调小组，定期进行沟通和讨论。我还提议让我们的业务专家驻场，协助工程师更准确的理解一些功能难点的设计与开发，并建议他们采用持续交付的方式让我们对产品进行审视，以便于对某些功能设计进行及时调整。又由于种种原因，我的提议并没有得到乙方的积极响应。原本乙方应该尽力配合甲方的需求开展工作的模式，变成了一种广泛商议性的“合作”模式，这让我对这种糟糕的服务关系感到很不满。尽管站在乙方项目经理的立场，我可以理解他为什么作出这样的反馈，但他们并没有呈现出基本的专业精神来。究其原因，主要有以下两点：
- 粥多僧少。当地专业的外包团队较少，大都是散兵游勇，所以他们有底气可以挑选项目，时间一长，服务意识自然就下降了。
- 友情出演。对于他们来说，我们的项目即不是雪中送炭，也不是锦上添花。权当我戏精上身，大胆演绎对方内心独白的话，既是：“咱有零星闲散人力，掉配出来帮他们搞一下吧。”
出于对这种服务关系的不满，以及对项目功能设计复杂度的担忧，我开始考虑是否应该自己组建团队进行开发。当时我们并没有放弃与他们的合作，一方面，合伙人积极协调，另一方面我们也在寻找其他的合作伙伴，但效果都不甚理想。为了更好地传达我们对交互设计的要求，我决定花一点时间自己做一个原型。我花了一个周末时间学习了Angular 6，并花了一周的时间搭建完成了一个原型。这个原型本应该交给乙方来讨论UI设计以及他与业务流程设计的关系。结果约了一周才促成了一次简短的沟通会，而且会上并未达成任何会议成果。
我花了一个周末的时间思考了自己组建团队的利弊，并快速评估了我倾向使用的技术的学习曲线和成熟度。与合伙人商议后，我们启动招聘，开始招募工程师组建自己的团队。两个月过去了，我们拥有了一只小型工程师团队：2个前端工程师，2个后端工程师（包括我）。并完成了验证版本80%功能的开发。计划在接下来的一个月中完成所有开发和测试。尽管这个过程中，我要付出比外包出去多几倍的时间和精力，但这个决定所带来的益处也是显而易见的：
- 由于我可以很快地找到所有的stakeholder来讨论产品功能设计，沟通成本大大降低了，也更顺畅了。这带来的是对我们对产品呈现方式设计更具主动性。
- 由于我们自己就是产品拥有者，剔除了外包开发模式下甲乙方的对立关系，我们可以更积极主动地进行产品的设计探讨。
- 尽管自建团队增加了公司运营的成本。但毕竟我们日后也需要有自己的研发力量。通过一个产品去打造一个技术团队，让团队与产品一同成长似乎是一个不错的选择。
- “迭代开发，持续交付”这种小步快走的模式，让设计缺陷和问题更早地被暴露出来，这样风险也更可控。
一句话总结：我很庆幸自己当时选择了自建团队做产品验证版。