项目管理常见问题

项目实施全流程

• 项目立项

科技为业务赋能 (节约人力至按点下班, 业务开心; 节约人力至裁员, 业务会强烈抵制)

监管要求 (卡上级检查节点, 容易验收, 不容易有额外需求)

面子工程 (前端样式要求高)

项目发起人的满意程度很大程度上决定项目验收难易(一般这个层级得好看, 不然怎么给领导写PPT)

• 招投标

售前阶段就会开始圈定实施的项目范围

需要初步控制范围，并在投标书中有所响应

商务,销售与行方建立的关系影响很大, 可能POC分数超过第二名供应商也被pass(事先了解很重要, 别投入大, 只是凑数的)

• 标书的解读

了解客户看重点(技术型, 不冒烟不罢休; 业务型, 好用才是王道; 两者兼具也很常见了)
POC评分规则也能看出公司产品是否符合, 评分标准是否已被其他厂商引导过(人家都是老铁了, 就别瞎掺和了)

• 启动入场

需初步确定的工作范围 (项目工作说明书, sow签订)
特殊情况需双方协商, 公司开具提前入场函 (还是多想想有坑没吧, 毕竟一入豪门深似海, 金主惹不起)

• 范围确定

控制成本的关键, 标准产品实施最优(完全定制化另当别论), 产品的满足程度越高，范围约可控 (就部署个应用爽不爽?)

适当的缩减范围，有时也能有效缩减项目周期，满足客户要求的上线要求，这是一个双赢的结果; (往往是一期二期间的需求替换, 二期的坑就不知道谁来填了)

需求不匹配程度很高，项目范围不可控，需要协调领导层决策(没事少招惹领导, 不然要你干嘛, 哎, 没办法了)

需求的约定需要引导客户, 把控客户预期, 预期过高项目易不可控 (我这就一个炮仗, 送不了你上月球)

业务需求(主要是指项目的业务类别: 信贷审批, 交易反欺诈, 知识图谱, 客户画像, 设备指纹, 数据仓库, 机器学习), 接入多少个渠道

功能需要(满足客户业务, 需要哪些功能. 登录, 权限隔离, 字典配置, 多级审核,审批 是一些最基本的功能 )

非功能需求(数据安全, 合规性, 吞吐量, 并发数, 响应时长, 高可用, 易扩展, 灾备等等对软件的特殊要求)

要求对产品有一定的熟悉程度, 引导客户向我们产品容易实现得方案进行(就是忽悠)

针对客户定制化需求需要有清晰判断, 规避难以实现的业务需求,避免架构上的伤筋动骨(范围内还是范围外; 全新开发, 还是现有产品简单改造)

避免xy问题, 都是贷后, 现有产品只是简单的"贷后监控", 而客户实际需要的是贷后管理, 预警, 催收一整套系统(答应了还想跑? 又不是程序猿删库就好, 违约等着你)

一些单纯为应付监管, 甚至客户自己都不知道需要哪些功能,需要专业引导 (不然过条小河造个小船的事, 客户非给你画个航母出来), 细化, 细化, 再细化 (都有指着近期两字问你, 为什么只有6个月的统计? 不能统计所有的么?为啥不写清楚?)

大数据相关项目, 数据调研尤其重要, 前期的数据调研需投入较多人力支持, 客户对自身的数据质量一般没有一个准确的判断，抽样具体场景的数据做判断(不要你觉得, 我要我觉得)

现阶段大部分客户数据质量不高, 优化数据调研的流程, 列清需求重点调研项, 客户数据质量实在非常差, 需要降低客户预期, 提前和客户沟通清楚(数据质量决定模型高度, 再牛叉的算法也只是逼近这个高度)

• 需求设计

遵循设计模式, 以应对可能出现的变更

• 实现

需求范围风险, 实施成本与时间成正比, 需求范围控制得好实施时间就不会延长太多, 项目才能盈利(最不愿做的就是附赠项目, 谁来支持? 开发听着都没兴趣; 从开始就亏钱的项目, 没发现风险就接了, 领导都不愿理你; )

客户风险, 客户预期过高, 不利于实施,验收; ps: 一般甲方科技部门与业务部门关系不会很和谐, 入场不站队都不好意思说自己混过乙方, 优先站强势队伍, 另一方相对中立即可

延期风险, 避免依赖其他渠道影响进度, 先约定成文档(邮件知会干系人,扯皮关键), 挡板开发, (时间节点评估宁愿事先扯皮多评估, 不要最后到店再提延期)

成本超支风险, 远程开发, 节约驻场成本; 功能复用, 很多功能各个项目都是需要的, 尽量抽取复用

关键风险点, 会引发其他一系列风险, 保质保量完成项目的验收结项，与这个有冲突的，都可以视为风险，都是作为项目经理需要排除的问题。

项目实施本质上是一个服务的过程，现场人员的表现就代表服务质量

实施一项关键能力是换位思考的能力, 只有知道客户真正想要什么, 才能为题提供好服务

实施过程中, 不遇见个奇葩那就太不正常了，见人说人话, 见鬼说鬼话, 心里抗压呗, 不然还能来个肉体间压力释放啊

复杂项目问题处理, 分析问题根本原因, 针对问题作出判断, 出解决方案, 然后执行. (需求变更: 首先从业务角度判断客户需求的合理性，然后看需求是否是项目范围内，如果是项目范围外，需要和客户协商做需求变更流程，同时告知客户需求变更对计划的影响)

实施类项目的周期往往和成本成正比, 作为项目经理需要专注于项目的落地 (得盈利啊, 难啊)

• 测试

SIT测试
系统操作手册, 系统培训
引导业务UAT测试, 配合验证

• 上线

上线部署操作手册
迭代, 注意回滚方案制定
上线稳定运行报告 (系统监控指标)
配合业务提供成果展示, 让项目发起人满意, 让领导满意, 不然科技,业务拿什么邀功, 没啥好处给你验啥收
生产出事了咋搞? 先止损呗, 保护好现场, 证据翻起来; 小事 -> 证据留好, 人情给我欠着; 大事 -> 锅能甩就甩起来, 甩不动了, 领导?我这有瓶82年得二"锅"头, 刚温的, 尝尝? 商务,法务搞起来(开玩笑, 锅要自己抗, 不然大佬们怎么捞你)

• 验收

项目验收在sow中有约定, 项目上线稳定运行约定期限后可按约定协商验收
项目验收的顺利往往和客户满意度有关，如果项目达到或者超过预期，往往验收会比较顺利 (我们的目标不只是完成项目上线，而且需要在保证项目上线的基础上, 也要让客户满意, 问题及时处理, 小需求及时响应)
对于科技部门, 系统稳定, 易维护, 高可用; 对于业务部门, 系统易用, 稳定, 结果正确; 对于项目发起人, 展示效果达到或超过预期

• 二次商机

了解客户现阶段痛点
与销售配合

• 一些业务

信贷 -> 客户各渠道获取的信息数字化, 评估信用是否达标;
反欺诈 -> 历史交易与当前交易信息整合,评估当前交易风险状况;
预警 -> 事中批处理, 是否达到阈值
知识图谱 -> 将死板的表格活化成图(点->实体; 边->实体间关联关系)

• 描述自己的优势

技术是大佬, 技术评审随便浪
产品熟练程度可以秀到飞
业务还能指导下甲方
性格好, 只要不动手你随意
对于出差或者加班不排斥, 能抗压, 就是落地项目
一直从事相关行业实施工作，项目管理经验有欠缺，充当技术经理角色, 和客户的沟通也非常多, 项目经理不在场时会充当项目经理角色, 完成项目交付是没问题

ps: 文字, 邮件记录为甩锅关键, 含糊不清的回答就当听不懂, 给他解释解释

本文地址：https://blog.csdn.net/zxczb/article/details/107374203