能否谈谈系统开发过程中人为因素的影响?
　

---

起个头吧,开发的过程中可能会采用各种技术、方法，各有千秋，可是项目的成功与失败很大程度上取决于用户的关注程度，如果处理不好很可能就是系统开发实施的壁垒，如：政治因素、用户会担心自己的权利会受限等等，都可能成为开发过程中的阻力，如：使你的计划不能按时、培训工作不配合等。。。
怎么处理？

 我称之为对"非技术因素"的管理
　

---

主要关注人的心理,如：感情,情绪,性格因素等方面对软件项目的影响问题.
我曾经卤莽地下过断言:
非技术因素和技术因素对软件项目的影响比例可能是8/2
而花在对非技术因素和技术因素上的研究和管理的代价比则是2/8
这又是一个典型的"XX倒挂"的问题.
软件主要是靠大脑的逻辑思维进行工作的,大脑思维最容易受到的影响来自心理的活动.这是人最脆弱的部分.
如何对非技术因素进行管理？我也想提出类似的问题。
我看过cancan的发言记录，2002这一年的时间怎么是空的？

不健康的关系投资涉及整个社会的范围,是适应社会文化的要求,间接为项目服务的投资,确实是较大的一块.
我比较关注的是和项目密切相关的健康的关系投资,就象投资到技术因素上的一样,是直接切实为项目服务的投资.
其中又包括外部的关系投资和内部关系投资,我想,cancan是比较关注外部关系的健康投资问题,我则比较关注内部关系的健康投资问题.
把政治环境的管理纳入技术范畴可以表达对政治环境的充分重视,但不意味着管理方式和手段也和对技术因素的管理相同。对某项目的SA提出相关素质需求,时意味着是对该SA的栽培和对该项目经理素质的缺陷的承认。一专多能和分工协作之间存在一个权衡，就象要求SA做BA的工作一样。

不懂用户文化是很多项目需求不确定的原因。现代it企业的误区之一便是以为将企业象计算机一样划分模块，明确接口，企业或项目就会自动的正常运转，呵呵。这点恰恰是被很多传统行业嘲笑的原因。杰克。维尔奇可能就是认识到此才提出管理无疆界的。

 和你的角色有关系
　

---

如果你是老板
你需要承担主要责任,赶紧的,搞掂客户一把手(说了算的).

如果你是项目经理
和老板沟通
和对方项目负责和用户沟通,找出双方谅解和可行的办法.

如果你是打工的
休息,学习,找工作
做面对任何突发情况的心理准备

如果我们稍微研究一下ISO以及一些流行的管理思想和方法，我们会发现软件的结构化分析设计的影子。传统行业要么嘲笑，要么接纳，却没有想到要进化，就象软件分析设计方法本身也在进化一样。这当然是不幸。
真正的“无疆界”是什么？
难道是对任何问题不加区分，对分工协作的全盘否定吗？应该不是！
应该是螺旋上升的境界，这已经超出本主题的讨论范围。

我们不是在讨论要不要懂用户文化的问题，而是讨论如何搞懂和适应用户文化的问题。甚至还有项目内部的文化问题。希望话题不会越跑越远。

只是各为各自的利益着想，而不看到全局的利益是如何被每个局部牵制和贡献的。为什么失败的项目那么多？这样下去，我们的项目在走向成功率上升还是下降？当然，作为失败的存在也是合理的，但随波逐流的态度，很容易从失败走向失败。
不管是什么角色，在履行本职岗位职责的时候，总要关注自己的上下游，总要关注自己的一个变化对整体的影响，要根据具体的实际情况灵活补位换位，既不是固守本位，也不是飘忽无位。这才是一种积极的文化，进化的文化。

解决问题之前是分析问题，开发过程中的人为因素影响到底有哪些？它们是怎样组成的，又可以怎样分类？这些因素之间以及和技术性因素之间有什么关联？所以建立该问题领域的参照系是第一步工作。

例1：在一个开发工具项目的初期，一个颇有潜质的程序员进入了项目组，强烈的求知欲和能力提高欲望使其士气高涨，对分配下来的任务总是积极和分析设计师做细致沟通，对编程技巧和实现算法总是精益求精。在项目早期的迭代中，他作出了突出的贡献并能力得到迅速提高。
好景不长，程序员逐渐发现自己要学的东西越来越多，希望实践锻炼的技术也越来越多，在对待分配下来的工作时，首先考虑的不是完成工作最恰当的技术了，而是考虑自己还有什么技术不大熟悉，拐弯抹角地在项目中哪怕牵强附会也要一试。最终发展到私自篡改设计，达到自己练兵的目的。对项目的影响是可想而知的。
这只是一个个人求知欲和成长欲对项目造成影响的例子，谁来分析一把，设计个解决方案？类似的例子还有大把。

我没有跑题，我只是想告诉你有些问题分工解决不了，让用户自己明白什么话题应该找什么人聊更是一种错误，你不觉得那样有点像去医院看病需要自己先明白是什么病吗？不过这倒是中国医院的特色，以至我以前看病时经常一次挂好几个科的号，以防万一不是这个科管也不用重新挂号。pm和sa不一定必须是项目的技术骨干（如果是更好），但必须是全才，否则最多只是一个技术经理，而不是项目经理。因此，有时项目经理可能比部门经理还要难当。现在很多项目经理都其实是技术经理，有名无实。

非常希望和你这样好同志一起搞几个项目，可是。。。
现状呢？
看看华为、用友、联想。。。是如何做的呢？

你所说的，更像是项目经理

“人为因素” 先分清来源先

来自客户的价值变更

来自内部的...

来自上层的行政命令...

1. 同级审查

2. 单元间松偶合接口设计

3. 起码单元性能功能描述 测试用例

另外是 职业道德和责任心 里程碑和进度 定期技术培训

就这些了.

团队和沟通很重要,这样的人存在,是团队建设的问题.

长期的手段,还是要从团队的建设和管理上入手

(巨牛的人,就调整到适合他的地方,比如技术顾问,配置管理等.而不是项目开发团队)
　

 非常感谢大家的讨论，希望大家的讨论能。。。
　

---

大家新年好！
起这个头的最初目的是总结下失败的原因，这两天在看一些书，看到关于测试的一个原理：要去发现错误，而不是证明能用。 看到这里突然有点感觉了，也许不止是在测试方面，如果在开发的过程方面也适当的转换下思维可能更好，觉得以前自己在学习、工作的过程中总是想找一个“能行”的方法和技巧去做，可是却很少思考用这些方法和技巧的过程中会面临的风险和阻力，以至于一些失败。而造成失败最大的因素是轻视了人的因素，特别是用户的因素（个人观念）。
想起了做系统分析的一个原则，系统是为用户而建的，所以我认为如何站在用户的角度为用户提供提高效率和利润的解决方案及产品设计、实施等方面都必须有很长的锻炼时间和需要学习的知识。我真心的希望大家不要急功近利，无论是写程序还是系统分析、项目管理或应用、技术的体系架构设计等都需要扎实的基础和熟悉的思路、意识、原则，而这些都不可能仅仅靠书本上的几句话就能领悟的，而是要在工作中去慢慢消化和总结。

这段时间我有空，可以好好交流交流，我在深圳
babituo还记得我，太意外了。2002年之所以空白，因为2001。5月就开始忙，现在失业了所以才来这里混混。

对于用户的风险，需要通过长时间的经验积累来降低，现在一般的分析人员都是
年轻人，对于别人的理解比较差，有时候，不同行业的人对同一件事情的认识差别很大，我们认为已经没有了问题（或者问题容易解决），但用户必须看见真实的操作才行，在这方面，要多从非专业人员的角度考虑。