|
项目管理者联盟
在写需求的工作中，“写”成文字并不是最重要的，决定需求的实质内容才是最关键的。谁“写”需求，实际上是指由谁来决定需求的内容。同时，需求编写的过程，实际也是业务与技术互相沟通理解、达成共识的过程，需要业务人员与技术人员共同完成。项目管理者联盟
业务需求与软件需求项目管理者联盟
业务需求是业务层面针对各种经营管理问题的解决方案，需要在各个相关部门之间达成共识，所以当然应该是业务方的人员来写，而且只能由业务人员来写。在写业务需求的过程中，也需要技术人员参与其中，主要是协助提供技术可行性的支持，保证所提出的业务需求在技术上是可以实现。从技术部门来说，要能确定业务需求的技术可行性，其实就已经形成了初步的技术解决方案，该方案是要符合应用架构整体要求的，在技术手段上是具有可行性的(包括投入产出的合理性)。也有一种观点，认为在绝大多数情况下需求都是肯定能通过技术手段实现的，所以在编制业务需求的过程中不需要技术参与，这种观点有些绝对化，会妨碍业务与技术双方的沟通效率。从产品设计角度来说，新产品功能在技术上具有可行性是必须的，而不是在形成了产品设计之后才去讨论技术可行性。项目管理者联盟
软件需求是在业务需求确定之后，基于初步确定的整体技术解决方案，将业务需求分解成为所涉及各应用系统的具体软件开发的需求，决定各应用系统需要实现的具体功能。功能需求原则上也是应该由业务人员编写，其中涉及到的业务规则、用户体验等，都应该是业务人员要决定的问题。由于此时软件需求的实现效果受到具体软件技术实现方式的约束，需要业务人员对技术实现方式有更深入的了解，现实中这对于很多业务人员来说是有相当难度的，所以对技术人员参与的依赖度更高，这就更要求业务与技术双方人员的密切沟通合作。在双方的密切沟通中，传统软件工程中的需求与需求分析是可以同时在进行的，实践中完全可以将这两个过程合并，提高工作效率。经过技术部门分析、修正过的需求，最终还是要由业务部门确定。项目管理者联盟
不论是业务需求还是软件需求，不论是传统瀑布式的软件工程过程，或者是新兴的各种开发方法，都需要业务与技术双方就需求达成共识，这一环节都是不可或缺的。项目管理者联盟
实践分享项目管理者联盟
编写需求的过程并不是一个孤立的过程，实际上也是业务与技术互相沟通理解的过程，已经是技术开发的开始。这是我们在实践中设计相应管理流程的主要出发点。bbs.mypm.net
业务部门形成初步的业务需求，技术部门根据业务需求形成初步的技术解决方案，提供技术可行性支持。在技术可行性讨论中，还经常会对业务需求提出优化建议。当技术部门反馈确认业务需求具有技术可行性的时候，意味着整体的技术解决方案也已经基本确定。为此，我们甚至做出强制性规定，业务部门提交业务需求时，必须说明是否已经与相关技术团队做过沟通，否则直接拒绝该项需求。项目管理者联盟
随后，根据技术解决方案确定的各应用系统功能范围，由业务部门与技术部门共同根据业务需求的内容分解形成各应用系统的软件功能需求。每个具体功能的需求，还是由业务部门提出基本要求，由技术部门确认可行性。在双方沟通过程中，把传统软件工程中的需求和需求分析两个步骤合并，最终实际成果直接就是双方确认的软件需求分析。从这个角度来说，由技术部门“写”软件需求也是有合理性的。项目管理者联盟
为了提高需求沟通的效率，尽量减少编制软件需求的工作量，对于已经建立并投入运行的应用系统，我们要求技术部门编制出符合该系统功能特点的需求模板，以此对软件需求给出指引和约束，大大提升了制定软件需求的效率。最为典型的如手机APP，技术框架和风格一旦确定，各项功能都需要遵守，这时就可以通过需求模板的方式，在既定的框架标准下，由业务人员以填空的方式来描述其需求。再比如各种报表类需求，也是非常具有共性的，在开发具体报表过程中，可以将需要业务方明确的各项内容可以形成一个检查表，例如数据范围、报表周期、统计口径、检查规则、展现形式、访问权限等，由需求方逐项给出定义。使用需求模板，不仅可以大幅提升工作效率，对于提高需求质量更是大有益处。项目管理者联盟
成立由业务和技术人员共同组成的需求部门如何?转自项目管理者联盟
可以看出，无论是业务需求还是软件需求形成的过程，都需要业务和技术两方面知识的结合，所以实践中也有单位采取这样的做法，调集业务和技术两方面经验丰富的人员形成一个独立的部门，专门负责编写需求，用组织结构的方法强化业务与技术的结合。我本人并不赞成这种做法，主要有以下几方面原因：项目管理者联盟
1，
从业务和技术部门抽调出一批对业务、技术都非常有经验的人员专职编写需求，这些有经验的人员在原部门中一般都会是骨干，所以这种人力资源要求在大部分机构中本身是不具备条件的。项目管理培训
2，
编写需求的过程实质也是业务与技术的沟通过程，是技术实施部门进行需求分析的过程，是技术开发人员理解需求的过程。负责技术实现的技术部门人员不参与需求过程，客观上割断了这一沟通过程，需要另外的过程让技术开发人员理解需求，这样至少会大大降低软件开发的工作效率。项目管理者联盟
3，
业务会随着市场变化而变化，应用系统架构规划也会不断发生变化，新应用系统会陆续建立，原有应用系统也会不断的技术升级，专职编写需求的人员需要能持续更新相关信息，以保证所编写的需求始终能满足技术可行性的要求，为此也需要付出许多额外的代价(实际上要做到这一点是比较难的)。这个部门的人员一旦不能跟上具体业务或技术的变化，就很可能会逐渐沦为二传手的地位。项目管理者联盟
这种情况下，与其考虑成立一个专门负责需求的部门，倒不如彻底考虑一下应该怎样加强产品管理，是否需要设立一个产品管理部门，如何解决好业务部门与技术部门之间的分工配合。项目管理者联盟
文章首发于乔东老师个人微信公众号：IT管理工匠，专注于IT管理的理论与最佳实践，不断提升IT管理“工艺”，欢迎关注交流。项目管理者联盟 项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
