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

jane

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

jane

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