2021年——项目开展中的工作衔接表单

摘要：浅谈一下在2021年中，对于外包软件项目完成调研、开发、测试实施三部分工作信息相互间传递、需求资源提前准备，形成标准的文档。个人发现项目中无论是对外、对内工作一定要形成记录，可以有效避免同样的问题重复出现。涉及到客户工作的时候，优先采用纸质文件可以在项目验收时候为客户提供有效的项目验收资料，也可以促进项目验收进度（注：个人从事医信相关软件，客户多为公立医院）。

相关文章

• 2021年——项目开展中的工作衔接

---

这里简略的介绍一下公司项目类型和各岗位岗位薪酬，有助于下方内容。

项目类型：公司主要包含硬件、软件，面向医院的银医自助、分诊排队、微信挂号。项目软件虽然有很高的相识度，但在各家不同医院都会有不同的需求。这里项目软件个人更偏向定义为外包类型。

薪酬分布：软件产品 = 软件开发 > 软件测试 > 软件UI设计 > 集成实施

---

一、工具介绍

个人采用了腾讯文档，其中主要认为比较实用的几点：

• QQ、微信可以相互绑定，账号数据方便。在网页、微信、QQ中可直接打开，应用方便
• 权限管理，可以某一张表，某一列分配编辑或查看权限
• 版本管理，对于以往的历史版本都可以回退

表单主要为信息的传递、资源汇总。表单涉及到的岗位较多，除了内部使用，有的时候根据实际情况给到客户（如：所需资源需要客户大量的协助工作）。方便的查看，是将这不部分数据未采用项目管理软件的主要原因 。

当然，腾讯文档这个工具也有不好使的情况，
1. 信息通知困难，全靠人力
2. 添加人员不方便，不能直接设定公司架构（注：目前采用一个部门、小组一个QQ群的方式去添加）。

目前主要有 7 张子表单模板通用，分别用处如下表：

项目通用表单作用概述

表名	概述
目录	主要呈现项目名称、项目所涉及的各个部门，小组成员、项目包名
事前准备确认表	主要呈现项目开展硬件设备所需电、网、安装环境；软件所需诊室分诊
硬件清单表	主要呈现项目中硬件设备现场摆放位置，设备分布单元楼栋，楼层区域。设备选型，设备现场安装方式
软件清单表	主要呈现项目中软件部分功能需求清单。此处为已将合同或客户的需求转后的输出。按照模块进行填写，此模块也为软件项目管理软件任务模块
资源清单表	主要呈现项目开展、实施中所需的资源
需求变更表	主要呈现项目合同签订后客户提出软件、硬件调整需求调整、变更或需求新增。
项目实施报告	主要呈现项目实施过程过程中实施人员每日实施过程进度及信息反馈

---

二、表单详情

往下依次详细描述表单填写要求及更新责任人

2.1 目录

表单为软件部门经理主要更新，表单主要为汇总性质，人员分配 。

格式字段描述：

名称：名称由两部分构成，上部分为签单公司名称，下半部分为实际使用方名称。
1. 两个名称利于解决同一家签单公司或使用方多次签单。
2. 对于不同的人来说的，特别是跨部门，都能按照自己叫法确认出是哪个项目

组员：按照不同部门，将相关成员添加进来

项目名（Java）：此处主要针对后台的包名，将不同的行业形成按照统一标准进行设定。当前采用的为 地理区域+行业类别+使用方名称。医院 = hosp ，政府 = gov ， 其他 = other。
1. 谁开发项目都有统一的名称，避免谁开发后期就需要联系的情况

后台登录地址：为项目在现场实施后的地址，有时间其他同事售后时，不能第一时间掌握后台地址。此处一般为软件测试在协助完成后进行填写。至于为什么写在此处，未写入实施报告中，不拓展开来。主要因为目前很多项目为集成实施同事前往现场，然后软件测试进行软件安装。

账号密码：为客户现场后台登录的最高管理员账号密码

当前状态：呈现项目最新进度，使得各成员知晓目前自己是否应该关注，解决腾讯文档无法指定人员通知

表单链接：此处未使用，为以前在设计时增添的一个小功能，可以便捷跳转。目前腾讯文档无法跳转

2.2 事前准备确认表

表单为售前（销售）技术支持填写

此表单在实际运用过程中，并不理想。未正式使用，主要有以下几点：

• 售前(销售)支持，主要为销售成员，对实施所需的集成环境掌握不佳
• 很多项目并未前往现场
• 项目签单一般为新建院区，具体细节没人能落实

基于以上内外部原因在实际中，此表单并没有采用。而是将其工作部分分拆、部分滞后，此处也导致存在一些莫须有的工作量（注：此处站在技术岗位思考，不考虑前期销售岗位），如下：

• 在客户实施电网情况下，现场并没有完成电、网，公司实施同事就前往现场，增加不需要的等待时间
• 原客户实施电网工作，落到公司。从而进行二次销售沟通或者义务实施
• 未知墙体类型和安装方式，在安装时，存在墙壁开槽埋线然后在修补墙、未携带设备壁挂机、天花板打孔等问题
• 没有固定诊室，设备上的亚克力板固定文字内容错误，形成二次销售沟通或糟糕的客情关系

格式字段描述：

这里没有跟多的详细描述，表单为选择居多

2.3 硬件清单表

表单主要为售前（销售）技术支持和硬件两岗位同事共同填写
售前（销售）技术支持：按照楼层区域的分布，将硬件设备对应的编写上
硬件：根据BOM单，将设别的具体参数填写上

格式字段描述：

楼层：区分院区内的不同楼层或不同院区，可以填写为 xx院区—xx楼—xx层

区域：在同一楼层，存在不同区域，如医技中的放射、彩超都会有主任，分别进行管理

型号名称：设别在公司的型号，有与在软件UI设计做提示的时候沿用正确的图片

数量：同一区域，一种设备存在多台

类型：配合设备型号使用，一台设备由多部分组成，处理主机外，会存在一些外设（如：热敏打印机、身份证阅读器）

模块：配合类型使用，对类型进一步细化。在软件开发过程中，需要使用到设备系统、采用的CPU厂家、外设具体型号等。

概述：配合模块描述，具体的参数或者厂家型号

安装方式：设备的横屏或竖屏，才有何种安装方式（如：壁挂、粘贴等）

详情：由于对区域整体描述

注意：在每一个区域末尾一个栏备注，用于对该区域进行一些特殊事件的描述。

2.4 软件清单表

表单主要为软件产品进行填写

格式字段描述：

产品名称：指软件名称，如当前的医院门诊分诊排队、自助服务终端、掌上医院（微信小程序）

功能模块：软件的模块，如【门诊】-【医生分诊】、【门诊】-【医技排队】

系统名称：对功能模块进一步拆分，这里采用系统二字，主要原因分拆结果为签到机、医生工作站呼叫器、医生门诊屏一类

优先级：模块功能那个优先开发，存在一个项目一部分一部分的分步上线

后续几个字段不在赘述，此处落已到项目管理软件中，如客户需要时再手动进行填写

2.5 资源清单表

表单为软件测试填写

格式字段描述：

类型：类型分为4类，如下：

• 内供设备类：公司内部提供的设备
• 基础类：如服务器，远程跳板机
• 对接类：接口对接一类（含现场环境部署问题）
• 外供设备类：医院或签单公司提供的设备，如就诊卡、刷卡器一类
• 
  
  名称：所需资源名
  
  数量：比如客户提供有硬件设备，在次记录一下，便于后期归还
  
  概述：对资源进行一个描述使得更容易理解和对重要事情进行备注。如微信公众号的自定义信息通知模板为3次/月。
  
  验证类型：主要分为3种，如下
  • 事前：在合同签订期就可确认，如支付
  • 事中：按项目流程，需要通过后才能开展下一步工作
  • 事后：可以交叉，如果开发过程中在确认资料验证
  
  提供方：资源提供责任人
  
  是否符合交接：资源是否按照要求提供
  
  验证人：资源提供后，谁进行验证确认
  
  提供时间：资源第一次提供时间
  
  最新更新时间：完整验证通过的最后一次时间，每验证一次更新一次
  
  当前状态：对资源进行结果描述或存储如远程的账号密码等
  
  地址：对需要存档资料的存档地址，此处有一个专门的共享文件交换服务器

2.6 需求变更表

表单由软件产品负责更新

格式字段描述：
这里抽取其中几个重要字段描述

版本号：此版本非软件的版本，为产品所使用的需求版本。采用 Vx.x.x_时间格式，此处只写 Vx.x.x 即可，在项目管理软件中写全版本格式。

产品版本设定规范

位数	名称	描述	情景
第一位	主板本	重大修改，重写，里程碑	【里程碑】【重大修改】 【分期开发】
第二位	次版本	显著增强，功能变更较多	【新增功能】【删除功能】
第三位	修订版本	局部修正，BUG修正	【优化功能】【局部修改功能】 【界面优化】【BUG修正】

状态：状态主要4种类型

• 确认中：产品经理正在同项目经理开展工作
• 不处理：确认对需求不做处理
• 完成：完成对需求的处理（如：开发，硬件新增）表示需求完成
• 取消：对已确认需求，如果在实施中时，取消需求行为状态标记。如果需求为完成状态，则需新建需求

提出者姓名：主要指需求为谁提出，依次统筹出项目中主要能做决定的是哪些人或岗位

类型：标注提出的需求属于什么，主要有4中

• 新需求：预定范围外的新增需求
• UI优化了：对界面简单调整，如修改颜色、logo
• 流程优化：对流程优化，比如取消某种认证方式
• 问题绕行：问绕行主要指流程出现重大问题，无法直接修复，而采用其他方式完成

影响描述：这个需求对于实际业务的影响大小，判断是否为个案，利于在后期版本或项目中是否提前纳入。

2.7 项目实施报告

表单为现场实施的集成部门同事填写，表单为模板，持续进行复制更新

此表单实际运用过程中未使用，主要有以下几点：

• 集成同事以硬件为主，大多数项目有软件，实施较困难，存在集成人在现场，软件测试进行远程安装
• 涉及到软件，需要多次前往现场，每次前往的人员不固定

缺少实施报告这部分内容，引发的其他额外工作有以下几点：

• 依赖性：形成了坏的情况，集成同事在现场开远程，然后等待软件测试安装。人数上软件测试小于集成，导致浪费很多等候时间，特别是医院17:30一般就下班赶人
• 随意性：软件测试在项目都会自己现场进行安装，在测试工作时，不严谨，等后期远程安装，直接现场测试
• 信息交换差：缺少整体的实施计划，很多东西不齐全已到现场或到达现场后“无事可做”
• 重复沟通：遇到人员更换时，往往医院、内部都会小范围重来一次，交接人对具体情况不清楚
• 及时性：不清楚当前项目什么进度，何时能完成
• 不可控性：现场给到客户一种内部人员都不清楚的状态，客户就随意提出需求。因此也给到客户一种不重视感觉，逐渐不配合情况

---

三、遗留问题

以上内容为整个项目表单，其中可以发现在跨部门衔接不理想，和形成各表单内容确认后，使得项目存在以下问题：

• 只能开展部分或无需求的项目不能有效推进，此类项目越累积越多，甚至造成返工、退货
• 测试实施界定存在问题，甚至存在相互推诿
• 实施过程中，没有具体的周期计划
• 对项目成本核算和项目奖励划分缺少强有力的有效数据