物流软件全过程管理办法

Posted 2023-02-02 炼金士

物流软件全过程管理办法

问答

1，为什么项目部名称前带XX？

为了收放自如。

如上图，XX代表软件公司基于业务现状及发展趋势，按照业务类别、业务规模、分布地域等条件，可以（增、减、合、拆）设立1-N多个项目部，以利于业务开展和团队管理。编制无论怎么调整，扩张还是收缩，都不会影响到公司组织架构整体的稳定性。

每个项目部的行为模式和岗位配置基本一致，快速复制没有多少障碍，可从容应对公司的业务扩张。对于业绩好、前景好的项目部，只要增设了销售岗位，就可以直接升格为事业部，或者分公司。

2，为什么产品研发团队要分为三个部门？

为了制衡，避免迷失方向。

闭门造车会带来大方向错误，而大方向错了往往是致命的。由市场、业务、技术三支团队协作研发产品，虽然沟通成本增加了，但在互相制衡下，可以减少方向性错误的发生。

市场上已显露出的或还暗藏着的真实需求和业务变革，交给独立思考的市场团队去发现、把握和引导；新技术、新模式、新业态的不断涌现，需要交给技术性强的专业团队去研究、吃透和应用；业务团队就专注于产品化软件领域模型的分析和搭建，整合市场和技术所提供的资源，吸取各个项目团队的反馈意见，提炼和不断完善可复用组件（/构件）的构思设想，交给技术团队进行论证和研发，为项目团队提供公司级别的可复用组件库，实现软件产品的版本升级换代。

三足鼎立、流水线式的生产组织形式适用于自主研发软件产品的生产过程。三支团队，自成体系，责任清晰，流程清晰，异步衔接，不影响各自的工作节奏。只要互相之间做好沟通协调，衔接好产出和消费，配套上瀑布模型或V型模型等适用于流水线的软件开发生命周期（SDLC）模型/方法，就是一个完美的组合。

对于初创公司，这么核心的工作，老板会亲自下手，就没必要搞得那么复杂了，一个部门就好。

3，如何提升产品研发过程中的沟通质量，降低沟通成本？

流水线式的产品研发过程，团队之间有产出和消费的衔接，短板可能会出在沟通协调上。沟通质量差，带来的是沟通成本指数级的增长，进而影响到研发计划的按期推进。

我们往往习惯于口头沟通。口头沟通虽然直接，但并不高效。沟通效果是受制于双方的沟通能力的，一方不一定能表达清楚，另一方也不一定能被理解清楚，这都会耽误事。所以，任何可以用文档沟通的问题绝对不要用直接面谈去沟通，特别是在团队之间、部门之间的沟通协调上。文字沟通有几个很明显的优点：可查证、可回溯，防止出现浑水摸鱼、遗忘抵赖的情况；思路清晰，文字相比语言更有条理；效率高，不同于面谈的实时性互动，你可以随时随地写上两句，想好了再落笔，写错了有补救机会，也避免了情绪带入影响正常沟通。面谈或开会沟通的目的，除了是为了解决复杂问题进行必要的讨论之外，其余主要是召集起来进行统一的传达或对事务的确认。比如，在需要统一思想或行动时；在需要当事人清楚、认可和接受时；在传达重要信息时；在澄清一些谣传信息，而这些谣传信息将对团队产生较大影响时。所以，团队之间的沟通，首选以文档进行沟通。这样，产品研发沟通质量的好坏，就取决于文档质量的好坏。而文档质量的管控，显然就归在了产品审计的范畴内，并且应该交给独立的质控部门（项管委执行小组和质检部）进行管控，否则是很容易出现扯皮推诿、各自为政等负面现象的。

文档质量的管控，至少有两方面需要关注的。一方面，是否按照相应的文档规范和模板进行编写，该有的内容是否都有，文字是否通顺，无歧义；另一方面，是否文档内容前后一致，比如设计是否覆盖了所有的需求，是否能一一对应得上。至于文档内容的细粒度、可操作性、完整性和准确性等问题，需要借助同行评审、绩效考核、岗位晋升等管理机制进行督促和解决，还有就是相关职能部门负责人对此问题的态度和重视程度，以及他们的对口协调能力。此时，质控部门的独立性尤为重要。否则，下游单位的员工会苦不堪言，无从申诉。而问题堆积到最后爆掉，受损的还是公司。

4，为什么公司组织架构中即有产品线也有项目线？

大中型物流企业的业务往往比较复杂，每家企业的管理模式各不相同，所处业务环境千差万别，作业对象庞杂繁多。如果针对这些企业，事先研发一个大而全的软件产品，或者拿某个同类项目的软件去套用，都会在具体项目运作中带来大量的二次开发，实际产品化率是不高的。即便如此，我们还是可以提炼出一些可通用的功能和模块，以组件（/构件）的形式提供给项目组使用，尽可能地节省他们的项目成本和时间，稳定软件质量。相对来说，开发组件库是件更实际的做法，对提升项目的产品化率会有一定的帮助。为此，我们将产品和项目进行切割，分别独立运作和管理。

如上图，“产品线”是指产品建模和组件库研发的组织和管理形式，“项目线”是指项目管理和系统研发的组织和管理形式。产品线是形而上的，专门研究物流软件的共性，通过领域工程方法进行提炼和构建，产出的是“可复用组件（/构件）库”；应用系统工程是形而下的，直面响应具体客户的业务需求，通过应用系统工程方法，平衡项目的成本、时间和质量，产出的是“应用系统”。产品线为项目线提供产品化技术支持，而项目线在项目实践中为产品线提供反馈和改进意见，双方通过领域模型和组件库等工作界面进行协同互动，不断改进各自的工作。

这里所谓的产品，指的是组件库，及其配套的技术支持，而非商务上的概念了。

5，为什么项目团队不是跨部门临时组建的？

相对产品研发而言，直面客户需求的系统研发，计划赶不上变化是常态。客户的需求往往并不清晰，不够全面，甚至有逻辑错误，特别是在有点规模的项目里。为此，我们在项目实践中往往采用的是快速迭代的软件开发方法，这在业内有不少模型，可以拿来借鉴参考。每一次迭代，要么是细化功能，要么是增补功能，要么是纠正信息传递失真带来的影响，甚至还有需求变更，因为客户的业务要发展。项目团队在与客户不断地沟通、不断地确认和反馈中完善系统，直至得到一个可以被客户接受的系统。总之，每一次迭代都是一次小型快速的流水线作业过程，需要项目团队各个角色的参与。在如此密集的迭代过程中，需要项目组内部有高效的沟通，紧密的配合，才能满足客户在响应、反馈、解决问题上的及时性、准确性要求。如果在项目的软件过程上，还是采用与产品研发一样的跨部门流水线式按部就班层层推进的工作方式，不仅沟通效率低下，潜在风险也会被埋在最后集中爆发，功亏一篑。

如上图，项目团队要能做到高效沟通，需要项目组成员各角色之间，有足够的信任和担当，紧密和默契的合作，整个团队是有一致目标的。所以，一个比较合理的项目团队结构，是一个核心成员稳定，集中统一管理的战斗小组。对于一个大型项目，可以分解为一个个小项目，分别由多个战斗小组承接，各战斗小组由一个总项目经理负责统一协调统筹，做整体的项目把控和推进、对外沟通。

战斗小组的负责人和管理者是项目经理。项目经理的角色定位，首先应该是有过类似本项目的项目实施经验的，对项目有一个清醒地认识，同时对该行业的相关知识有扎实的基础，能够做出一个科学的、切合实际情况的实施方案，在必要的时候能够帮助自己的组员解决问题，但并不是说项目经理必须是任何技术问题都非常精通。但无论如何，项目经理都应该熟悉和了解项目中的每一项技术，只有这样才能全面掌握项目。其次项目经理应具有协调、组织的能力，具有同客户进行沟通、协调的能力，为自己组员的项目实施做好环境的准备；在遇到关键或疑难问题时，能够通过各种途径找到问题的答案。

战斗小组的组员构成，有需求分析师（调研分析+开发指导+测试用例+系统实施）、软件设计师（系统设计+模块开发）、软件工程师（编程开发+单元测试）。余下，系统整体架构可以交给技术部的技术专家负责，系统集成交给技术部出系统集成方案和负责实施，系统测试交给质检部的测试团队负责。

项目经理应该是从以往项目团队的核心骨干里物色和培养出来的，通过晋升上岗。战斗小组的组员，可以从成熟的项目团队中拆分而来，也可以从相关的产品研发团队中转岗而来。

最新版见：GitHub - phenixiii/software-engineering-technology: software engineering technology

补充：纯技术服务类软件过程管控