专家评审之痛
来源:互联网 发布:windows系统发展史 编辑:程序博客网 时间:2024/04/29 14:36
这周专家请了专家做项目评审,三个高校教授,兄弟单位的软件开发人员。我因它事未能参加,评审结果到目前为止仍为保密。从多渠道的消息分析看来,评审结果不理想。怨言主要集中在几个方面:
1、专家对项目本身的不了解,只凭15-20分钟就对项目的工作量、难度、创新点作出一个量化评价,说实话太难为专家。
2、项目介绍的人员文不对题。过多的阐述技术,对比技术,而对项目本身要干的工作陈述不清,也不明确。
3、本次邀请专家对项目管理的实质我看来其实成了一个用“专家法评估项目时间”,而与当初考虑评审项目架构、技术路线、工作量等想法相去甚远。
4、专家们提到了几个问题,个别项目范围过大,风险难以控制。也不知道领导是否意识到。
5、有两个项目,项目与项目之间有较多的重叠,因为部门利益而都上,实际为双方都带来了重大风险。
6、结果不让项目参与评审,工作量根本没有衡量项目开发团队的水平,这工作是不是漂在水上了呢?
专家能为我们解决什么呢?我疑惑。以前,我希望专家的意见能消除领导对项目经理的疑虑,希望他们认识到项目经理没有忽悠他们。从目前的情况来看,这个目的很难以说明达到。反而导致了项目组之间的矛盾,项目组对专家的抵触,这可能是谁都没想到的。管理体系不是一天建成的,我们总是一鳞半爪的学恐怕适得其反。
- 专家评审之痛
- Scrum之 评审会议
- Scrum之 评审会议
- 静态测试之评审
- 评审
- 评审
- 软件需求评审之道
- 软件需求评审之道
- 软件需求评审之道
- 可评审代码之道
- 软件需求评审之道
- 《需求管理》系列之三需求评审
- 软件需求设计评审之八项注意
- 软件需求设计评审之八项注意
- 软件需求设计评审之八项注意
- 软件需求设计评审之八项注意
- 软件需求设计评审之八项注意
- CMMI再认识之“软件同行评审”
- apache+php初试
- 为什么近期芯片产能如此吃紧?
- 一位软件工程师的6年总结(写的很好)
- 快速选择——寻找第k小的数
- 先这样了
- 专家评审之痛
- 意大利“移动虚拟校园”技术[cnbeta,ugmbbc,2010.3.21](朱佳峰)
- 英美主要报刊杂志网站大全
- (二十三)继续幸福 - 2
- 令你大吃一惊的60个生活小常识
- (二十三)继续幸福 - 3
- 尴尬了,在 Google 自己的 JS 性能测试软件中 Chrome 仅列第三[古奥,2010.3.20](朱佳峰)
- (二十三)继续幸福 - 4
- (二十三)继续幸福 - 5