你不是一个人在战斗——软件项目团队模型
摘要:
俗话说“三个臭皮匠胜过诸葛亮”,但实际工作情况往往是“三个诸葛亮不如一个臭皮匠”!
软件开发是智力型团队,如何发挥每个人的作用,并将所有人的力量扭成一股强大的项目团队战斗力,这是项目团队模型要重点解决的问题。
大纲:
1、传统项目团队模型
2、实际项目团队模型
3、MSF的项目团队模型
4、实用团队模型
5、什么才是合适的项目团队模型?
正文:
传统项目团队模型
什么是项目团队模型?简单地说就是项目以怎样的方式组建团队,软件开发项目团队的传统团队模型如下:
项目组在项目经理的带领下,各角色协调工作,为项目成功而努力!
各角色的具体职责如下:
项目经理:整体协调项目,编制计划及保证计划执行,推动项目成功。
系统分析员:分析系统需求,保证系统需求既满足客户要求,同时保证技术可行性;指导项目技术方案及系统架构设计。
软件设计师:细化系统设计。
程序员:编码实现设计。
测试工程师:测试系统,保证系统满足需求。
实施工程师:部署、调试系统,培训客户,协助客户推动系统上线运行。
配置管理员:对整个项目周期中的工作产品实施配置管理。
QA:质量保证工程师,保证开发过程按照既定的要求进行,保证工作产品符合既定的规范。
这个传统团队模型有两大特点:
1、一个团队总有一个头(这也是我们的惯性思维),这个头就是项目经理。
2、假设各种专业的角色能协调工作,并能各自发挥所长。
我们希望项目团队能有一个强大的头领,加上一班专业人才,共同为项目成功而努力。
但实际情况有这么理想吗?
项目经理会埋怨手下能力不够、不主动报告工作、不主动承担责任......
而项目组成员会埋怨项目经理不够强,只会叫他干活,不授权,更加不会传授知识......
实际项目团队模型
我们实际项目的团队结构,往往是这样的:
很多项目往往没有专职的系统分析员和软件设计师,项目经理兼任需求分析与软件设计的工作,甚至还需要负责编码的工作。
图中系统分析员、软件设计师这两个角色都是虚线框,意思就是表示这两个角色往往只是虚位,难以落实具体的专职的人员。
项目经理要做的事情太多了,往往没有办法专注项目管理,项目计划相关的文档能免则免,项目设计文档能少则少。
造成这种不平等的原因主要有两个:一就是开发人员的天生优越感,二就是整体来说我们的测试工程师、实施工程师水平确实还不够
在我们公司其实也有这样的“不平等”情况,我花了很多时间营造“平等”的氛围,我的主要办法有:
图中这两种角色是灰色的,这两者可能是整个项目团队中最“惨淡”的角色了!
造成这局面原因也主要有两个:一就是大家的习惯性思维认为这两个职位就是最不重要的,二就是我们的配置管理员、QA的水平还不够的问题。
对于配置管理工作,其实实质就是项目生命周期中各种工作产品的管理工作,我认为项目经理应该发挥更大的作用,而我们的配置管理员应该嵌入到项目的具体中去完成工作,而不要只抱着配置管理的大道理来工作。
QA确实是最痛苦的职位,优秀的QA需要有资深的项目经验,但有资深项目经验的人大都不愿意做QA,这是多么矛盾和痛苦啊!
MSF,全称是Microsoft Solution Framework,微软解决方案框架,是微软进行研发活动的方法论。
此图来自MSF的官方资料
微软的团队是没有项目经理的,由6类角色组成,分别是产品经理(Product Management)、程序经理(Program Management)、开发(Development)、测试(Test)、发布管理(Release Management)、用户体验(User Experience)。
各类角色负责的职责如下:
该模型的几个重要特点:
1、没有所谓的项目经理。
程序经理这个角色可以说是最接近项目经理的了,他需要编制计划及跟踪计划执行,但在行政级别上,他不是大家的头,大家都是平等的,大家只是处在不同专业的角度来负责工作。
2、强调项目团队是由各专家组成的。
软件开发活动是高强度高挑战的智力活动,我们需要由各类专家共同负责协调工作,每位专家都是同等重要的。
3、用户体验是我们常常忽略的部分。
用户体验简单地说就是用户使用软件时的感觉,软件的颜色、布局、文字、行为等等会直接影响用户使用软件的满意度。目前我们国内的项目组,往往没有用户体验设计环节,也没有专职的用户体验设计师。
我第一次学习MSF团队模型时让我很震动,该模型体现了以人为本的开发模式,让团队中的每个人都极受鼓舞,但该模型在实际工作中很难完全应用,主要原因如下:
1、各专业人才水平参差不齐。
我的个人感觉国内以上六类角色的水平由高到低排列,大致这样:开发、程序经理、产品管理、测试、发布管理、用户体验,而用户体验基本是空白。各专业人才能力不相当,就无法组成“无头领”的团队,充分发挥各种角色的作用。
2、各专业人才水平全部没达到要求。
哪怕是水平最高的开发角色,我们的平均水平跟微软的相比还是相差太远,那就更加不需要提其他角色了。
3、团队协助能力差。
我们的团队基本不会“team work”,我们从小到大的教育就基本没有“team work”的教育。
MSF常常也被人以“太理想化”质疑,MSF所描述的世界只是软件开发的乌托邦而已。难道我们的现实情况就决定了我们的项目团队水平吗?我们没有办法建立一种实用的项目团队模型,让我们的项目团队能持续进步吗?
实用团队模型
我带领过很多团队,其中不少是带领应届生或者是工作经验还不多的工程师,团队中每个人的能力如果还不能塑造好,确实无法让团队高效运作。而项目初期我做的很多事情,都是通过项目具体工作来训练大家、提高每个人水平的事情。
我们的计算机相关教育并没有训练出合格的各类专业人才,但我们这般计算机从业者都是充满激情和追求进步的,基于这样的现状,我觉得应该有合适的团队模型能让我们的项目团队自学习,然后逐步发挥各专业人才的作用。
我们光抱怨我们的教育制度是没有用的,我们需要实用的团队模型来解决当前的实际问题。我在实际项目中的项目团队模型,通常是这样的:
角色和人并一定是一一对应的,一个人可以戴多个角色的帽子,一种角色也可能由多个人担当。
上述模型有8种角色:项目经理、产品经理、软件设计师、用户体验设计师、测试工程师、实施工程师、配置管理员、QA。
前面六种角色分别与MSF的程序经理、产品经理、开发、用户体验、测试、发布管理角色类似。
我基本上是很认可MSF的项目管理思想的,但为了适应实际情况,我做了一些必要的调整。
这个人不一定非常强,但只要他是项目组所有人中综合能力最强的人就可以了。项目经理除了领导项目团队,他需要更关注项目成员的成长。项目经理进行相关决策的时候,应该充分发挥大家的参与性。
犯错不可怕,只需要能不断学习不断总结不断进步就可以了。整个项目小组是学习型成长型的团队,要人人勇于承担责任,不怕犯错,遇到问题一起来总结进步!
1、项目中的每个人尽管水平和能力不一致,但应该都被平等的对待,所有人对项目同等重要。
2、水平和能力较高的人,应该承担更多责任,并且有责任推动项目组人员提高水平。
3、“学习、总结、进步”,是每个项目团队应该具备的基本特点。
4、项目各角色的划分其实是灵活的,但项目所有人员的整体能力和水平,应该能覆盖实用项目团队模型的8种角色。如果缺失某种角色,或者某种角色的水平较低,项目组则应该有计划地去增强这部分的水平。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/
10、软件质量工程师指南 - 软件项目角色指南系列文章 第9章 软件质量工程师 软件质量工程师也是分配在项目质量控制部里的编制,对项目的软件编码质量等进行管理,与软件配置工程师相比,主要偏向于对项目的质量控制部分进行管理。虽然在项目管理过程里没有详细划分这个岗位,但是在项目管理中仍然需要软件质量工程师对整个项目的质量进行控制管理。
《程序员度量:改善软件团队的分析学》一软件团队是成功还是失败 本节书摘来华章计算机《程序员度量:改善软件团队的分析学》一书中的第3章 ,Jonathan Alexander 著 张燎原 周峰 张刚 宋励奋 译更多章节内容可以访问云栖社区“华章计算机”公众号查看。
相关文章
- 有黑客精神的IT老兵与创业团队中坚力量——汤城
- 企业团队使用Git协同开发的一般流程
- 自然语言交流系统 phxnet团队 创新实训 项目博客 (四)
- 自然语言交流系统 phxnet团队 创新实训 项目博客 (三)
- 自然语言交流系统 phxnet团队 创新实训 项目博客 (十一)
- git 提交团队项目代码的流程
- 【华为云技术分享】【DevCloud · 敏捷智库】项目团队人员变动频繁,如何对新人进行有效培养和管理?
- PHP团队 编码规范 & 代码样式风格规范
- 深入诈骗团队
- 阿里技术团队如何开项目复盘会
- 微服务实践:全栈小团队“洪荒之力”改造阿里服务CRM技术体系
- 项目团队管理 Atitit 职位的自动分配草案 attilax总结
- Atitit.软件研发团队建设原理与概论 理论
- Atitit.软件研发团队建设原理与概论 理论
- atitit.团队建设总结fx O622
- 腾讯技术团队最新出品,Android Framework系统框架底层原理解密
- 对于有志于成为架构师的开发者,支付宝架构团队有何建议?
- 【华为云技术分享】【DevCloud · 敏捷智库】项目团队人员变动频繁,如何对新人进行有效培养和管理?
- 【关于ChatGPT的30个问题】26、ChatGPT的开发团队是谁?/ By 禅与计算机程序设计艺术
- 转:高创新团队
- [Git & GitHub] 怎么团队合作多人开发项目
- 敏捷测试团队组织构成