项目经理（实施）
以下内容仅根据个人工作经验阐述（作用仅为记录增加自己对工作的理解）
相信处于软件行业的实施人员甚至项目经理，对以下几种类型的产品或多或少有所了解，我在这里一一阐明
一、传统软件产品（现行业已成熟的）
1.传统软件服务，服务器（物理机），信息更为安全，从机房到服务器到数据库均在客户本地，网络内网。相对来说这类项目的前期部署也需耗费大量时间，在实施的层面来说，内部项目评审过后就要开始准备工作，避免不必要的时间浪费。
接下来由项目经理编写“项目主计划”，随后乙方会同甲方进行项目启动会（会议上部分公司会同甲方明确此项目的高层次需求，也可能会将甲方的关键用户或业务主管拉到会上做一个简单的”需求调研”，并确定交付范围。一般情况下交付的模块都会在合同中明确规定，或者售前会提前知会，但是难免会出现微小变动），会议过后形成“重要的”会议纪要，由项目经理根据会议纪要，输出项目前期资料文件SOW（项目工作说明书），由实施人员根据SOW按照项目主计划的时间规划，同甲方关键用户和业务主管进行详细需求调研，这个调研时间根据甲方购买产品模块的体量，一般情况下会通过问卷，业务模型，多人讨论会的方式确定甲方的功能需求与业务需求，进而形成SRS（需求分析说明书）交由甲方签字确认。以公司以往的经验（组织过程资产）和现有SRS，根据调研产生对甲方业务的理解，由项目组成员为甲方提供整体业务解决方案交由甲方签字确认。此后则由项目经理进行实施计划的编写，通过WBS工作分解，将大目标分解为小目标，再讲小目标分解为工作任务，将工作任务分配到实施人员的日常活动当中去。WBS工作分解结构显得尤为重要，资源配置要合适，注重效率提高，最好做好风险管理，实行人员AB制度，预测项目相关方可能会出现的意外情况，并提前拟定风险应对策略，具体风险问题具体分析（范围一般会有甲方组织架构人员调整，乙方项目团队人员调整，无法控制因素例如天气，疫情，以及甲乙双方对项目的关注度）。因为是标准行业化产品，所以不会有大的改动，只会有操作习惯，和行业特殊化的开发工作。在分配工作后由项目团队进行相关系统配置，业务流程形成闭环，配置好后进行测试（质量管理），测试分为多种以系统测试、单元测试、集成测试，回归测试为主。在测试成功后，实施人员会根据系统功能结合测试用例，给予用户编写系统操作手册或录制视频用来培训用户，此后将配置好的生产环境交由甲方进行产品演示。可能在演示的过程中还会出现有一点小改动的问题，这些都是正常情况。演示后正式签写“上线适用报告”，在客户适用过程中会出现个各种各样的操作问题（关乎培训可能是反复无常的，也可能随时随地都要教客户学会使用系统），在适用一段时间后，甲方关键用户会基于操作习惯或者功能提出需求，在此类需求中，实施人员要知道如何识别需求，需求的优先度和系统的适配程度，通过识别需求来同意和拒绝甲方的提问。同时将此类问题编制成问题清单，包括问题的状态、处理方式、负责人都要有记录，有确认，有测试。在此阶段完成后，可以进入到验收。在与客户谈验收时，又可能会遇到阻碍，例如：还有一些无关痛痒的问题没有处理完，我们不可能改动的功能甲方坚持要改，关于合同外的需求如果要做，此时应与商务沟通，如果是简单易改能不进行开发就不进行开发，尽量采用可配置的方法进行完善。以上问题在开始之前应需要提前与甲方沟通好，做完验收签字确认，否则这样的情况将会无休止进行下去。在验收阶段后会进入运维阶段。对于传统软件行业，甲方如在未来使用这一套产品的过程中需要乙方进行咨询和维护则还会签署运维合同，由乙方专业的团队来进行对接。至此这一项目交付成功。
二、定制化产品（从0到1之间反复迭代）
定制化产品服务，在软件实施过程中更多的工作在于原型迭代，需求评审和沟通，并且模式不可复制，不可应用到其他项目上。一般情况下，乙方并没有标准化产品进行应用，而是通过一个团队（ 团队里面可能包含项目经理、产品、UI、测试、前后端开发工程师）在项目立项时即开始组建，到项目启动会会议结束时即开始调研，从甲方整体的业务和功能框架开始，调研甲方应用产品的目标，达到什么样应用模式，完善哪些业务流程或跨组织业务流重组。定制化产品在需求评审、质量控制、团队管理、上更为突出。需求评审体现在沟通上，在调研时在于倾听者能否明确甲方业务，与甲方沟通是否得当，能否真正理解关键用户在工作中的痛点，更体现在转达内部产品与开发之间需求的准确程度，在团队内部中通过讨论与头脑风暴的方式客观分析需求的必要程度从而将需求编入开发计划中。如不符合说出原因并结合所了解的业务给予甲方更专业的建议。质量控制体现在测试上，测试工作更是循环反复的一个工作，每有一个新需求就要从画原型开始到上线更新，测试更是把握着新需求的生命节点，只要与甲方目标不符一定会进行返工。每从1.0更新到2.0版本都要到甲方现场给客户进行展示，看是否符合外部预期。展示结果成功则会开始调研新一轮业务，反复进行此项工作直到项目完成为止。团队管理体现为与内部、外部的对接，消息的转达，甲方，乙方高层领导和团队内部三方共同利益上。兼顾好三方的利益（三方利益指的是甲方的期望目标，乙方高层领导期待项目的利润空间，团队成员的工作舒适度、工作氛围和奖金发放），定制化开发的进度、效率会更高。同样，定制化产品的范围会比传统软件服务更难控制一些，本身定制化产品就是为甲方量身定制的，所以甲方提出符合自身的需求在理论上是符合原则的。所以需求评审是定制化开发的“重中之重”。如何取舍这个问题很考验项目团队负责人的能力。最后验收和运维阶段，大多数要求定制化开发的甲方（我做过的项目的甲方）都会要求简洁明了，操作简单，所以运维只要交给甲方的信息部门或信息科就好。
三、saas化产品（由云部署到包装为客户提供软件租赁服务）
saas化产品软件即服务在我理解为乙方为软件提供租赁服务，数据库与服务器均在云上，网络为外网。在甲方购买此项服务后后期运维均有乙方的运维团队负责。甲方相当于租户，如果运用产品使用感受良好，则进行二次续费。跟传统软件服务相比，实施周期短，敏捷实施，产品更新快、数据安全不如传统软件服务，二次续费看产品的好用与否。从实施的角度上来看，saas实施更为敏捷，通过提供saas服务账号给予甲方，乙方通过调研甲方业务进行实施配置，在实施阶段可以省去很多麻烦事，无需考虑应用本地部署。在收割客户时，我常常会提及这个优势。但是依赖于网络，如果网络断掉就不及本地化部署的脱机模式。界内一直对于saas的命题是标准化与定制化相结合，在我看来我更认为是软件即服务的发展趋势。同时saas对外实施的推进变得简单了很多：业务→实施→流程→界面→适用，全链路服务。在saas实施过程中更注重的是用户对于产品的体验如何，甲方领导的决策占比反而相对少了些，因为最终saas是延伸到终端的，由用户反馈给上层领导，通过提升用户满意度而降低甲方领导决策占比。在我的理解中saas产品未来一定是集中的，至少在行业或产业的集中，saas也一定是开放的，但并不是说为他人做嫁衣的开发，而是指API接口，我们只要保留saas的核心功能融入到甲方的业务形态里去，形成一整条业务流，就不会造成被窃取知识成果的局面。saas实施后期至运维阶段最重要的还是服务属性，这也会大大影响用户的续费率。相比之下，传统软件服务宣传口号往往是为客户节省多少资源，节省多少人力，慢慢的saas的口号也于传统软件服务变得一样了，但是我并不这么认为，我考虑更多的是saas产品相关的业务升级和人员技能升级，所以关乎节省人力、资源是个伪命题。由于我对saas项目实施的不是很宽泛，所以只能理解到这一层面。