去年,我们要让软件开发团队管理上台阶。

  我们由于处于企业管理软件开发领域,而对日外包大部分接的单子都是管理软件之类的单子,但是人家的项目管理、进度、质量都比我们好,如果他们再配合管理咨询公司作为合作伙伴,再加上大规模的服务呼叫中心,像我们之类岂有出路?

  于是我们想到了引入对日外包的开发过程管理。

  大家一想起对日外包,想到了大量的文档和大量的代码工人,想到了详细设计说明书甚至到函数级、伪代码级。

  要不要引入的时候,我们内部也做了争论。觉得对日外包,人家接的单子额比国内客户大,所以也能招聘大规模的员工,而且对日外包,日本人是很理性的看待项目周期的(国内客户要求一个月开发完上线),而且日本人都做了半年到一年的调研和设计分析(国内调研几乎只是一个上午,坐在一起瞎聊,根本不成方法)。所以对日外包不适合咱们。咱们没有钱招聘一定数量的人(即使我们只需要普通员工,而不是人才,我们也没多余的钱),当然我们也无法分离那么多专职的项目管理、开发、测试、文档、配置管理岗位。我们的客户对于软件的认知决定了我们无法在调研、设计上下太多功夫(单子额那么大,客户认为软件值那么多钱,当然无须对软件生产各个环节进行重视)。

  不过,我还是坚持进行引入。是骡子是马,咱们拉出来遛遛。还没遛,说不行。这不是小时候的小马过河了么?

  引了进来,合作伙伴给我们派了一位质量控制部的人员。

  一入手,发现有个很关键的问题,方法的源头。

  因为对日外包,都是接单生产,主要是编码、测试,保证生产进度和质量要求。但编码之前的所有环节,对日外包公司并不清楚。他们只知道拿人家给的设计书开始coding,设计书怎么来的,前面环节产生过哪些文档,不清楚。

  幸亏我们过去有系统的调研方法,从调研描述现状、然后分析优化的组织结构、工作流程、考核报表、岗位职责四大块来描述需求。客户优化后的流程、工具中包含手工纸张信息、EXCEL信息、软件信息。