供应商管理
遇到两个让我头痛的供应商了。
一个供应商（A供应商）的项目基本已经做完，后续的维护他们就不管了，BUG的修复就留给我来处理，给他们查屁股。
另一个供应商（B供应商）的项目正在交涉中，我所做的是评估技术方面的，但项目负责人（业务部门）的人，他们基本谈好了。但我和这个供应商的技术人员交流时，发现他们文档能力不行，变更能力强。此供应商的方案有极高的风险。唉，头都大了。
现在我们每次沟通过的内容，我都会一一发邮件给相关的责任人。B供应商都不会答复我的邮件，都在QQ上回复，回复的内容又很含含糊糊的。这叫人郁闷。我们让他们来我们公司，他们就说，请我们去他们公司。
哪能遇到那么好的甲方啊~~我现在都被甲方折腾死了。~！！！被完虐。 18 楼 xiaoqiulqs 2010-11-22 hgq0011 写道xiaoqiulqs 写道我现在正遇到和楼主同样情况，此时建议可做如下操作：
1.在合同中明确：各里程碑及产相关产出物（特别是需求、设计、测试），同时验收指标明确，确认甲乙双方职责。
2.每次开会必须当场确认会议结论，事后尽快发出，以免过后不认账。
上午和B供应商激烈的讨论了一上午。
上午浪费了我不少口水。我非常讨厌别人做事不务实。需求文档明明写的非常清楚了，也和他们确认了，然后说改好了，一测试问题还是那样。这样玩我，我就用时间期限，压不死你？要不就废掉该方案。
我们做事情还是比较稳的，一定要方案没有问题，并且能够经过大体的测试，没有大的问题。那么我们才能接收他们的方案。即使是接收了他们的方案，在使用过程中如果发现有问题，不能及时的改进，该供应商还是一根毛也别想得到。最多乱费感情。
说白了LZ就是怕担责任，这也是可以理解，别看是在甲方。
既然这样，你完全可以用硬性指标压制乙方的。在关键项目节点，一定要有评审，评审时召集相关负责人，特别是业务部门。如果发生问题，评审时各负责人都在场，可以当场确认问题到底是什么问题，谁的责任，或是找相关解决办法。如果在评审中各负责人都没有问题，即使系统过后出现问题，责任也不在你。
19 楼 hgq0011 2010-11-22 xiaoqiulqs 写道
说白了LZ就是怕担责任，这也是可以理解，别看是在甲方。
既然这样，你完全可以用硬性指标压制乙方的。在关键项目节点，一定要有评审，评审时召集相关负责人，特别是业务部门。如果发生问题，评审时各负责人都在场，可以当场确认问题到底是什么问题，谁的责任，或是找相关解决办法。如果在评审中各负责人都没有问题，即使系统过后出现问题，责任也不在你。
不是怕承担责任，是怕被黑锅。
没错，直接在会议上，说明我们已经提出该方案的风险，如果业务部门要上，有任何问题，IT不负任何责任。业务部门同意了。 20 楼 wf1006 2010-11-26 有过类似经历,说下我的看法:
1.维护项目一定要有一个长远的打算,申请资源(如:程序员),由他进行有效的沟通和反馈记录,并提交项目进行决策,是否变更和修复工作;可以统计一定时期后进行反馈客户,提出变更请求;有话说的好,事多人不怪!
2.现在正在跟踪的项目,及时做好业务沟通分析,QQ反馈记录整理和客户反馈工作,最终目标,和客户达成初步开发需求的大框架,并签定协议开发.技术方面可采用公司现有产品的二次开发和定制工作;或是,采用敏捷开发模式,进行短期跌代开发模式,及时发布收集反馈意见并修复.
3.作好项目文档的整理工作,确保项目进度过程中的任何风险,并及时提交公司评审,确定工作策略. 21 楼 hgq0011 2010-11-30 wf1006 写道有过类似经历,说下我的看法:
1.维护项目一定要有一个长远的打算,申请资源(如:程序员),由他进行有效的沟通和反馈记录,并提交项目进行决策,是否变更和修复工作;可以统计一定时期后进行反馈客户,提出变更请求;有话说的好,事多人不怪!
2.现在正在跟踪的项目,及时做好业务沟通分析,QQ反馈记录整理和客户反馈工作,最终目标,和客户达成初步开发需求的大框架,并签定协议开发.技术方面可采用公司现有产品的二次开发和定制工作;或是,采用敏捷开发模式,进行短期跌代开发模式,及时发布收集反馈意见并修复.
3.作好项目文档的整理工作,确保项目进度过程中的任何风险,并及时提交公司评审,确定工作策略.
积极的心态做事情，就会产生积极的影响。能和务实的公司做事就是放心
