BBS项目招募志愿人员加入

yining

支持。在补充一点：作为项目经理，你的另外一个责任包括控制需求以及需求的变化。不要客户说什么你就做什么。客户需要的是超人，你要做的，是给他一个普通人，再告诉他这个普通人就能满足他的需要，而且他付不起超人的佣金。

lodge

最初由 base 发布
[B]“我要建立一个BBS，能发帖子，能回帖子，当然，也能看，还有那个短消息功能，就是像人家BBS样的，一打开有人发给我的话，就会弹一个小窗户给我看的，我也能发给别人；还有就是我想可以管理那些个板块，还有人和发的帖子，并且呐，我可以改变BBS的样子；哦，对啦，还有啦，就是不是所有人都能发回帖子，还有短消息，要注册了的才成”
[/B]

呵呵, 世界上有这么懂行的客户, 大概就没有偶们混饭吃的份了.

实际上, 客户的要求是不可能这么明确的, 比如说, 这么多人都在讨论BBS, 他们一定有需求, 而能把这些需求明确化的人就一定是个IT高手.

偶在这里灌了这么多次水, 就总觉的差点什么, 象这次热烈的讨论, 除了一页又一页的翻看就几乎没有什么别的手段帮偶找到主线. 那么多的意见有分歧, 有一致却无法被清晰的表现出来. --这也许就是一个客户需求的样子.

base

[QUOTE]最初由 lodge 发布
[B]呵呵, 世界上有这么懂行的客户, 大概就没有偶们混饭吃的份
了. [/B]
呵呵，如果就实际情况来讲的话，这当然不会说的这么清晰啦，但是如果PM给他带一下的话，就会整理出来，不会没有混饭吃的份啦。

一则既然有这样的需求提过来，在成本分析的时候就会有个协商度，以后慢慢的，不能只谋求完全的技术壁垒来获得利润，因为如果我是客户，那么我要电脑化，我的手下则一定有懂电脑的，但因为实力没有强到可以自己开发才找软件供应商来做的；

二则，遇到思路清晰而且懂行的客户，这个系统开发起来会顺利的多，在软件开发中，最大的问题就是沟通，如，客户与程序员的沟通，由于表达的意思的不同，从而导致功能与需求的差异

[B]实际上, 客户的要求是不可能这么明确的, 比如说, 这么多人都在讨论BBS, 他们一定有需求, 而能把这些需求明确化的人就一定是个IT高手. [/B]

是呵，所以如果要真实的模拟实际情况是不太可能的，毕竟大家都算是写程序的人，我们的思路其实大同小异，差别在思考的层面有不同而已。
－－－－－－－－－－－－－－－－－－－－－－－－－－－
这个项目的目的如同经典力学，就是说从相对论中捞出来的一个宏观特例，使主线明晰化，将具体中遇到的，如与客户讨论时抓了狂，然后还得耐下心来讲解，引导其说得条理些，清楚些，不要把上一分钟讲过的不要做的事情，下一分钟又要做什么的。能把复杂的需求明确化确实需要一个高手，但是，如果受过严格的思维训练的话，这或者也是很容易的事情。

严格的思维训练，比如一个博导，他就可以从杂乱的需求中理出来，并且还能生成一套理论，然后再以理论来带实例进行开发。所以为什么在带项目的时候都要求经验，经验多了，也即你的思维训练到了一种程度了。

OK,我们现在在做一个实验，然后想从实验中得出想要的一个结果

一般情况下，一个提出需求的人如YN所言，会把你当成什么都能的超人，如，我遇到一个，他说，XX公司的XX系统的资料很好，我们这个系统呐，就直接用那个公司的这个系统的数据，然后再处理一下就行了，我说：那个公司和你们是什么关系呀？，他说：不熟，只是从网上看到的。我FT，让我去做Hacker呀。最后还得进行启蒙教育。

所以有效的导引是必须的，哪怕把他也培养成一个PM级数的人，如果有时间和阿堵物的话。这样大家都容易做，沟通易，而易达成共识，可是现实中这种理想的达成率之又少呵。

[B]希望各位对这部分提出问题，商讨ing
在下周开始做初阶段业务用例分析，因为原先开始的打算就是引入RUP的一些基本流程，用用例来做。[/B]
－－－－－－－－－－－－－－－－－－－－－－－－－
××××注：
这里再少少带一下XP的敏捷方法，XP的一点就是小范围快速迭代，什么叫做小范围快速迭代呐？

我想首先要弄清的是为什么要迭代，就是因为前一次发现有问题，所以进行迭代，在本次迭代中将前次发现的问题解决掉，那小范围快速迭代就是在一个可以掌控的范围内进行问题检查迭代，如此，用XP做下来的东西一般不需要回头，迭代过去后就OK。

这是一点，但是在实际的项目中，如果要用XP，则需要有客户方的懂业务的人参与，成为开发团队中的一员，这样才能进行有效的快速迭代，但实际上这不太可能，当然如果是自家公司开发自家系统除外。

所以在这个动作中PM可以扮这个角色，但对于需求，PM是没有决定权的，因为变更需求是客户的权利。

那XP怎么用呐，大家可以自己想一下，也就可以知道用法了
－－－－－－－－－－－－－－－－－－－－－－－－－

lodge

恩, 对于PM这个角色的理解, 偶是有点不一样的
PM的主要的管理目标有三个:
1. 成本 2. 时间 3. 质量
而在开发团队中的角色, 主要有四种:
1. 需求设计员, 只需要IT的基础知识, 但必需很了解客户, 这个角色的工作和以上PM的很类似, 主要工作是提出, 需求设计方案.
2. SD, 对于IT技术有广泛的了解, 有一定的成本核算知识, 主要工作, 根据需求设计方案, 提出系统基本设计方案, 并在可能的范围内, 减少系统复杂性, 降低开发成本
3.PG, 对于某一领域的IT技术(如, JAVA)有非常深入的了解, 有相当的编程能力, 主要工作根据基本设计方案, 提出详细设计方案, 实施方法, 测试方案
4.其他人员, 以PM为中心, 管理协调各部工作

特别需要指出的是, 需求设计方案, 基本设计方案基本上和开发语言没有关系, (虽然在基本设计方案方案中, 对开发语言和系统要求做了规定, 但是, 从思路上说应该是放之四海而皆准的)

yining

1。通常是叫做Business analyst的。PM往往也可以兼任。
2。设计人员所要知道的，就是需求，以及时间。对于成本控制，设计人员往往是做不到的。
3。测试人员应该与程序员分开。尤其是测试方案。从程序员的角度来写和从用户的角度来写，结果往往是不同的。

lodge

最初由 yining 发布
[B]1。通常是叫做Business analyst的。PM往往也可以兼任。
2。设计人员所要知道的，就是需求，以及时间。对于成本控制，设计人员往往是做不到的。
3。测试人员应该与程序员分开。尤其是测试方案。从程序员的角度来写和从用户的角度来写，结果往往是不同的。 [/B]

也许理解有所不同, 在我们这里, 一般需求设计由市场和企划部的人员负责编制, 而SD则肩负预算STEP数的责任, 因此要有一定的成本核算知识, 对于系统的复杂程度的掌握也是成本控制的一个重要手段. 至于编程和测试则都由系统开发部门负责, 不过通常是两个GROUP而已. 最后, 还有一个项目部门, 主要负责协调工作, 当然也包括在开发过程中同客户的协调, 不过偶觉得这不属于系统开发所必须理解的需求方案(也就是说, 所谓需求方案是要理解客户的总体需要这样的原则性问题, 而不是某个功能如何实施才符合用户习惯这样的细节).

base

这与自身所处的团队的实际协作情况有关，而且也是一个发展的过程
一般像国内的公司大都有将PM和SD由同一个人承担的情况，而称为PM（Project Manager），如YN所讲。很多，这也是一个问题。

嗯，像Lodge公司的做法还是比较合理的
由市场部抓单，企划部协作进行需求整理，不过这里的SD实际与上面所讲的PM差不多，只是将需求调查划分出去了，这样会不会使中间出现断层呐，即如果用户那边发生变动，这时与SD这边的沟通会不会出现问题呐？不过这种方式对于一些基本固定的领域比较适合

至于到开发阶段，这部分从理论到实践大都比较成熟了，只是要看实际时候如何把握，编程和测试是要分开的，对于稍大一点的项目这都是必须的，咦看到这里L兄这里还有一个独立的项目部门来处理需求变更，这里应该还要与企划和市场部进行迭代吧？

[B]另：希望有更多同仁参与讨论，看看应该如何做哦，呵呵[/B]

lodge

最初由 base 发布
[B]咦看到这里L兄这里还有一个独立的项目部门来处理需求变更，这里应该还要与企划和市场部进行迭代吧？

这时候的需求概念和企划部市场部那个阶段的需求概念大不一样, 企画部主要是全面了解行业动向(包括IT行业和我们客户所在行业)为系统开发确定大方向. 市场部则负责策划针对某一类客户的功能方案.
而在后期由PM承担的协调工作, 则具体到某一确定客户针对设计功能提出的微调整之类的需求, 他们各有其责, 没有迭代关系

lodge

想明白了一件事,

我所在的公司采用的是自行开发然后向客户销售已经定型的系统或者服务, 我们是先开发系统再"接单子", 需求的概念也就不同于所谓的定制开发, 也就是直接到客户那里接单子, 再开发系统的模式了.

我很虚心

我能不能也报名参加呢,我现在的工作每天都接触到,但是我却不懂之其所以然.我的mail是huhu20009@hotmail.com,qq号是164200076,但我没有天天开QQ.几乎我每天都有时间.