惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
量子位
M
MIT News - Artificial intelligence
Y
Y Combinator Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Google DeepMind News
Google DeepMind News
Hugging Face - Blog
Hugging Face - Blog
博客园_首页
雷峰网
雷峰网
I
InfoQ
罗磊的独立博客
博客园 - 聂微东
酷 壳 – CoolShell
酷 壳 – CoolShell
大猫的无限游戏
大猫的无限游戏
D
Docker
H
Hackread – Cybersecurity News, Data Breaches, AI and More
腾讯CDC
博客园 - 三生石上(FineUI控件)
The GitHub Blog
The GitHub Blog
K
Kaspersky official blog
P
Privacy & Cybersecurity Law Blog
S
SegmentFault 最新的问题
T
Threat Research - Cisco Blogs
H
Help Net Security
小众软件
小众软件
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
C
CERT Recently Published Vulnerability Notes
WordPress大学
WordPress大学
T
Tenable Blog
T
The Blog of Author Tim Ferriss
C
Cisco Blogs
Simon Willison's Weblog
Simon Willison's Weblog
博客园 - Franky
A
Arctic Wolf
T
Threatpost
Scott Helme
Scott Helme
C
Cybersecurity and Infrastructure Security Agency CISA
D
Darknet – Hacking Tools, Hacker News & Cyber Security
T
The Exploit Database - CXSecurity.com
G
GRAHAM CLULEY
Security Latest
Security Latest
Spread Privacy
Spread Privacy
L
LINUX DO - 热门话题
V
Vulnerabilities – Threatpost
P
Privacy International News Feed
S
Schneier on Security
Latest news
Latest news
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
C
Cyber Attacks, Cyber Crime and Cyber Security
C
CXSECURITY Database RSS Feed - CXSecurity.com

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
以角色为基础的软件开发团队建设
我观世界观 · 2023-10-02 · via 人人都是产品经理

软件开发管理的重要任务之一就是团队的组建。本文提出了一种以角色为基础的团队建设方法,以有效提高团队建设能力。在软件开发过程中,对开发和管理活动进行分解会产生一系列的子活动,对子活动及其相关知识的抽象产生角色——问题角色;对人的分析和抽象也产生角色——人员角色。

在软件开发过程中,对开发和管理活动进行分解会产生一系列的子活动,对子活动及其相关知识的抽象产生角色——问题角色;对人的分析和抽象也产生角色——人员角色。

问题角色与人员角色的有效关联也就是团队的组建,问题角色与人员角色的再定义和改进也就是团队的建设。以角色为基础来进行软件开发团队的组织,能够比较全面地解决项目管理问题,而且团队建设很容易达到可持续改进的目的。

角色抽象作为一种载体,可以很好地进行软件工程知识体系和企业知识地图的组织,满足企业知识体系持续改进的需要,因此角色团队组建和建设也可以作为软件工程实施方法之一。

软件开发项目立项时,重要工作之一就是开发团队的组建;在软件工程实施(把软件工程研究结果产生的标准或规范如ISO、RUP、MSF、XP具体应用到软件开发活动的程称为软件工程实施)的过程中,要解决的问题之一就是关于团队组建规则的定义;从企业发展的角度来看,软件开发团队建设是企业建设的重要任务。总之,软件开发团队的组建和建设是企业经营和发展的重要内容之一。

几乎所有的管理知识体系或规范都涉及到个体和团队建设问题,比如组织行为学[Stephen P.Robbins,1997]对个体和团队的行为进行了研究;项目管理[PMI,2000]中的计划、人力资源管理、项目集成管理、项目沟通管理等多个项目管理领域都涉及到团队建设和管理;在软件能力成熟度模型(CMM)[SEI,2000]的发展过程中,从个体软件过程和团队软件过程来研究软件的开发和管理。对个体和团队管理的研究是管理学的核心任务,涉及到的知识和学科纷繁、复杂。

然而,在管理的具体实施过程中,客观上管理环境的不同及主观上管理者的偏好,一般会在理论或规范基础上进行简化、删减、方向取向、分类归纳等工作,最后表现为各自独立的制度、规则、知识、评估方法、认证等多种独立体系,失去了其内在的联系,管理工作仍然复杂,而且不利于改进。

瑞理统一过程(RUP)[Rational,2001]通过对工作流分解的方式进行了软件开发过程及活动的分解和定义,并以角色为中心来进行知识、活动、规则、工具等的关联组织,从而把软件开发活动一体化、层次化、结构化,并保持其内在的有机联系,为个体和团队软件开发活动提供了很好的指导。

本文以“角色”这一概念为基础,提出了“以角色为基础的软件开发团队建设”的观点,阐述了其原理和方法,并对其优、缺点进行了分析,简要说明了该方法对“软件工程过程改进”的支持。

为简化叙述,文中“以角色为基础的软件开发团队”简称为“角色团队”,对应地,其它一般团队简称为“一般团队”;许多地方把文档、资源、信息、规则等统称为“知识体系”。

一、角色的含义

根据RUP[Rational,2001]的定义(如 “图 1 RUP中角色的含义”所示),角色的含义是:角色是抽象的职责定义,它定义的是所执行的一组活动和所拥有的一组资源。角色通常由一个人或作为团队相互协作的多个人来实现。

图 1 RUP中角色的含义

角色定义是一种管理上的要求,是“以活动为基础的管理”的表现形式,角色定义的依据是:问题、人、管理都可以分析为一系列活动的组合,这些活动有输入、输出,需要一定的环境和工具,需要活动承担者具有一定的能力,所有这些要素都是可以定义的,其联系的核心可以称为“角色”;管理本身的任务包括对问题域的角色分解、对人的角色分解、问题角色与人员角色的配对等。

因此,我们可以定义通用的角色模型如“图 2 通用角色模型”所示。

图 2 通用角色模型

通用角色模型的含义:

  • 角色是活动的承担者,角色与所需要的知识、工具、环境、输入、输出相关,是分析和定义结果的抽象,是一个容器;
  • 角色是构成知识体系的基本粒子,角色粒度大小和层次构成根据企业对角色团队掌握的成熟度灵活控制。

问题角色容纳了对问题域的认识和分析结果,人员角色满足预定义的能力和人格要求,并在掌握了相关知识和工具后获得认证;问题角色和人员角色关联后,人员角色利用知识、工具、输入文档等进行创造性活动,解决问题角色的需求;关联活动产生的结果经过总结、分析,进行经验总结反馈,从而可以改进问题角色和人员角色的定义和认证,为组织进步提供通道。

二、角色团队组建原理

在软件开发实践中涉及到的问题、人、管理都具有一个共同特点:复杂,人类解决复杂问题的方法离不开“分解”,分解结果被定义为一系列的“信息点”,由于这些“信息点”的粒度、层次、构成还是太复杂,因此又被进行分类、归纳、总结成为一系列的“知识体系”,这些“知识体系”各自有重点,同时又具有一定的相关性,有的发展为“学科”,有的发展为“规范”,知识体系在具体应用时又以知识、规则、制度、工具等各种方式来具体体现。

在这些分析、综合、归纳、合并的过程中,关联性并没有消失,但是变得难以掌握和理解——在学习的过程中很少有机会同时应用多种知识及其关联性,而在知识的具体应用过程中,由于其庞大、复杂,只有少数专家能够充分理解、综合应用,大部分人难见全貌、只见一斑,能够学习独立的学科,但是很难根据相关性进行综合应用。于是,又产生了一个新的问题:良好的知识体系得不到良好的应用,这就是常见的“理论与实践脱节”问题。

“角色”是一个抽象的概念,通过角色,能够有机地把知识体系以及实践结果联系在一起,而且是恰到好处——只有需要的知识体系和实践结果才和对应的角色进行关联,通过角色粒度的控制甚至可以达到这样一种效果:只要符合了角色定义要求,那么就能够顺利完成角色活动。另一方面,角色概念与“社会化分工”原理不谋而合,主要差别仅仅是粒度、层次上的差别而已。

人员角色并不代表个人,而是说明个人在某一具体业务活动中应该如何表现以及他们应该承担的责任。角色有一组互相联系的活动需要执行,这些活动密切相关,在功能上互相补充,所以最好由同一个人来执行。活动与知识体系密切相关:知识体系提供活动的输入和输出,并提供活动之间的通信机制。项目团队成员在履行角色职能的过程中,一个人可以担任许多不同的角色,一个角色也可以由多个人来承担。

三、角色团队组建方法

根据“角色团队组建原理”,角色团队组建就是面向问题、人进行角色的定义和关联,把相关知识有机地分布到角色上去,在具体团队组建时进行合理关联配对:让合适的人在合适的时间利用合适的工具完成合适的任务。

1. 从问题分析角色需求

根据相关知识体系、过去的定义、经验、角色定义原则,把解决问题的过程分解为子问题及子活动,控制子活动的粒度甚至粒度层次,并就每个子活动进行关联分析、环境分析、知识分析,最后定义为角色,称为问题解决角色,如“图 3 从问题分析角色需求”所示。

图 3 从问题分析角色需求

 2. 从人员分析角色认可

根据企业发展要求、角色定义原则、人的能力、兴趣等要素,对人进行分析和认可,控制知识体系的粒度、相关性等,最后定义为角色,称为人员认可角色,如“图 4 从人员分析角色认可”所示。

图 4 从人员分析角色认可

四、角色团队组建

在项目团队组建时,根据对问题域的分析结果,在成员角色表中选取对应的角色去承担问题角色任务,并从项目管理的角度来进行工作时间分配、费用预算等。如果企业内部没有所需要的角色,则可以考虑寻求外部资源。如“图 5 以角色为基础的团队组建”所示。

图 5 以角色为基础的团队组建

五、角色团队组建与建设过程

角色团队组建是发生在项目立项时的工作,而角色团队建设是在企业经营的整个生命周期内都要进行的,建设结果是角色团队组建的基础。建设是持续性的,组建是临时性的,建设为组建提供基础,组建后的项目团队的实施结果为建设提供依据,整个过程如“图 6 角色团队组建与建设过程”所示。

图 6 角色团队组建与建设过程

角色团队建设要完成的工作有:

  • 通用问题域角色定义:定义企业开发领域的通用问题,根据对通用问题的解决“从问题分析角色”工作,定义问题域角色体系;
  • 通用人员角色定义:根据“问题域角色体系”,对人进行分析、定义和认证,建立关于“人员角色体系”;对某些超出问题域角色体系的人的角色也进行定义,选择标准可以根据企业的发展方向进行选择;
  • 问题域角色与人员角色映射规则:为了适应企业业务的变化和发展、满足管理要求,问题域角色与人员角色不一定要一一对应,甚至粒度、层次也可以不一样,所以要建立映射规则为以后的工作安排提供指导。

角色团队组建时要完成的工作有:

  • 具体问题域角色定义:以“问题域角色体系”为基础,分析项目所面临的问题,定义“项目角色体系”;
  • 具体人员角色定义:对照“项目角色体系”和“人员角色体系”,根据映射规则,进行配合、关联、调整,完成项目团队的组建和任务计划,进行项目实施;
  • 角色体系改进:在项目实施的任何时刻,如果有超出“问题域角色体系”的角色产生,可以根据需要补充到“问题域角色体系”中,对人员角色体系的变化也可以采取同样方法处理。

在具体的角色团队建设过程中,实际上可以保留多个层次的角色体系,主要原则就是适应企业的经营要求和发展要求,其它相关内容如取舍、粒度控制、层次控制、结构控制、管理、认证等原则和方法本文不再赘述,部分内容可参考RUP。

  • 角色团队分析
  • 一般团队面临的问题和原因

在过去的实际管理过程中,一般团队存在很多问题,包括:

  • 结构简单:过于简单化,“开发团队”等于“工程师集合”,其相关性控制、团队配合等全部依赖于领导者的直觉或感觉;尽管不会完全错误,但是不够精细,属于“粗放”管理范畴;
  • 管理困难:缺乏层次级别,几乎都处于同一个层次上,令难行,禁难止;
  • 职责不清:针对工作内容,一方面缺乏规范,另一方面范围模糊,因此导致职责不清楚,工作目标模糊;
  • 资源浪费:由于组织和管理不力,软件开发效率低、成功率低,并期望通过提高个体素质来提高效率或成功率,片面追求文凭,本科不行用硕士,硕士不行用博士,等等,导致资源浪费,经营成本高;
  • 发展缓慢:团队的进步没有明确的计划和方向,团队的进步依赖于个体的随意发展,因此团队的建设变成了艰难地培养“全才”,很难培养“专才”;企业发展不明确,员工发展也不明确。

导致上述问题存在的根本原因是什么?我们认为,主要的原因有:

  • 对问题的认识不充分:没有对问题域进行定义、分析、内容组织,或者比较薄弱,仅仅从比较高层的软件开发的“需求、分析、设计、开发”出发来进行开发团队的组织,缺乏“具体问题具体分析环节”;
  • 对人的认识不充分:对个体的认识依赖于管理者的直觉、感觉和经验,个体的发展依赖于自己的兴趣,把工作当成任务,过多依赖于文凭评价;
  • 对管理的认识不充分:过分依赖管理者的直觉和感觉,安排任务时“大体上”知道存在的问题、什么人能解决什么问题,但是没有进行问题的分化、定义、具体化等细节工作,比较“粗放”;管理过于依赖于权力;
  • 过于平面化和大粒度:从问题认识、人的认识、管理认识三个方面都缺乏层次化、模块化和结构化,分工粒度过大,忽略问题的多样性、人的多样性、管理的多样性,决策一刀切;

最基本的原因是全面性问题,不够全面导致管理不到位:用不合适的方法去解决模糊的问题,如“图 7 一般团队的问题域覆盖程度”所示,应该解决的问题没有解决,解决问题的人又不一定是合适的。

图 7 一般团队的问题域覆盖程度

六、角色团队对问题的解决

角色团队通过“问题角色体系”的建立来促进对问题的分析,很大程度上解决了一般团队存在的“不够全面”问题,改善了对问题域的覆盖程度,如图“图 8 角色团队提高问题域覆盖程度”所示。通过“人员角色体系”的建立来进行培训、认证、甄别,促进团队建设,并为薪酬体系、绩效考核提供依据。角色团队组建后,管理定位更加容易:管理者有事可做,有章可循;被管理者明确管理定位和职责,依照角色关联的合作更加顺畅。

图 8 角色团队提高问题域覆盖程度

更重要的是,角色团队的组建和建设过程,就是企业知识体系的建设过程,角色体系也就是知识体系,角色体系的改进就是知识体系的挖掘和进步,是学习性组织的良好选择。

七、角色团队的缺点

角色团队的建立和组建,其本身就是一项复杂的管理活动,需要有力的资源支持;角色团队的建设是一个持续性发展的过程,不是一蹴而就的,因此需要企业具有持续建设的需要和能力,也就不适合那些业务方向频繁变化、业务领域不明确的企业。

八、角色团队原理在软件工程实施中的作用

在目前软件工程实施中,“持续改进”无疑是最重要的思想;首先,改进就必须要有一个载体,这个载体必然是企业知识体系,因此也可以采用“角色团队”作为这一载体;其次,改进必须是持续的,也就意味着过去定义的知识体系能够在一定程度上重用。角色团队通过“角色”这一概念来进行知识体系的分解,通过粒度和层次的控制很容易达到高程度重用的目的,因此,角色团队原理可以在软件工程实施中作为实施载体来使用。

以角色团队为基础的企业知识体系还可以很方便地容纳软件工程规范,因而对软件工程的实施具有很高的支持性;通过“人员角色体系”的建立,可以达到对个体的针对性培训和学习引导,对团队的进步具有很好的引导作用。

由于角色粒度、层次控制的灵活性,角色团队的组建和建设可以从任何时候、任何规模开始逐步建设,非常灵活,满足企业逐步成熟的要求。

小结

软件开发是一项知识性活动、创造性活动,软件技术日新月异,软件应用领域复杂多变,所有的这些原因造成了软件开发管理的困难,导致了软件危机的产生。软件管理问题的解决,离不开对知识体系的依赖和对变化的适应。角色团队原理作为一个知识体系的载体以及对持续改进的充分支持,可以作为软件工程实施方法之一。

参考资料

[1]  Stephen P.Robbins,《组织行为学》(第七版),1997,中国人民大学出版社;

[2]  PMI,《A Guide to The Project Management Body of Knowledge》,2000;

[3]  SEI,《CMMI for Systems Engineering/ Software Engineering》,2000;

[4]  Rational,《Rational Unified Process 》,2000。

本文由 @我观世界观 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。