公司最近接了一个比较大的项目，我这个技术总监不能总是睡觉吧，就写了个东西给同事们看看，顺便也贴到blog上来，给大家讨论讨论。

1、项目成败的关键是找到系统的核心价值
这是关键一点，首先必须找出这个项目真正的目的所在，这里首先要找出“真正的用户”--一般是系统的最高使用者，他们眼中的建设系统的目的和最关键的需求就是系统的核心价值。当然，比较矛盾的一点是，这些用户在开始做项目的时候一般自己也都不清楚自己的关键需求，一般会在项目开展后才会逐步有认识，因此尽快地引导“真正的用户”找到最关键的需求是前期的中心任务。时刻要想到，这个系统是干什么用的，为了这个目的所做的工作就是关键的人物。
总的来说，只要满足了最关键的需求，体现了系统的核心价值，项目就算及格了，可以看作实现了项目的“最低纲领”。

2、用户、需求一定要分层次
用户本身就要分为几个层次，这需要项目经理有清醒的认识：不是所有的用户都是上帝，不是所有的需求都是必须实现的，体现系统核心价值以及为了体现核心价值所必要的，才是必须做的需求。其他的需求要分轻重缓急，一般根据提出需求的用户等级来排定优先级，而且关键一点是：用户提出的需求，首先要想一下，目前的系统有没有可能满足，或者有什么变通的办法可以实现，尽可能在现有的系统内解决，如果实在不能满足，就找出最简便的解决方案。

3、确保用户与我方的接口是唯一且规范
大家一定要清醒地认识到：项目组是一个团队，而不是几个人，这个团队是有分工的，其中关键的一个工作是与用户的沟通、接触。根据我的经验，必须确保与用户的这个接口是唯一的，用户所有的需求必须通过这个接口才能进入团队成为工作，不是谁都能答应用户需求的。
这个接口很重要的工作是，理清用户需求确认的流程，规范其操作，要认识到，不是阿猫阿狗都能向项目组提需求的，一定要引导用户建立自己的需求确认机制。核心要点是，确认需求必须有规范的流程和规范的文档（越详细越繁琐越好），用户也是需要做规矩的，这需要我们自身首先就要做到操作流程、文档规范，然后用实际的行动展现给用户看，用户会逐渐的认可、接受这种方式，只要用户接受了，以后很多的事情就容易操作了。关于这点我有着非常多的教训。

4、用户的各种角色以及对应的策略
用户本身也要分为各种角色的，根据我的经验，我把经常接触的用户分为如下几种角色
A、用户单位的高层领导
这类用户一般是项目的最高使用者，但是一般来说对IT都是一知半解甚至是一片空白，对于这类用户要时刻注意在给与足够尊重的情况下保持适当的距离，对于他们提出的问题要不折不扣的解答，一般来说他们最注重的是态度，由于是高层领导，因此他们与项目组的接触一般比较少，因此抓住有限的机会用最好的态度来给领导们留个好印象。
B、项目提出者/具体执行者
这类用户一般是用户单位的中高层领导，一般来说都是比较有事业心，很有头脑，在一些专业领域也颇有建树。这类用户是项目成败的核心，系统的核心价值就掌握在这类用户手中，因为即使他们不是用户单位的高层领导，但也是掌握了高层领导的真正想法。对于这类用户，我的经验是这类人有个共同的特点就是：有特别的嗜好，而且特别执着。因此可以从精神沟通层面入手，多聊一下他们嗜好的东西，有条件就多参与，最好的情况下能够培养出与他们的感情。跟这类用户的沟通是关键，一定要多多沟通，聊的越多越好。在物质方面，根据我的经验，他们一般不会特别的在意，不过也是要根据具体的情况来区分。
C、项目方接口
这类用户一般是具体执行部门的IT负责人，一般对IT很精通，但是具体的业务是一知半解，而且对我方有着强烈的好奇心，并有浓厚的学习欲望。对这类用户，应该与他们打成一片，跟他们要同吃同工作，经常腐蚀他们，至少要让他们有小半个屁股坐在我们这边，对我方的项目操作非常有利。
D、具体的使用者
这类用户一般是具体业务部门的主管、组长等，一般对业务很精通但是对IT不是很了解，他们的需求是最多的，一般说系统有很多问题的也是这类用户，对于这类用户，需要主动的沟通，在需求调研、系统设计阶段就不断的跟他们沟通，不断地向他们请教业务知识，一般业务专家都是很希望找个人来聊聊自己的专长的，通过这样的沟通，我方既可以掌握业务知识，又跟这类用户混熟了，但是这类用户提出的需求，一定要坚持上述第2、3点，必须跟这类用户解释清楚我方的流程以及不采用这个流程的坏处。
E、具体的操作者
这类用户一般来说是不用多理会的，意见要听，态度要好，但是就长个耳朵就行了，要记住他们不是付钱的人，对付钱的人也没什么影响力，当然可以多从他们身上多听些意见对系统也是有好处的，至于是否做可以再说。

5、必须表现出专业公司的气质
A、自信
这是关键一点，我们必须表现出对IT方面的绝对自信，用户在这方面是没有更多发言权的，但是业务方面当然要听用户的。
B、统一
项目组内部可以争吵，但是对外必须是一个口径说话，不管在哪个方面
C、稳定
首先是人员的稳定，人不能总换，必须有个连续性
其次是系统稳定，用户最担心的不是功能不够，而是运行起来老是出莫名其妙的问题，这是最忌讳的。
D、不要总是大批的人在现场开发
一直趴在现场开发的是小公司，只有沟通不够或者设计不行的公司才会这样。
E、文档
文档必须很规范，每做一件事情，之前必须确认，做中必须有汇报沟通，之后必须有总结、验收、确认。用户要多多参与，这些都是展现给用户看的，乙方的地位很多程度是通过这个来提高的。

需要说一句的是：所谓的经验，都是在实际项目中总结出来的，不一定适用所有的地方，且世上没有一样东西可以放之四海皆准，所以还是一句话“运用之妙，存乎于心”，要根据实际的情况来把握。