第一次项目经历,碰到很多问题,麻烦前辈们指点

jane

好像这个问题在我们公司也比较多，好在我们有个售后维护部，可以缓解下源源不断反馈回来的BUG。
看到你的描述，以及不少专家的高见。问题和解决方案差不多都明了。在这里我还是想谈谈我的陋见。
上面你描述需求这一块的内容相当少，是不是说需求你们做得还不错，基本上不存在变更的问题。如果需求做好了，为什么设计会有问题？有点不理解。
在不明确需求时，可能项目计划只是比较粗的表述，但大概一个项目每个阶段所占的工作量有个大致的规律，主要确定几个大的点就OK了。当需求确定后，你可以用delphile方法，把那些所谓比较牛的开发人员招集起来，大家一起来评估各功能模块的规模，以及工作量。这样子可以为你做计划提供参考。也可以成为一部分反应项目进度安排的数据，跟领导讨价还价的法码。
整个过程看下来，好像觉得你做得事情挺多的，不过对于项目管理这一块好像涉及得不多。不知道你的团队凝聚力如何？有的时候大家的沟通，团队氛围也是非常重要的。在分配任务时，大家是不是有什么意见，或者说每个人是不是承担了一份自己最善长的功能模块。这对提高项目进度也非常重要。所以前期你是不是应该通过不同的渠道了解到你的项目成员素质。
还有你提到的一些什么评审，还有什么很正规的文档。我觉得小公司并不用这么严格的要求踏实做好每一步，就可以了。比如，需求确定时，尽量让参与的人一起来了解需求，一起分析需求，不明确的尽量在前期解决掉，技术实现有问题的也可以在这阶段处理。其实真正的编码并不需要太长时间，所以大可以放心，只要大家真正理解了需求，而且需求变动不是很大的话，问题都不大。而且一旦理解了需求，返工的现象也基本可以解决。
先谈这些吧，有选择的看看吧。嘿嘿

fqking

原帖由 jane 于 2008-8-14 21:19 发表
好像这个问题在我们公司也比较多，好在我们有个售后维护部，可以缓解下源源不断反馈回来的BUG。
看到你的描述，以及不少专家的高见。问题和解决方案差不多都明了。在这里我还是想谈谈我的陋见。
上面你描述需求这一 ...

需求在以前的项目中,是个大问题,老变.这次因为我在需求上卡的比较严,所以变更不大.而且设计初衷就是先做个东西出来,我只要主干需求就行,其他的能推后的都推后了.
可能我有点没说清楚,我们设计的变更不是由需求变更引起的.比如这个项目我们是要做一个网络硬盘集成到以前的产品中.项目时间有限,所以设计的时候就准备采用开源的FTP协议.但是设计的时间很短,只能找一个比较牛的开发来设计,设计的重点放在与原来系统的结合以及计费等方面,详细设计只是列出我们需要在FTP协议上扩展些什么功能.但是,在设计完成的时候,连采用哪个开源代码都不知道.所以,在编码的时候,我们要边分析代码边做,这里就容易出现一些技术瓶颈(而这些受代码框架引起的问题,我们在设计的时候完全没法知道,因为那时都不晓得将来用哪个代码).或者,发现一些逻辑有问题,这个应该跟评审有关,主要大家就是参加评审也因为各有各手头要紧的事,不是很投入,只想快点搞完回去搞自己的事.这个方面我应该去加强,不过不知道有什么办法能让他们能真正投入进来呢?

团队凝聚力绝对没问题,这个可能是我唯一有信心的地方:)

iamredeye

这样的话其实焦点问题越来越清晰了，项目的主要问题在于technical risk。设计之后要投入多一些精力去验证或评估feasibility。

iamredeye

原帖由 fqking 于 2008-8-14 18:44 发表



在项目初期考虑过用迭代,可是怎么说呢..我们现在做的就是第一版,从宏观上讲就是迭代的第一次.功能是选取的经典短小的.开始准备使用迭代是根据设计来选择的,后来因为设计的更改,发现迭代失去了意义(因为功能是串 ...

讨价还价的基础是项目管理环境。pm把pragmitic的plan拿出来，老板用懂项目管理的脑子思考一下哪里合理哪里不合理。所以项目管理受公司环境（即项目的环境）的影响很大，属于org的范畴。

这可能对你来说没啥用，等于是废话。。。sorry

step365

:victory: