项目经理应该知道的97件事.docx
《项目经理应该知道的97件事.docx》由会员分享，可在线阅读，更多相关《项目经理应该知道的97件事.docx（60页珍藏版）》请在冰豆网上搜索。
项目经理应该知道的97件事
资料范本
本资料为word版本，可以直接编辑和打印，感谢您的下载
项目经理应该知道的97件事
地点：
__________________
时间：
__________________
说明：
本资料适用于约定双方经过谈判，协商而共同承认，共同遵守的责任与义务，仅供参考，文档可直接下载或修改，不需要的部分可直接删除，使用时请详细阅读内容
HYPERLINK"\o"查看原书"项目经理应该知道的97件事
以往的软件开发模式是先了解用户的要求，然后再在极度神秘的环境下进行
编程测试。
毕竟，用户根本不知道我们在做什么，对吧？
直至项目结束，我们的
魔术师才会匆匆登场，揭去魔法布，然后期望用户会对我们卓越的产品惊叹不
已。
然而用户此时的通常反应是：
“咳，好吧，我知道你们花了很多功夫，但我
们真正需要的是……”
今天，项目成功的秘诀就是尽早向用户展示任何可以展示的东西。
如果能在
项目启动早期，而不是当整个项目都结束的时候，就能发现项目中存在的问题，
那该有多好啊！
随着项目时间的推进，变更项目的成本越来越高。
重新编码、重新测试以及
改进当前软件的时间，加上整合外围代码进行集成测试所花费的时间都会大大拖
延项目进度。
如果变化非常重大，还可能危及时间和成本底线，需要经过变更控
制委员会一个漫长的批准程序。
在一些细小环节上做出的编程决策，或许对于软件开发人员和项目经理而言
道理十足，可当软件投入使用后却有可能给用户造成巨大的混乱。
我知道曾经有一个大型的培训公司，花了500万美元重新设计它的订购软件
系统。
此前，项目编号同订购产品之间的匹配存在一定逻辑性。
例如，4125可能
是学生手册，4225则是配套的学生练习盘，4325可以代表教师手册，4425则是
营销宣传时使用的课程大纲等。
你可以在同一屏幕上订购4X25系列的所有项目。
① PHR，即Professional inHumanResources（人力资源专家），是由美国认证协会（AmericanCerti-
ficationInstitute）推出的在国际范围内比较权威的人力资源管理知识体系认证资格。
——编者注
每天，全球140个地方的行政助理一遍遍地反复订购同类材料，并很快记住
了项目编号。
一旦知道了学生手册的编号，他们无须查看就可以立即键入其他项
目的编号，这样一来，订购过程十分快捷。
在重新设计时，不知何故，这个项目团队居然忘记考虑实际情况下真人是如
何进行订购的。
新的设计方式中，项目之间没有逻辑关系。
项目6358可能就是
4125曾经代表的学生手册，而其配套的学生练习盘现在是 8872，而同一类教师
手册又是3392。
现在，不仅用户不得不逐项查询并试着“忘记”旧的编号和系统，而且同类
产品的不同项目也会分别出现在不同的页面上。
行政助理们很愤怒。
订购过程慢得就像是蜗牛在蠕动。
该项目最后远远突破
了它的时间和成本底线。
作为项目经理，你应该尽早并经常让软件开发人员和用户交谈。
2.避免打地鼠式开发
软件项目经理经常面临及早交付产品的巨大压力。
时间是关键。
你如何才能
快速完成任务呢？
假设你的团队有两名程序员，伯尼和罗布。
两人都很能干，知识面相同，
编程语言技巧也相当。
你发现在开发过程中伯尼实现软件功能的速度远远超过
罗布。
当伯尼着力于快速完成编程时，罗布正花时间写代码并对其进行重构①。
罗
布对变量和方法的命名更擅长。
一旦写的程序能够运行起来，他就把这个程序分
成几小块。
现在他要写测试来确保该程序的每一块都能按照他的意图运行。
当他
觉得结果比较满意时才宣称实现了功能。
但是假设你并不知道上述这些细节。
如果你只看他们谁先宣称实现了功能，
那么很明显伯尼表现得更好，对吗？
几个星期之后，你向客户演示这些功能。
像往常一样，顾客喜欢你已经完
成的功能，但现在需要你做一些改动和完善。
你让软件开发人员修改这些代码。
当你把新改进的功能带回给客户时，他们试用了罗布实现的功能，对他做出的
改动十分满意。
① 重构就是改动代码，完善其内部组成结构而不改变其外部功能。
它改进软件产品设计。
重构代码
是回过头去完善以前仓促创建并测试的某项可用的功能。
现在需要进一步对该功能进行内部改进，
以便长期使用，也使日后增加功能更为方便。
遗憾的是他们发现伯尼实现的功能有些奇怪。
当伯尼编写好新的功能后，一
些以前能使用的功能现在却不能用了。
客户把这些作为缺陷标记出来，然后你让
伯尼来修改。
客户又一次测试这些功能，结果后来新增的功能也不能用了。
这到
底是咋回事呢？
如果你有孩子，就会知道发生了什么。
伯尼创建的是一个打地鼠式的应用程
序。
打地鼠是一种游戏，孩子们拿着一个木棒敲打几个孔中随意弹出的地鼠，他
们会很惊奇接下来是哪个地鼠弹出来，而且还乐此不疲。
然而，在修改应用程序
的时候如果总有坏代码不知从何处随意弹出，那可不是好玩的事情。
那会令人沮
丧，结果也难以预料，并且它会减慢产品开发速度。
伯尼一开始就全速冲刺，只
是南辕北辙了。
尽管罗布从一开始就表现得较慢，但实际上他编写的代码更胜一筹。
事实证
明，他的节奏是可持续发展的。
由于最初编写的代码就有较好的质量，所以，他
才能更快地做出可行的改动。
而且他早期编写的测试能随时带给他反馈信息，让
他了解自己新写的代码是否与原有应用程序的其他部分兼容。
当估计某一功能的实现时间时，不要只考虑最初写代码所花费的时间，还要
加上提升、调整和改进这些代码所需的时间。
写高质量的代码和测试都需要花时
间。
从短期来看，这似乎是一种损失，然而它带来的却是长期收获。
问问自己，你是想要速度还是想尽情享受可持续发展的乐趣。
3.一词不慎坏大事
哪一个词会让你错过最后期限？
答案是“任何一个词”。
在开发一个将以非
英语语言发布的产品时，你将给项目带来许多新的风险和限制。
有些风险和限制是技术性的，且显而易见。
例如，如果你的产品将投放日
本，那么它必须支持适当的字体。
如果不支持，那么，即使英文版运行得很完
美，日文版的产品也无法运行。
但是，字体兼容性不受你的控制。
你和团队需要
特别注意的倒是一些特殊的翻译译法，并在编码前就要考虑到这些因素，确保开
发活动遵循有关国际标准，消除这类问题。
仅仅是转换成其他语言版本也会影响到你何时做何种决定。
通常情况下，产
品本地化（日语、瑞典语和德语等）与英语版本的开发是同时进行的，只是具有
一定的滞后。
滞后的时间可以是几天，几周，甚至几个月。
尽管如此，在某个时
间点，外文版的翻译必须要“赶上”英文版。
在测试和审查阶段，你需要确保：
英文版里的内容都可以被准确翻译过来； z
翻译过来的内容同英文版是真正相符的； z
翻译版产品的运行没有瑕疵。
z
这里有一个问题。
这三项事情可能是在英文版完成并批准后才进行测试的。
在测试和审查本地化的版本时，你总会发现不止一个具有挑战性的问题无法得到
解决，除非回头去改变英文版产品。
然而，要知道，在英文产品里最后一分钟所做的一个相对简单和低风险的改
变，如改写句子（这只需要几秒钟来编码），却往往需要好几天时间来运行和重
新测试所有本地化的版本。
这可能需要额外花费数千美元，尤其是当你正和一家国外的公司签订翻译合
约时。
经验不足的软件开发项目经理常犯的这个错误很简单。
他们就是低估了对
英文版进行意外更改所造成的影响有多严重。
为了预防这种情况发生，你可以采取以下两项主要措施。
在进度表最后加一个“本地化缓冲区”。
z进度表的截止日期意味着与项目
计划中的英语产品相关的所有工作都必须在这个有效期限内结束。
在目
标结束日期之后做的任何改动，都必须符合非常具体、非常严格的标准，
只有达到这个标准才可以“进入”返工队列。
这个版本的任何变化都不
可避免地引起其他外文版作出相应变化。
把这些任务排序，让功能的质量控制和英文文本的质量审查分开来做。
z
这其实很简单，甚至可以复制所有英文文本到一个电子表格里去进行校
对。
这样一来，如果有措辞不清楚的情况，我们就能立即发现它，而不
必等到测试可运行的产品时才发现它。
于是我们可以提前作出必要的改
动，可能就不需要对所有其他的语言版本都进行返工了。
4.让项目发起人自己写需求
项目失败并不是只有美国公司才遇到的问题。
根据几年前一家日本领先IT
杂志社进行的调查，如果按照质量、成本和交付期的标准来衡量，日本企业实施
的项目中，超过75%都被认为是失败的。
跟大多数其他国家一样，在日本，项目不能达标的首要原因几乎总是需求
定义太差。
处境最危险的公司是那些业务分析能力较差的公司。
由他们来做软
件开发这样的技术项目时，成功就被委婉地归为“不可能发生的”事项。
这一
结果表明，要发现、识别并定义一个软件项目的真实需求有多么困难。
既然是这样困难，很多项目所有人，如客户、项目发起人或公司主管，就期
望项目经理能自己定义和细化这些对软件的要求。
项目所有人很少会提供指导或
明确他们的需求。
既然是一个软件项目，而自己可能又不懂软件开发，所以，他
们认为没必要来亲自定义自己的期望。
而对于软件项目经理而言，他通常没有权力或时间来自己发现、选择项目需
求并排定优先级，尤其是当该项目可能涉及多个利益团体时，大家对软件完成后
应实现的功能可能会有相互冲突的设想。
项目经理要在项目实施前花时间与资助该项目的人交流，帮他们准确定义各
自想要的功能。
要能够迅速完成项目且只有少数错误，而且需要的预算尽可能地
少，这难道不是最重要吗？
但你又不能一箭三雕。
哪些资源和技能对创建所需软
件而言是至关重要的？
资助人是否给团队提供了这些资源？
软件如何用于运行基础架构或为公司赚钱？
时间期限是切实可行的吗？
这些时间限制是不是被写进客户合同，是否绑定到某个重要的节假日，是否据此精心
制作了一份营销计划？
如果在需求定义阶段没有认真、具体地考虑这个项目要创建什么，那么，这
个项目可是岌岌可危了。
请记住，项目所有人需要传达的是他们想要这个软件做
什么，而不是程序员将如何着手生成这一结果。
说服项目所有人，他们必须自始至终参与这个过程。
步调一致的需求计划可
以明确地将商业意义、项目目标和项目结果联系到一起。
否则，该项目不能产生
他们所期待的令人满意的结果。
失败的软件项目对项目所有人伤害最大，因为是他们资助了这个项目，是他
们一直期待着能靠这个软件赚回投资。
5.要简单，不要复杂
我的微波炉只需要有一个按钮，即“增加一分钟”。
要烧开一杯水喝咖啡，
我得按下按钮三次；要融化奶酪饼干，只需轻轻点击一下；为了加热玉米粉饼，
我按“增加一分钟”，到点后过15秒钟再打开门。
只有一个按钮的微波炉会通过产品规划委员会的认可吗？
可能不会。
看看我
的那台微波炉上的功能选项（都是从未用过的），我就知道，产品规划委员会喜欢
复杂而不要简单。
当然，他们可能会给“复杂性”冠以“功能丰富”的头衔。
没
有人从一开始就树立目标：
生产的产品就得极尽复杂。
复杂性总是意外出现的。
假设我有一块凉比萨饼需要热一下。
根据制造商的说明，我应该按“菜单”
按钮。
我现在面临的选择是“速热”和“再热”。
（嗯，我猜应该选择“再热”，
虽然我有点饿了。
速热会比再热快吗？
）
“饮料”、“面条”、“比萨饼”、“盘菜”、“酱”还是“汤”？
（我选择“比萨
饼”，尽管它上面确实有酱并且它也放在盘中。
）“熟食/新做”还是“冷冻”？
（当然都不是，它只是吃剩下的外卖比萨饼。
我猜应该选择“熟食/新做”。
）“一
块”、“两块”、“三块”还是“四块”？
我不知道这样的盘问将持续多久，所以我
按取消，然后按“增加一分钟”按钮。
这和软件开发有什么关系？
就我而言，A只有一个按钮，即“一
键购物”。
哦，当然，我第一次访问时必须输入我的地址和我的信用卡号码，但
现在我只要点一下就可以实现自己的冲动购物了。
软件通常要解决复杂的问题。
现在的问题是，那种固有的复杂问题中有多少
是你强加给最终用户的？
你的软件是不是一个复杂问题放大器？
成功的软件通常
是一个复杂问题吸收器，因为它首当其冲地为用户承受了复杂的问题，而不是将
这些问题一路传递给用户。
作为项目经理，你是复杂问题吸收器还是复杂问题放大器？
最优秀的项目经
理能够吸收程序员、最终用户和公司管理层等各方面抛出的复杂问题。
当最终用
户提出看似矛盾的需求时，你的任务就是帮助清理这些需求，而不是盲目地将这
些问题传递给开发人员。
当开发人员由于技术原因不能实现需求时，你的任务就
是翻译（吸收）这个复杂的问题，并向用户进行解释，用足够多的信息帮助用户
选择另一个途径。
使用你的应用程序有多容易？
为应用程序添加一项新功能有多容易？
对一
项新功能提出要求有多容易？
报告缺陷、部署新版本、回滚不良的版本又有多
容易？
简单性不会偶然发生，它需要积极培育。
而复杂性会因你不留意而丛生。
6.偿还你的技术债
不管是普通的市民还是成功的企业，只要他们管理得当，债务就是一种有用
的金融工具。
它通过对未来利润的预支来平衡目前的资金不足。
明智地使用短期
债务能够有效地消除现金大涨大落。
可一旦滥用，短期债务又会成为一个使企业
举步维艰的沉重枷锁。
在软件开发界，为了实现那些“处于危险之中”的里程碑，同时完善大部
分需要实现的工作，借用时间可谓是一种有效的策略。
沃德·坎宁汉（Ward
Cunningham）提出了“技术债”的概念，就是指在时间紧迫的情况下，开发人
员为实现迭代①目标或快到截止日期时所采取的一种方法。
在那一刻，他们无力
用很恰当的方式来处理代码，但采取一些捷径，他们也许能够让编写好的程序
“刚刚足以”冲过终点线。
即使这套软件是临时的、有缺陷的，但只要有效地管理出现的技术债，这就
是一种恰当的举措。
可是，如果这笔债没有得到偿还，它就会变成一个令人痛苦
的越滚越大的雪球。
如果持续向未来借债而不偿还，那么就会令整个项目变得岌
岌可危。
要想还清技术债，最好的方法就是评估在每个迭代结束前发生的所有“债
务”。
可以要求开发人员确定他们想要展开的临时修改②具体是什么，这样做需要
花费多少时间。
① 迭代是指由一个敏捷项目小组选择的一段较短的时期（一周、两周或一个月等），在此期间，该小
组会开发并测试由客户挑选的一个关键需求，并将结果发送给客户以征求其同意或意见。
然后，
小组会开始下一个迭代，以开发下一个最重要的需求并（或）纠正前一个迭代中完成的工作。
② 临时修改是指对一个在运行的编程问题作快速修复或解决，但这种解决方案并不是很理想，在时
间允许的情况下可能需要重新修改。
修改这种不完善的代码可以称为“展开修改”。
开发人员并不需要立刻还清债务，不过，趁他们对这些捷径仍然记忆犹新时
来估量所需的修复工作，当然是不错的。
一定要发现要重写的代码有什么具体问题，而不只是随意判断所需要花费的
时间。
不要借机偷懒，这是一种严肃的、保持代码库干净的有效方法。
另外，有越来越多的软件分析工具能自动帮助识别出现“技术债”的地方，
了解代码覆盖率、分析耦合性、检测风格偏离等，这些工具或许都可以在你不知
情时工作。
把留下“技术债”的地方记录到问题跟踪系统，并安排在以后的迭代
中解决。
只要可以平衡添加新业务功能的工作量并同时还清这些债务，就有可能
既满足客户的功能要求又不使这些“技术债”失去控制。
软件难用的原因有很多，但通常都归结到临时修改、文档不足、依赖关系不
恰当、快捷方式以及偏离预期设计等问题上。
当开发人员最终举手投降说他们需
要在一个系统上重打锣另开张时，实际情况极有可能是，许许多多没有偿还的技
术债已经使他们不堪重负，债台高筑之下，他们觉得还不如痛快地宣布这套软件
破产了。
只有一直坚持识别债务并迅速处理它，你才可能总是用“最低补偿”来避免
接踵而至的混乱。
在向业务利益相关者进行解释时，这种比喻说法可谓出奇地管
用，能让他们立刻明白软件如何会随着时间的推移而变得无法控制，以及为什么
应该投入力量保持代码洁净。
7.为团队增添人才而非技能
我过去采用的招聘标准同我们这个行业里的每一个人的招聘方式都是一样
的：
技能，技能，技能。
直到有一天，一位来面试的应聘者当头泼我一盆冷水
（这当然是一种比喻的说法），这次经历从此改变了我。
当时我正期望为团队招纳一个有多年微软工作经验的能人。
仔细翻阅了比尔
的简历，我觉得他非常适合这个职位。
他在所有相关技术方面都有六年多的经
验。
如果我能开出不错的薪酬，这将会是一件轻而易举的事。
比尔接受了面试。
我们先聊了聊，然后我向他介绍了我们手头上的一些项
目，并对他说他是多么适合这个职位。
我信心十足地认为这次招聘会进展得很顺
利。
可是突然间我意识到我会招不到他。
我中途停止了面谈，问比尔发生了什么
事。
我告诉他，他非常适合这个职位，也对他直说我感觉到他不会来。
他的答复是：
“理查德，如果我还想做过去六年来一直做的事情，我就会留
在我现在的单位了。
我听说你们即将开始一些非常酷、非常新的Java项目，所
以我才会想来这儿工作，因为我把它看成一个学习和成长的机会。
”
就在那时我才恍然大悟。
用“按技能挑简历”的方式来招聘新人，对一个要
创建团队的经理而言，实在是最愚蠢的方法。
你知道，我和我的伙伴之所以会进入这个高新技术产业，正是因为我们希望
走在科技的最前沿。
我们没有一个人希望在职业生涯中重复使用自己在大学学到
的那些技能。
我们之所以进入这个行业，正是因为这个行业所涉及的永远都是新
领域，永远都要学习新技能和新技术。
但不知何时出现了严重的错误。
我意识到我们在员工成长上已停止了投资。
我们不是在寻找新的人才，我们一直寻找的只是非常具体的精良技能。
现在我要
告诉大家，如果你们看到一个雇主在聘用新人时要求其技能达到精确匹配，那
么，这个雇主其实是说：
“我们不打算投资你。
”
对于所有努力创建强大团队的人，我要给出的忠告是：
请记住你要聘请的是
人才而非专业技能。
当为敏捷开发团队招聘技术专家时，我要找的是什么样的人
才？
他们需要具备的优良技能不过是在幼儿园里就培养的：
能和他人融洽相处吗？
z
能主动合作吗？
z
当完成任务后，会把自己的工作整理以做备用吗？
z
会对新事物感到兴奋吗？
z
喜欢学习吗？
z
至于技能，我可以教他。
事实上在我们的敏捷团队环境中，学习技术简单而
迅速。
然而，教一个成年人如何主动合作几乎是不可能的。
聘用人才而不是技能，这是组建团队的一种完全不同的方式。
那些满腔
热情、打算同我肩并肩一起开创激动人心的未来新技术的人，才是我想与之
共事的人。
8.西蒙，保持简单
项目的利益相关者往往使事情变得过分复杂，这是软件项目失败的一种常见
原因。
项目组成员一定有能力完整构想该项目的目标并完成实际工作。
可那些利
益相关者却臆想，只靠几个简单的、不可思议的步骤就能完成这个项目。
他们以
为实现最终解决方案是轻而易举的一件事情，哪怕这个项目很复杂。
利益相关者不应该把软件项目建成一个统一、巨大而僵化的怪物，而应该让
信息技术团队把项目建成一棵洋葱，每长一层就表示成熟一分。
现实世界中没有
其他可供选择的余地。
不论那些需求有多完善，总是难免会有变动。
如果你的软
件不够灵活，不能迅速适应不断变化的需求，那么这个项目甚至在开始前就注定
要失败了。
为了让事情保持简单，需要牢记下列关键点。
让需求保持简单 z。
需求分析人员往往会将自己脑海里冒出的某个解决方
案同依据业务需要而提出的实际客户需求弄混淆。
虽然实际的需求可能
会非常简单，但是由于需求分析人员和开发人员之间缺乏真正的理解，
会导致双方的交流并不到位。
需求分析人员应该用简单树形图写出需求。
根本需求是总体项目的
简单目标。
细小枝叶的子级需求被分门别类组成代表父级需求的枝叶。
在整个图中不断重复这个过程，直到每项需求都清晰明了。
可以使用软
件思维导图工具来依照这种方法记录需求。
只要明确了一个小子集的需
求，开发工作就可以开始了。
遵循敏捷开发过程 z。
一旦确定了一个小子集的需求，开发小组就可以立
刻开始创建原型。
只要原型可用，利益相关者就可以测试并提供反馈信
息。
客户的反馈信息能够确保准确的需求，同时发现需求经需求分析员
从实际客户传递到项目组时有可能形成的交流差异。
让客户看到原型，
也可以帮助检查开发人员设想的相应解决方案是否和客户所预想的一致。
这些差异变成新的需求，于是开发人员重做原型，接着周而复始重
复这个循环。
每个循环周期应尽可能地短，通常不超过两三个星期。
定义需求的一个小子集，按照陈述的需求创建一个原型，然后获得
反馈信息，这种循环能够确保项目的所有利益相关者总能达成共识，且
每个人对进展情况都感到很满意。
只要认真地遵循这些简单的技巧，每
一个软件项目都可以取得圆满成功。
这里说的成功意味着顾客满意且软
件实用，而且软件所提供的有效业务功能完全符合创建初衷。
9.你并不是非比寻常的
还记得你妈妈说的话吗？
“你是非比寻常的！
你是独一无二的！
”其实，所
有的妈妈都会这么跟孩子说。
相信那个爱的谎言，结果导致了许多常见的软件项
目问题。
我指导了许多不同的团队。
当按照软件项目的达标情况进行考核时，那些相
信他们是“非比寻常”的团队总是无一例外地落在了后面。
因为他们自认为是非
比寻常的，所以有着重塑一切的强烈倾向。
他们认为：
“其他的团队都不可能开
发出实用的软件，或至少没有我们这个团队创造的软件这么优秀。
”他们不从其
他开发团队的错误中汲取经验教训，而是闷头重复犯着同样的错误。
损失都由公
司买单。
他们把大量时间用在重写、调试以及把自己的奇怪想法运用到那些已经成为
行业标准的软件和工具①上，以至于他们永远都无法完成客户项目，而这些项目
才是他们应该出售来赚钱的产品。
这些虚幻而神奇的产品本可以像这个团队一样
非比寻常，当然，前提是这个团队真的有幸将它们写出来。
听听这群独一无二的开发人员是怎么说的吧：
任何现成的构建系统都不可能
处理他们“独一无二”的需求。
因此，他们必须为每个新项目编写一个新系统。
不用现成的对象数据库映射工具，他们要写自己的。
网络应用程序框架？
他们信
奉：
“我们可以做。
”持续集成？
行。
测试工具？
我们也能写。
他们当中那些最自
负、最痴迷的人甚至还尝试自己编写编程语言。
① 工具：
软件开发人员用来创建、调试、测试、分析、追踪或以其他方式支持高质量的软件开发的
简单程序。
那么这些团队每天都在做什么呢？
由于舍弃不用那些通常都可以免费获得
的、功能完善的软件工具，他们要自己创建那些未经检验的代码，由此便出现许
多问题，而他们每天就是在解决这些问题。
如果是编写自己的数据库层，他们每
天就要追踪隐藏的缺陷和问题。
处理这些边缘事件①所花费的时间非常多，如果
他们能学习或者修改现有的工具，那花费的时间将会少得多。
不那么“非比寻常”（但却更成功）的团队之所以会使用现成的工具，那是
因为他们准备解决的问题都是很棘手的。
他们需要可靠的工具，因此他们的注意
力集中在软件项目的解决方案上，而不是试图为一个已经满满的工具箱再装入一
个工具。
这和有效的软件项目管理有什么关系呢？
不要让你的程序员白费力气做重复
工作。
如果他们跑来跟你解释他们的问题
升级会员 