数字化建设从不打乱仗开始

当前企业在进行数字化转型时，一支专业的技术团队是标配，特别是规模企业会同时拥有IT运维及软件开发两支队伍，尤其是软件开发团队是数字化建设的主力军，肩负着企业个性化场景的软件开发重任，但在实际的管理工作中，会存在以下痛点：  1.正常开发节奏经常被打乱；  2.人员配备低，导致大量开发任务排队；  3.需求总是被业务反复推翻；  4.开发的软件应用率低；

以上问题直接导致的后果就是： 

第一，虽然开发团队加班加点，但仍赶不上业务需求变化的速度，搞的开发团队疲于奔命； 

第二，软件需求反复推翻，软件架构反复设计，搞的开发身心疲惫无成就感；  

第三，需求大量排队，给业务部门造成的印象就是开发部门效率太低； 

第四，开发的系统不应用，让开发部门价值难以体现，价值存在感低； 

以上这些都是企业数字化转型过程中的一个典型场景，很多企业以为自己成立了软件开发团队，就可以解决任何数字化系统的难题，但岂不知数字化转型是一个系统工程，涉及技术更涉及业务、运营，如果数字化部门不能很好的把控业务需求、合理推进工作任务，缺乏管理意识，数字化运营意识，那么就会陷入“打乱仗”的死循环中。

今天老杨就来讲一讲开发团队如何避免打乱仗。    我们知道企业内部开发一款数字化系统需要经过如下环节：项目立项、方案确定、系统开发、系统测试、上线运行五大环节，而每一环节都有若干需要完成的工作，这些细小环节工作构成一个系统化的标准工作流程，如果这些细小环节未实现精细化管理，那么可能引起连锁反应，导致整个项目处于混乱状态，这就是打乱仗的开端。那么开发团队如何实现过程管理精细化呢？

1、项目立项阶段： 立项是项目的开端，决定是否做与不做。但在此环节上技术部门容易被业务部门的“伪需求”所迷惑，此时的需求可能是某一个部门人员或某位领导的一厢情愿的想法，缺乏部门验证，如此时开发部门不加验证，就匆匆接下该需求，那么极有可能有推翻重来的可能，所以此时开发部门应严格遵循三不原则： 分管领导不知情不做； 业务需求不明不做； 没有业务骨干参与不做； 在与业务部门确定好系统需求后，开发部门应出具业务需求文档、系统功能清单、系统工时评估表并与业务部门达成共识，此时不要忘记还需要业务部门分管领导签字确认。这就是一个标准的立项过程，开发部门一定要注意，不要以为自己是企业内部的部门就将以上工作忽略，否则日后一旦与业务部门产生分歧，将无证可依，成为名副其实的“背锅侠”，同时软件开发工时评估表也是开发部门价值的体现，要让业务部门知晓一款业务系统上线需要投入多少人力成本，让业务部门在第一时间珍惜数字化建设成果。

项目立项阶段标准文档内容： 《业务部门原始诉求沟通记录》；    《需求文档》；    《工时评估表》；    《系统功能清单明细表》    《项目立项审批表》

2、解决方案确定阶段： 此环节包括以下工作节点：软件原型设计、需求文档编写、技术文档编写、UI设计；只有业务部门需求方案确定了，开发部门才能进行这一步的工作，切忌在业务部门需求反复期间就轻易做解决方案，此时开发部门要沉的住心，宁愿与业务部在需求方面多花时间沟通，也不能在开发期间反复。    为什么开发部门会打乱仗？解决方案确定阶段就是开端，企业的开发部门往往以人手不足为由不做相关文档编写工作，如业务需求文档，内部工作均有口头传达为主，这样造成的后果就是对内用户需求交接不清，造成后期开发工作反复，对外与业务部门需求沟通存在理解偏差风险，当后期用户对功能开发提出质疑时、内部开发人员工作反复时，各种扯皮随即而来，混乱开始了。    所以开发部门一定要按标准化管理推进工作，不能以工期紧、业务部门催的急为借口打乱仗，在解决方案确定阶段需要提交的文档有： 《系统原型设计》  《业务需求文档》  《后端接口文档》  《数据库文档》  《平台架构设计文档》  《UI设计》其中《系统原型设计》、《UI设计》一定要业务部门负责人签字确认。

3、系统开发阶段： 此阶段很好理解，就是软件开发工程师按照产品经理提供的系统原型设计及UI设计师提供的UI设计进行软件开发工作，但此时对项目经理的把控能力要求很高，在系统开发阶段，尤其是企业内部，业务部门会产生这样的假象：以为开发部门是企业自己的，不会产生费用，就对需求反复修改，甚至朝定夕改，让开发部门疲于应付，所以前期的需求确定在此时显得格外重要，但业务部门在软件开发期间修改需求也是时有发生的，如何把控需求，项目经理此时非常关键，一方面要满足业务部门的需求，让系统在上线后能应用起来，另一方面要控制业务部门的需求无限发散，让系统上线遥遥无期，因此项目经理的沟通、规划能力十分重要。    同时对团队内部项目经理要合理分配工作、安排进度，有条不紊的推进工作，按期交付产品，所以在此阶段需要产生的管理文档有： 《任务进度计划表》  《任务分工表》  《需求修改确认表》    系统开发阶段，如控制不好，同样会打乱仗，现实中，开发部门会同时进行多个项目的推进，如不进行科学的管理，会陷入对外需求变更管理混乱、对内工作安排推进混乱。

4、测试阶段： 测试关乎软件质量，但在企业开发团队中会存在测试人员缺编、人手不足的现状，导致一部分开发人员也担负测试的工作，但此时标准的测试工作流程一样不能少，上线前的测试报告一样不能少，此时需要提交的标准文档很简单，就是《系统测试报告》。

5、上线阶段： 软件通过测试后，开发工作告一段落，接下来就是重要的时刻，用户体验上线阶段，此时开发部门也马虎不得，不能以为是企业内部人员，直接将系统网址提交给客户就行，随便培训一下就草草交付，相对于技术，业务部门是非专业的，需要手把手的功能培训，看系统功能是否匹配用户需求，并做好用户新需求记录，此时需交付的文档有： 《用户操作手册》  《培训文档》  《培训记录表》    此时开发部门还要关注用户应用情况，对用户的相关问题进行跟踪、反馈，唯有如此数字化建设工作才能有条不紊顺利的开展。    综上所述，在企业内部一个业务需求从提出要系统实现要经历：立项、方案确定、系统开发、系统测试、系统上线五大关键步骤，每一个步骤要实现标准化的管理，才能保障过程管理不混乱、不打乱仗。

要记住：任务多、工期紧、人手少均不是打乱仗的借口，不甩锅、勇担当才能打硬仗，严格执行标准化、制度化、流程化才能打胜仗！