|
精华帖 (0) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-07-23
jimmy.shine 写道 不讨论细节?我认为这不可能,如果一个需求分析只是点到即止的话,到最后你会发现后期你会陷入无何止的改动当中,有很多是需求理解的问题. 我认为这不是讨论不讨论需求的问题,而是你们PM的问题,做为一个PM,没有很好的对于项目的把控能力,第一个场景,在问题没有表述清楚前就开始讨论.更让人惊异的是,居然下面的成员不知道是为什么行业的客户做的软件.每个行业都会有自己的特点.场景二,PM如果自己对于技术不是很了解,就放手让技术强的人去做,如果自己了解,就决定好了.场景三,需求是无止境的,可以在心里有估算,做到有的放矢,但是过人扩大需求就没有意义了.建议看一下Rod Johnson的 J2EE without EJB,不要产生幻影需求 至少在项目目标都不明确的时候，不要讨论细节问题吧？ |
| 返回顶楼 | |
|
最后更新时间：2008-07-23
我觉得楼主说的“细节”有问题吧。应该是太早考虑实现了
应该先把需求缕清。而且，需求一定要注意细节。 |
| 返回顶楼 | |
|
最后更新时间：2008-07-23
jimmy.shine 写道 不讨论细节?我认为这不可能,如果一个需求分析只是点到即止的话,到最后你会发现后期你会陷入无何止的改动当中,有很多是需求理解的问题.
我认为这不是讨论不讨论需求的问题,而是你们PM的问题,做为一个PM,没有很好的对于项目的把控能力,第一个场景,在问题没有表述清楚前就开始讨论.更让人惊异的是,居然下面的成员不知道是为什么行业的客户做的软件.每个行业都会有自己的特点.场景二,PM如果自己对于技术不是很了解,就放手让技术强的人去做,如果自己了解,就决定好了.场景三,需求是无止境的,可以在心里有估算,做到有的放矢,但是过人扩大需求就没有意义了.建议看一下Rod Johnson的 J2EE without EJB,不要产生幻影需求 同意你的观点 |
| 返回顶楼 | |
|
最后更新时间：2008-07-24
这是有关客户的需求解决过程的讨论,我现在小结的一般过程是:
客户提出需求 -> 开发方分析与理解需求 -> 程序设计[部署,数据表设计,server component引用,编码等等]->解决需求 分析与理解需求是前提,程序设计是关键; 系统的使用好坏归根结蒂是设计问题! |
| 返回顶楼 | |
|
最后更新时间：2008-07-26
我没有从LZ的经验中看出他们公司的软件过程是怎么样的，对于一个商业的项目，不仅仅是涉及到IT部门，还包括到市场、销售、操作、HR等业务部门，对于这些跨部门的软件开发，如果没有一套软件过程来约束，而仅仅是靠PM、TL单方面的讨论，稍微复杂一些的项目马上就会出现无头苍蝇的情况。
|
| 返回顶楼 | |
|
最后更新时间：2008-07-26
protti 写道 jimmy.shine 写道 不讨论细节?我认为这不可能,如果一个需求分析只是点到即止的话,到最后你会发现后期你会陷入无何止的改动当中,有很多是需求理解的问题.
我认为这不是讨论不讨论需求的问题,而是你们PM的问题,做为一个PM,没有很好的对于项目的把控能力,第一个场景,在问题没有表述清楚前就开始讨论.更让人惊异的是,居然下面的成员不知道是为什么行业的客户做的软件.每个行业都会有自己的特点.场景二,PM如果自己对于技术不是很了解,就放手让技术强的人去做,如果自己了解,就决定好了.场景三,需求是无止境的,可以在心里有估算,做到有的放矢,但是过人扩大需求就没有意义了.建议看一下Rod Johnson的 J2EE without EJB,不要产生幻影需求 同意你的观点 人家说的是不要先讨论细节。 |
| 返回顶楼 | |
|
最后更新时间：2008-07-26
做了三年项目，我现在对这个问题的理解是：
PM总得安排点事情要大家做，比如第三个场景 那就讨论吧，反正也没啥害处 我经常遇到这样的Leader 也经常避免做这样的Leader |
| 返回顶楼 | |
|
最后更新时间：2008-07-29
领导水平的问题
严重同意sslaowan |
| 返回顶楼 | |
|
最后更新时间：2008-07-29
会议组织者应该控制会议的议题,不要让它跑题,我们现在开会老是跑题,而且越跑越远,拉都城拉不住住
|
| 返回顶楼 | |
|
最后更新时间：2008-07-29
支持,不过技术人员要讨论的时候,难免会落入俗套,从程序实现的角度去考虑问题,这也是程序开发人员需要改进的地方,站在什么角度,就希望从什么角度去考虑问题,而不能固封在技术的圈子里面,若干年后我们只能死在技术里面,因为技术更新太快了.
|
| 返回顶楼 | |
