Project教程
Project多个项目如何调用共享资源库
Project Server或者Project Online版本是可以联机的，从而实现团队的协作功能。但其实绝大部分Project用户使用的都是Project Professional专业版，也可以理解为单机版软件。那么在单机版软件中，能否实现多个项目同时调用公司里的共有资源呢？也是可以间接实现的，我们来演示一下。首先我们创建一个共享资源库的文件，随便给这个文件取个名字，比如叫做“共享资源库”吧。在这个文件中，我们不创建任何任务，只在【资源工作表】中创建公司项目中可能会用到的资源。这里只是演示一下，我们就简单地创建2个资源吧，比如项目经理和设计师，我们也不改它的默认数量了，都是100%，如图1所示。【注意】暂时不要关闭这个共享资源库的文件。图1然后我们再创建一个新的项目文件，比如叫做“项目1”。在这个项目文件中，我们随便创建几个任务A、B、C，设置一下关联关系，并输入工期，这个不是本文的重点，所以随便设置即可，如图2所示。 图2
Project 2016中的工时资源是什么？
首先对于工时资源在Project中的定义为按照工时执行的人员或者设备资源，简单理解来说就是按照时间来进行费用计算的资源。例如：人力资源在Project中一般采用工时资源进行表示，还有就是租用办公室这一类型的费用，也算作工时资源，一般工时资源受时间影响。在Project中表示如下图：
Project 快捷键 快速定位到任务的条形图或者时间段
当我们用Project做计划时，经常用的视图也是默认的视图就是甘特图。在这个视图中，左侧是工作表区域，包含任务的很多数据，右侧是甘特图区域，就是显示任务对应的条形图或者甘特图。如果任务较多，那么可能条形图跨越的时间段也较长。如果我们想查看某个任务的条形图时，如图1所示，假如我们想查看任务12的条形图，除了在甘特图区域下方拖动左右的进度条之外，如图1中箭头所指位置，还有没有办法快速定位到任务的条形图呢？图1 想查看任务12的条形图这里我们给大家介绍一个快捷键小技巧。我们按Fn+F5，没有Fn键的电脑直接按F5，就会弹出一个【定位】的小窗口，在标识号那里直接输入任务的ID号，即12，如图2所示，然后点击确定按钮。图 Fn+F5 快速定位任务条形图如图3所示，这样的话，任务12的条形图就自动显示在甘特图区域了，这样是不是很方便呢？图3这个快速定位的快捷键，除了可以在【甘特图】或者【跟踪甘特图】使用外，在【任务分配状况】或者【资源使用状况视图】也是可以使用的，我们在【任务分配状况视图】给大家演示一下。
如何修改Project的默认字体、默认条形图样式
今天给大家介绍一个Project小技巧，教大家修改Project软件默认的字体或者默认的条形图样式。如果大家在Project软件【选项】设置中去查找的话，可能会发现没有设置默认字体的地方，那该怎么让软件默认就显示自己喜欢看的字体呢？我们点击【格式】主菜单，点击左侧的【文本样式】按钮，如图1所示。在弹出的【文本样式】窗口中，【要更改的项】后面默认显示的是【全部】，那么全部都包含哪些内容呢，我们可以点击这个下拉菜单看一下，其中包含 图1如果对于以上文本都想修改它的默认字体为“等线”，那么我们就选择【全部】，如果只想改某一类文本的默认字体，那就在【要更改的项】中选择对应的内容。然后设置字体，比如我们选择等线，如图2所示，然后点击【确定】。 图2这样字体修改了，假如也想把默认条形图样式也修改一下呢？比如在任务条形图的左侧默认显示任务名称，右侧默认显示任务的完成时间。
Project 如何调配资源
当资源过度分配了，肿么办？比如前面的例子，某吃货甲，一天之内给他分配了9.6个工时的吃量，这怎么可以呢，让人加班是不厚道滴。（前文说某吃货甲不是一个人在战斗，假设此处他的伙伴们已纷纷倒下，只剩他一个人了）有一个办法，就是让Project同学自己来处理，那就是【资源】选项卡下的【资源调配】，鼠标啪叽一点，就好了？哦不是，还有个选项，得告诉笨电脑是对哪个资源进行处理，然后才能【开始调配】。来，对比一下调配前后的区别。过度分配的红色警示确实没有了，但这个……工期变长了呀，说好的一天就把活全部干完的呢？所以，最后张同学也建议了，还是手动调配实在点。
Project教程 如何实现每次编辑后变化的单元格背景颜色如何更醒目？
在Project软件中，不论是Project 2010、2013还是2016版本，大家会发现，每次进行某些编辑或操作后，有些单元格的背景色就出现了变化。比如图1中，假如我们将任务9的工期从1天改成2天，我们来看一下软件界面会出现什么变化。图1如图2所示，我们看到，有些单元格的背景颜色变成了浅蓝色，这是什么原因呢？当在Project软件中进行某一步操作后，因为这步操作而引起变化的单元格，它的背景颜色就会以浅蓝色的背景显示出来，以便提醒用户前一步操作对整个计划所造成的影响，这是一个非常体贴和实用的功能。 图2虽然我们仅仅是将任务9的工期进行了修改，它的工期单元格显示成了浅蓝色背景，它的完成时间单元格也变成了浅蓝色，同时，与之关联的任务也发生了变化。比如任务9的摘要任务（任务6），它的工期和完成时间也由于子任务9的编辑而出现了变化，所以它的工期和完成时间单元格也变成了浅蓝色。再比如任务10，它的前置任务是任务9。而现在任务9的完成时间延后了，所以任务10的开始时间也延后了，所以任务10的开始时间单元格也变成了浅蓝色。同理，任务10的完成时间也延后了，所以它的完成时间单元格也变成了浅蓝色。按照同样的逻辑，我们也就可以理解为什么其他单元格颜色也变成了浅蓝色，所有这些变化都是因为上一步操作，即把任务9的工期从1天改成了2天。Project的这个功能，就是提醒用户，你的一举一动不仅会影响到当前任务，可能还会影响到其他任务以及整个计划，牵一发而动全身。单元格背景颜色的变化就是默认的一种提醒方式，当点击【保存】按钮后，这些单元格的浅蓝色背景就消失了。
如何直观看到Project每一步操作对整个计划的影响
当我们在Project中做计划时，每做任何一个操作，比如修改了任务的工期，比如修改了任务的前置任务，又或者输入了任务的实际开始时间等等，你的每一次编辑，都可能会对其他任务、其他单元格、以及整个项目造成影响，尤其是在设置了任务之间的关联关系的情况下，更是如此。任何一次改动，都可能引起连锁反应，可谓牵一发而动全身，而这恰恰是Project 软件的好处，给计划编制者带来了无穷的便利。说了那么多，举个例子吧。假如原来计划中有3个任务，A、B、C，如图1所示。 图1 平静的3个任务假如，我们将任务A的工期从1天改为2天，如图2所示。那么细心的朋友会发现，有些单元格的背景已经变成了浅蓝色，这是什么原因造成的呢？ 图2 将任务A的工期从1天改成2天就是因为，我们把任务A的工期从1天改成了2天，所以它的完成时间没变，但是完成时间往后顺延了1个工作日，完成时间发生了变化，所以你看任务A的【完成时间】单元格就变成了浅蓝色。同时，由于任务B是在任务A完成后马上开始，任务A的完成时间变化了，任务B的开始时间也跟着变了，所以任务B的【开始时间】单元格也变成了浅蓝色，同理它的【完成时间】单元格也变色了。
Project资源冲突解决方案
在我们对功能进行资源设置后，由于任务分配不均匀，导致有些资源会造成时间上的冲突，有冲突的任务可以在第一列上看到冲突标识，具体如下：或者我们也可以通过资源工作表、资源使用情况和资源图表来查看资源工作表资源使用情况资源图表通过多种方式，我们很容易的看出存在冲突的资源，对于有冲突的资源，我们就需要解决冲突，毕竟一个人当多人使，总是会比较容易出问题。
如何在Project 中快速设置任务之间的关联关系
当我们在Project做计划时 通常需要设置任务之间的关联关系，一般情况下我们会在【前置任务】列中进行设置。但是有没有更快的方法呢？如图1所示，假如说，任务1到任务14是依次前后衔接的关系，我们可以选中任务1到任务14，然后在【任务】菜单下点击链条的按钮。 图1 点击【任务】菜单下的链条按钮然后，我们就会看到，此时我们已经成功地将任务1到任务14设置了依次前后衔接的关系，如图2所示。图2 任务之间已设置了关联关系好，我们现在撤销刚才的操作。假如说，在图1的原始案例中，只有任务1、3、5、7、9有这样的关系，那应该怎么操作呢？选中任务1，然后按住CTRL键，再分别点击任务3、5、7、9，然后点击【任务】菜单下的链条按钮，如图3所示。
再谈软件研发管理体系建设
在前面的文章中，我曾和大家分享了软件研发管理体系建设的一些见解，其中涉及对软件研发管理体系的一些概念认知、什么样的软件研发管理体系适合我们的发展以及构建我们的软件研发管理体系应包含哪些内容。结合最近一段时间的思考，今天再次和各位朋友探讨一下软件研发管理体系建设这个话题。今天要谈的这个话题主要包括以下几点： 1、研发体系框架 2、人员组织能力 3、项目管理能力 4、技术研发能力 5、持续交付能力 6、运维服务能力 7、安全可控能力 8、资源建设能力 在正式探讨该话题之前，简要谈谈最近的一些思考和想法，首要一点是社会的发展、业务的变化、技术的进步促进了研发模式的转变，同时也促进了研发内容的转变，例如从以往的单体架构向云化架构演变、从以往的PC端应用向多终端应用演变、从以往的传统应用向智能化应用演变，另一方面项目交付的发展方向也是发生了重大转变，从以前的注重过程标准、流程可控、需求明确和面面俱到向关注交付价值、交付效率、安全保密和过程可视的方向转变。 正是基于对上述这些认知和理解，让我对软件研发管理体系的建设有了一些新的思考，为此和大家一起分享交流。一、研发体系框架 在个人看来，研发体系主要从标准方法体系、技术能力、组织架构、交付模式、服务客户等方面去分解考虑，并在中间通过人员组织能力、项目管理能力、技术研发能力、持续交付能力、运维服务能力、安全可控能力和资源建设能力等贯穿。研发体系框架示意如下图所示：二、人员组织能力 在人员组织能力方面，需要建立组织岗位体系框架，包括岗位标准库、培训规范、岗位胜任能力标准、岗位认证流程、岗位等级认证、岗位发展通道等。在岗位体系建设方面，可以考虑按职能类（如部门总经理、部门副总经理、行政助理等）、项目类（如项目总监、高级项目经理、项目经理、项目工程师等）、专业类（如技术总监、技术经理、开发经理、系统架构师、开发工程师、测试工程师、实施工程师等）的方式进行分类设置。同时，明确相应的岗位发展通道。 关于组织岗位体系框架的建立，通常需要在公司层面来统筹考虑，因此需要和HR部门等诸多部门进行协同落实。 此外还需要建立绩效考核评价方法，针对研发人员的绩效考核评价方法在会对各岗位人员个人技能、综合素质及工作任务进行持续跟踪，并根据人员考核计划开展绩效面谈辅导，帮助全员改进工作方法、提升工作技能和工作质效。 培训作为人员组织能力的有机组成部分，需要强化培训和知识共享，通过建立内部培训体系，内部培训与外部培训相结合，多样化培训形式，将技术认证、培训积分等纳入技术序列晋升考评条件，强调培训的结果。三、项目管理能力 项目管理能力方面，需要在标准化项目管理与敏捷迭代之间融合升华并逐步形成满足未来发展需要的敏捷项目管理能力，促进管理与工程维度相结合，应用最佳实践，从而快速、高质量交付可工作的软件。 除了项目管理体系方面的内容之外，还需要关注设计评审规范、应用开发规范、质量管理、配置管理等方面的内容。 对于涉及评审规范，需要针对需求、概要设计、数据库设计、详细设计、原型设计、界面设计等制定相应的评审规范，同时要对测试计划、测试用例等进行评审，除此之外，还需要有代码评审和发布评审等方面的规范约束。 对于应用开发规范，可以重点关注架构规范、设计规范、UI规范、编码规范、测试规范等。其中，架构规范方面是通过规范架构设计，来管控软件的技术合规性；对设计进行规范，包括如统一文档格式规范、功能设计要素、DFX设计规范、数据库设计规范等；UI规范是为避免使用者对不同系统进行多次学习、操作思维不连贯，从而提升操作效率；代码规范是为了代码能被更好的维护、扩展和更高的质量。包括代码编写规范和代码质量管理规范；测试规范则是规范测试过程，包括测试步骤、测试方法、测试工具、用例规范等。通过对测试进行合规性管控，提高产品质量。四、技术研发能力 技术研发能力主要从应用开发能力、平台研发能力和技术创新能力三个维度考虑。 应用开发能力着重于考虑对各类业务应用的前后端开发支撑能力；平台研发能力着重于考虑对基础平台、公共组件、套件、工具等的研发提炼并让软件开发逐步具备搭积木能力；技术创新能力着重于紧跟前沿技术，特别是云大移物智方面的相关新技术的研发突破，以便于更好地为业务服务。 在技术研发方面，需要持续增强基础开发能力，并在平台化、产品化方面深入研发，拓展云计算、物联网、移动互联网、大数据、人工智能等方面的技术能力。五、持续交付能力 在持续交付能力方面，不同阶段会有不同的做法。个人认为，在构建持续交付体系框架的初期，可以考虑从两个方面出发，一是统一软件开发平台，二是推行CI/CD。 统一软件开发平台，主要目标是把基础服务平台化、软件架构标准化，从而进行快速的开发和迭代，提高整个应用开发域的自主可控能力。 推行CI/CD方面，主要是通过搭建自动化工具平台，构建持续交付流水线，实现端到端无缝集成。这里面可快速运用的实践包括代码构建自动化、静态代码扫描自动化、API接口测试自动化等。有关这方面的一些实践会在后续计划分享的敏捷和DevOps转型实践的有关文章中探讨。六、运维服务能力 在运维服务方面，有两方面的考虑。首先是对于软件开发项目的生产运维，这方面可能会涉及到持续部署等方面的内容，更多会牵涉到DevOps中有关Ops的部分内容。另外一方面是针对常规性的IT运维服务及管理，这方面需要围绕提升IT服务交付质量打造以流程、规范制度、技术人才和工具共同支撑的运维服务管理体系。七、安全可控能力 在安全可控方面，着重于将安全问题摆在凸显问题。这里面既有应用安全，也有过程安全，同时也需要考虑本质安全。应用层安全包括应用安全、内容安全、工控安全等。过程安全包括物理层安全、设备层安全和数据层安全，其中设备层安全包括物理安全、环境安全、设备安全等，系统层安全包括网络安全、软件安全等，数据层安全包括数据安全、身份安全、隐私保护等。八、资源建设能力资源建设能力方面着重于持续积累组织过程资产，包括持续积累在研发过程中所获得的经验和教训，其中包含显性知识（文字档案），隐性知识（员工脑子中的思想、经验）。组织资产积累除了显性知识，更重要的是把隐性知识显性化。 同时还需要持续构建知识库，推行各项制度、标准、规范、流程。以上是本次针对软件研发管理体系建设的进一步思考，欢迎各位朋友广泛提建议，可以做进一步交流、探讨。