公司成立初期,我与合伙人商议以上什么样的方式完成产品验证版本的开发最合适。当时我们基于以下原因,决定将产品外包给我合伙人的一位友人的公司做:

  • 我们没有工程师团队
  • 他们有专门的软件外包开发团队(开发经验相对丰富,服务水平相对专业)
  • 报价合理
  • 工作量申明符合我们的上线要求

由于曾长期担任乙方项目管理者角色,我深知需求梳理质量对项目质量的深远影响,哪怕采用敏捷开发模式,没有对产品功能和业务流程的细致梳理,产品最终也很有容走偏甚至失败。于是我们要求他们能参与到需求梳理工作中来,并协助我们挖掘需求。很遗憾,由于种种原因,我们的这种要求被他们委婉地拒绝了,主要的理由是人手不够。当时我心里嘀咕,“这完全不是做乙方的姿态嘛!”。由于进一步商议也没有什么进展,加之当时也没有其他合适的团队可供选择,我主动承担了主导需求梳理的任务。经历了几十次的讨论和打磨,我们花了一个月时间整理除了一份比较详尽的需求说明书,并对UI设计也提出了自己的要求。尽管很多细节上仍需进一步探讨和明确,但用作系统设计和基础应用架构的搭建我认为绰绰有余。为了确保能及时发现并解决项目推进过程中的问题,我还提议成立一个项目协调小组,定期进行沟通和讨论。我还提议让我们的业务专家驻场,协助工程师更准确的理解一些功能难点的设计与开发,并建议他们采用持续交付的方式让我们对产品进行审视,以便于对某些功能设计进行及时调整。又由于种种原因,我的提议并没有得到乙方的积极响应。原本乙方应该尽力配合甲方的需求开展工作的模式,变成了一种广泛商议性的“合作”模式,这让我对这种糟糕的服务关系感到很不满。尽管站在乙方项目经理的立场,我可以理解他为什么作出这样的反馈,但他们并没有呈现出基本的专业精神来。究其原因,主要有以下两点:

  • 粥多僧少。当地专业的外包团队较少,大都是散兵游勇,所以他们有底气可以挑选项目,时间一长,服务意识自然就下降了。
  • 友情出演。对于他们来说,我们的项目即不是雪中送炭,也不是锦上添花。权当我戏精上身,大胆演绎对方内心独白的话,既是:“咱有零星闲散人力,掉配出来帮他们搞一下吧。”

出于对这种服务关系的不满,以及对项目功能设计复杂度的担忧,我开始考虑是否应该自己组建团队进行开发。当时我们并没有放弃与他们的合作,一方面,合伙人积极协调,另一方面我们也在寻找其他的合作伙伴,但效果都不甚理想。为了更好地传达我们对交互设计的要求,我决定花一点时间自己做一个原型。我花了一个周末时间学习了Angular 6,并花了一周的时间搭建完成了一个原型。这个原型本应该交给乙方来讨论UI设计以及他与业务流程设计的关系。结果约了一周才促成了一次简短的沟通会,而且会上并未达成任何会议成果。

我花了一个周末的时间思考了自己组建团队的利弊,并快速评估了我倾向使用的技术的学习曲线和成熟度。与合伙人商议后,我们启动招聘,开始招募工程师组建自己的团队。两个月过去了,我们拥有了一只小型工程师团队:2个前端工程师,2个后端工程师(包括我)。并完成了验证版本80%功能的开发。计划在接下来的一个月中完成所有开发和测试。尽管这个过程中,我要付出比外包出去多几倍的时间和精力,但这个决定所带来的益处也是显而易见的:

  • 由于我可以很快地找到所有的stakeholder来讨论产品功能设计,沟通成本大大降低了,也更顺畅了。这带来的是对我们对产品呈现方式设计更具主动性。
  • 由于我们自己就是产品拥有者,剔除了外包开发模式下甲乙方的对立关系,我们可以更积极主动地进行产品的设计探讨。
  • 尽管自建团队增加了公司运营的成本。但毕竟我们日后也需要有自己的研发力量。通过一个产品去打造一个技术团队,让团队与产品一同成长似乎是一个不错的选择。
  • “迭代开发,持续交付”这种小步快走的模式,让设计缺陷和问题更早地被暴露出来,这样风险也更可控。

一句话总结:我很庆幸自己当时选择了自建团队做产品验证版。

发表评论

电子邮件地址不会被公开。 必填项已用*标注