推荐阅读
WPS表格 插入与单元格同样大小的形状 动画教程
WPS表格里 单位格的 巨细是 牢固的，你要 调解的话要 本人 别的 配置。 假如在 单位格 拔出图形会 怎样？ 明显不 调解 单位格 巨细，图形是 没法 局部 显现 进去的， 有无 甚么好 法子 能够 拔出与 单位格 巨细 同样的 外形呢？ 谜底是有，这不， 上面 便是 简朴易懂的动画教程。动画演示
如何将销量表用Excel2007制作成图表形式展现
用户如要将一份销量工作表，做成图表该如何去快速完成？在Excel2007中用户可以快速将工作表中的数据转换成图表。操作步骤 打开Excel表格单击菜单栏“插入”→“数据透视表”→“数据透视图”。 在“创建数据透视表当”中选择一块区域作为统计图，接着勾选“现有工作表”按“确定”。 弹出提示后选择“是”即可。 此时弹出“数据透视图筛选窗格”和“数据透视表字段列表”勾选“字段”将两个窗口关闭即可。 最终呈现一张简洁的图表，如果用户觉得很单调可以在“设计”窗口中自行设计。
wps office如何添加工具栏
用wps编辑文字的时候，很多时候都需要使用工具栏。很多朋友一个不小心就把工具栏隐藏了，不知道怎么调出来，小编分享这个方法给大家。 wps office添加工具栏 我们在使用wps编辑文字的时候，很多时候都需要使用工具栏。很多朋友一个不小心就把工具栏隐藏了，不知道怎么调出来，其实很容易，下面小编将这个方法分享给大家 首先我们打开wps你要操作的文档，然后点击右上角的隐藏的按键 然后我们工具栏又出来了
WPS中VBA为灰色不可用怎么解决
WPS版本众多，可能有些版本中的VBA不可用。WPS2013就没有VBA，在开发工具中查看，都是灰色的，需要重新下载安装。以下是小编为您带来的关于WPS中VBA为灰色不可用的解决方案，希望对您有所帮助。 WPS中VBA为灰色不可用的解决方案 ①小编打开WPS2013，切换到开发工具选项卡，看到VBA都是灰色，不可用。 ②我下了一个插件，安装之后，却提示Vbe6ext.olb无法加载，解决方法如下：按下Win+R输入regedit。 ③依次展开到注册表：HKEY_CLASSES_ROOT\Typelib\{0002E157-0000-0000-C000-000000000046}，右击，设置权限。 ④将user用户允许完全控制，这样就解决了无法加载的问题。
最新发布
和大家一起走进原型设计的世界—原型设计方法
这一篇文章简单谈谈有关原型设计的一些方法。1、设计思维与习惯 首先，我觉得做原型设计时非常重要的一点就是要有好的设计思维和习惯。做产品就是做工程，工程就要严谨有序，在大工程量级时，模块化前期不快，但中后期的优势明显，通过不断积累可以形成原型复用库。这些设计思维和习惯是我在进行原型设计过程工作中的一些小体会，归结起来主要有以下几点： （1）全局意识：就是要在做原型设计前要有整体的考虑，考虑做原型的目标在哪里？受众是谁？用户特点是怎样的？用户体验要求又当如何？原型主题往哪里走？原型风格趋于哪种风格？诸如此类的问题都需要在一开始就给予重点考虑和关注。 （2）广阔视野：广阔的视野意味着我们在平时要多看好的作品，多去感受众多优秀的产品，多了解与心理学、美学、工程学、管理学等方面的知识，同时要注意多收集整理一些优秀的资源网站等，以便于让自己在进行原型设计时能够有更多的想法。 （3）模仿组合：很多时候，我们学习新东西，都是从模仿开始的，模仿并不是简单地照抄照搬，而是认真领会被模仿对象，然后结合自身实际进行组合式转化。 （4）严谨耐心：做原型设计也需要有严谨的工作态度和耐心，只有严谨才能在一些关键点的设计上做到极致。 （5）关注细节：原型设计的好坏，其实很多时候都是藏在细节之中，因此不放过每一个细节将会决定我们设计出来的原型是否合格乃至优秀。 （6）复用转化：每一次原型的设计都应该更进一步，因此要对之前设计的成果形成原型库，并利于后续的复用和转化。2、原型设计的基本方法 原型设计的基本方法有哪些呢？结合网上的一些资料，我收集整理了以下几点： 产品定位，定义形式及交互模式：什么样的用户想要什么？我们要做什么样的产品？我们要做什么样的？ 定义功能和数据：充分考虑具体的功能及对应的数据元素，每个功能及元素的定义要针对需求，考虑周全 确定层级和页面：确定一个页面应该放多少东西，一个任务要分多少步来完成页面元素居多时要保证用户合理的视觉线 绘制原型草图：从整体且高层次的框架开始构建，不要被细节分散了注意力，细节留到最后去仔细推敲 构建用户行为路线：考虑用户最频繁也是日常的一个行为路径，可以通过给用户设想不同的情景下完成什么任务来构建 通过场景验证检查设计：找到原型或逻辑的漏洞，调整并优化；路径分岔点、必要场景、边缘情景场景、特殊场景 3、高保真原型的设计 高保真原型的设计，它的适用场景：流程清晰的前提下，想要接近或者定义最终效果。 4、原型设计小TIPS 在原型设计过程中，其实还有很多小tips可以提高原型设计的水准，例如用动态面板实现交互效果、养成良好的命名习惯等等。
project 浅谈技术管理者的角色认知与自我管理
谈到技术管理，首要的一点就是管理者的角色认知问题，因此本篇文章的主要内容就是如何增强管理者的角色认知，持续提升自我管理能力。作为管理者，首要任务就是要认清自我并管理好自己，要树立对管理者角色的正确认知，并在实际管理工作中持续提升自我管理能力，系统思考，不断修炼，持续实践，逐步提升个人领导力。要学会管理并运用于实际工作中，首先要了解管理的起源，在我们国家，很多的管理思想都是藏于各类文学、哲学、史书之中，像《孙子兵法》、《论语》、《孟子》、《大学》、《中庸》、《资治通鉴》、《王阳明传习录》等等，里面有非常多的管理智慧。而现代将管理的起源，其实很多时候将的是管理学的起源和发展，这个主要源自西方的古典管理理论、行为科学理论、现代管理理论等。因此，关于管理的定义，我们可以从一些管理大师的言论、作品、思想理论中窥探一二：弗雷德里克·温斯洛·泰勒认为：“管理就是确切地知道你要别人干什么，并使他用最好的方法去干。” 赫伯特·西蒙认为：“管理就是制定决策。” 亨利·法约尔认为：“管理是由计划、组织、指挥、协调及控制等职能为要素组成的活动过程。” 彼得·德鲁克认为：“管理是一种工作，它有自己的技巧、工具和方法；管理是一种器官，是赋予组织以生命的、能动的、动态的器官；管理是一门科学，一种系统化的并到处适用的知识；同时管理也是一种文化。”那么，针对技术管理的定义，常见的说法是：技术管理用于计划、开发和实现技术能力，完成组织战略和运营目标。技术管理通常是指在技术行业当中所作的管理工作，管理者一般具有较高的技术水平，同时带领着自己所管理的团队完成某项技术任务。管理者用自己所掌握的技术知识和能力来提高整个团队的效率，继而完成技术任务。很多的管理者都是从小白入手，经过千锤百炼，逐步成长为管理精英。那么，在这个过程中，就需要做好管理者的角色转换，认清管理者的角色定位误区，明确管理者的正确的角色定位。大部分技术管理者都是从工程师跃升过来的，因此这里面会面临几个方面的角色转换问题：一是从专才向通才转变，二是从对事向对人+事转变，三是从管好自己向带好团队转变，四是从被安排向主动规划转变，五是从过程导向向目标/结果导向转变，六是从追求个人业绩向追求团队业绩转变。在向管理者角色转换的过程中，很容易会步入一些误区，例如有官僚主义作风倾向，从工程师升级到技术管理者，通常会有一种这个权力的放大，容易出现急躁冒进、官僚作风凸显等问题，由此会导致工作开展等各方面受影响。其次，也容易一味盲从地听从下属的意见，容易把自己定位为民意代表。再次是依旧把自己当做一名普通的员工，和之前的工程师角色没有任何差别。除此之外就是容易充当传话筒。除了上述这些角色定位误区之外，作为技术管理者，也容易出现找借口、推卸责任，危机意识淡薄、缺乏老板心态等方面的问题。这些都是我们在向技术管理者角色转换过程中要特别注意的。
浅谈如何做好软件研发团队的盘点
作为一名研发部门的负责人，做好软件研发团队的盘点工作，有利于分析团队现状，清理工作思路，明确未来发展。在此，本人将如何做好软件研发团队的盘点、如何编写团队盘点报告分享一点心得，不妥之处，欢迎各位朋友批评指正。做团队盘点的目的就是要给团队把脉，更加全面深入掌握团队的整体情况、人员情况等，以便对团队有全面认知，并做好未来规划。盘点的范围通常包括现阶段人员总体情况、各部门人员情况、各岗位人员分布情况、项目交付人员及项目匹配情况、运维服务人员及项目匹配情况、技术研发人员情况等。首先，对团队人员总体情况的盘点包括从研发部门总人数、各类型人数、各类型人员分布情况、各毕业院校人数分布、人员入离职情况分布等进行统计。其中，各类型人员分布情况包括但不限于按社会工龄分布统计、按入职工龄分布统计、按年龄分布统计、按学历分布统计等等。对毕业院校人数分布的统计除了主要院校的人数分布之外，还可以对一些重点院校进行占比等方面的统计，有利于明确各类人才的分布情况。对人员入离职的情况统计，通常按岗位（如项目经理、需求分析师、开发工程师、测试工程师、运维工程师等）进行分类统计。 其次，可以从各二级部门角度、岗位类别角度、业务类别角度等方面的分布情况进行统计分析。岗位类别包括岗位大类和岗位小类，岗位大类可以类似按项目管理实施、软件架构开发、软件设计开发、UED设计开发、软件质量保证、软件运维服务、部门公共等分类，岗位小类可以类似按项目管理、需求分析、架构开发、交互设计、UI设计、前端开发、后端开发、软件测试、质量管理、配置管理、运维服务、部门管理、部门公共等方式进行分类。而业务类别分布情况统计分析，则是结合公司的业务方向来进行的，对于无法归入业务方向的，可以按公共资源等进行分类处理。对团队各类人员的分布情况主要是结合公司的模式来考虑的，本人所在的公司是一个典型的项目型公司，因此在分类上按项目交付、运维服务、技术研发和综合其他来进行分项盘点。 在项目交付方面，对主要客户单位主要项目的各类参与人员进行盘点，识别出可能存在的瓶颈。在运维服务方面，对主要客户单位主要项目的运维人员进行盘点，识别出计划配备人数和实际人数的差距。在技术研发方面，主要是指在技术预研、架构研发等方面的人员进行盘点。在综合其他方面，主要是对公共资源（如交互设计、UI设计等）进行综合盘点分析。基于前面所述的团队盘点并结合公司未来业务发展方向，基于业务层面、技术层面及研发效能层面等方面综合考虑，规划下一阶段的团队情况。这里面，同样也会从项目交付、运维服务、技术研发、公共资源等方面进行考虑。只不过，项目交付及运维服务考虑的是下一年度的项目/产品/服务业务情况，由此进行团队配备的预估及能力匹配的分析。技术研发则是确定下一年度的技术研发方向。基于对当前研发团队的盘点及对下一阶段的团队规划，梳理出下一阶段（通常是未来3-6个月，长一点也可以是1年）的人员招聘需求。最后，通过上述思路对团队的盘点，可以整理成一份团队盘点报告，本人当前使用的团队盘点报告大纲如下图所示，仅供大家参考学习。
管理任务和工具概述
一是关于管理任务，书中提到五项管理任务，且定义为必须完成的最低标准，而不是可以选择的最低标准。这五项管理任务总结如下图所示： 1、满足目标所需。没有目标就没有管理，这是作为管理者首要面对的问题，倘若目标不清晰，管理的边界也是模糊的。 2、组织。我想这个是大多数管理者在自己职权范围内的重要工作，作为管理者必须对组织工作进行恰当的安排，并极力促进形成良好的运行态势，同时要对可能发生的结果勇于承担责任。 3、决策。决策过程中，所有任务、资源都被整合到一起，以求尽可能切中问题的要害，抓出事件的核心。 4、控制。我们能做的只是要选择是这样控制还是那样控制，而不是不要控制。控制的基础是测量和评估。 5、对人的培养和发展。对人的培养和发展算得上是重中之重。二是关于管理工具，书中提到管理者必须掌握并且经常用到的工具： 1、会议。要保证会议是有价值、有效率、有成果，必须抓住两个关键点：一是会前做好充足的准备，二是会后及时总结修改。 2、报告。要想获得有效性，就必须把报告当成广义上的管理工具来看待。 3、职位说明和委派任务。职位的结构必须确定，逻辑必须理顺。 4、个人工作方法。要形成符合个人的系统化、行之有效的工作方法，并转化为生产力和效能。 5、预算及预算编制。只要是管理者，就至少要掌握编制预算的初级知识。在组织内部，预算属于最重要的整合和调控工具。 6、绩效评估。管理者不仅要能带领员工创造绩效，对绩效负责，还要对其进行评估。在这方面，个人的做法是做定期绩效辅导和年度绩效评估。 7、系统性垃圾清除。别再做错误的事情！
和大家一起学 Project—Project高级应用
我们再来看Project的一些高级应用。1.1.设置任务依赖性的几种方法首先是设置任务依赖性的几种方法，这里介绍三种方法。方法一：选中两个需要建立依赖型的任务。选中用ctrl鼠标左键的方式即可。但是要注意选择的顺序，先选择的那一个被认为是前置，后选择的那个默认依赖于先选择那一个任务。点击如图所示的这个图标。一个“链接”模样的图标。刚才选择的两个任务就被链接在一起了。依赖性是默认的“结束-开始”型。你会看到，在前置这一栏出现了如图示的数字，这个数字就是最左侧的行号数字。方法二：这次不需要选中两个任务了。只需要选中所谓的后继，我们通过其他方式给它确定其前继。比如，我选中了上图中的任务3，并想确定任务3是依赖与任务2的。执行任务→属性→信息，弹出如下任务信息对话框。选择前置任务标签，点击下面的任务名称右侧的按钮，会弹出所有可供选择的前继，选择我们需要的任务2。方法三：前两种操作后，内部进行了什么我们不清楚，我们只是看到在前置任务一列中多出来一些数字，而这些数字刚才已经解释了，就是最左侧一列的行号。那么能不能直接在前置任务这一列输入数字来完成依赖性关系的设置呢？答案是肯定的！只需要单击（相当于选中）一下任务后面的前置任务字段，就可以输入了。输入的对不对，可以在右侧的甘特图中进行预览。1.2.改变任务的依赖性那么，我们如何改变任务的依赖性呢？通常来讲，默认的“结束-开始”模式能够适应大部分任务，但是仍然会有一些特殊的任务，他们之间的依赖关系不是简单的开始结束，而是上表中的其他形式，怎么处理？一般的方法是，先按照“开始-结束”默认设置，设好了之后，在右侧的甘特图中双击关系线，弹出的对话框中就可以选择其他的依赖关系了。
聊聊软件项目管理及成本核算
谈到项目管理，想必大家也非常清楚其重要性。由于项目具有临时性、独特性、渐进明细等特点，因此每一个项目的管理都各有差异，特别是对于软件项目来说，这种差异更是受人的主观能动性影响差异和变化更多。几年下来，我们做了大大小小、林林总总、各种各样的软件项目，有一些在当时的情境下似乎做得还算可以的软件项目，也有大部分做得普普通通、不好不坏的软件项目，还有一些是做得比较失败的软件项目。总的感觉就是，软件项目管理是一门学问，不是某一个项目经理单打独斗的学问，而更多是团队协作的学问。固然，一个优秀的项目经理能在项目中起到至关重要的作用，但软件项目开发，终究是一群人的战斗，因此共同保持对项目的敏锐度，才有利于项目的顺利推进，也才更有利于对项目的可持续性。早些年，我们常常会出现销售、售前、售后（交付）容易脱节的问题，甚至是相互挖坑的问题。举个例子，销售人员在完成合同签订将项目转到交付环节后基本上就不怎么关心后续项目交付的情况而是等着项目验收及收款，售前缺少与售后（交付）团队的沟通衔接导致需求理解出现偏差甚至是重复做用户调研等问题，项目交付团队缺少与销售、售前沟通而导致多走了不少弯路等等。这类问题其实很常见，但凡在一些做得不好的项目中基本都能找到这些影子。做甩手掌柜这种行为在项目执行中会带来很大的问题，而且往往很难取得客户长期的信任与持续合作的机会。因此，销售、售前、售后（交付）协同融合是做好项目的根本保障。另外一点就是，每一个软件项目都有其特定的使用场景，都有其存在的特定意义。我们要想将项目做成功、做漂亮，就需要思考个中奥秘，就需要抓住关键干系人，帮助客户做出一些亮点、特色出来。这些亮点、特色不在乎多少，而在于要与客户取得共鸣，解决客户的痛点、戳到客户的痒点、触到客户的爽点。要做到这些，往往不是一两个人的事情，而是整个项目团队甚至包括销售、售前及相关人员在内的共同责任。比如当初本人在全省各地市做系列项目的时候，也是抓重点地市单位、抓创新意愿强烈的地市单位，有的放矢、凝心聚力地做好一些关键节点并做出一些亮点。当然，那些具有可持续性的软件项目或者能产生规模效应的软件项目更值得我们这样做，我们更应该也必须全力以赴。从项目管理的角度来讲，每一个项目都会经历启动、规划、执行、监控、收尾等过程组。个人认为，项目管理过程除了交付团队必须要重点关注和着重做好之外，对于销售人员也是有必要了解的，并且在整个项目的执行过程中保持良好的沟通渠道，共同应对软件项目实施过程中的各类问题及可能出现的风险。此外，相信大家都很关注软件项目的成本问题，到底一个软件项目是不是挣钱、能不能挣钱，是挣现在的钱还是挣将来的钱，是挣项目自身的钱还是挣关联项目的钱等等，都会关系到我们项目型软件开发的走向。在我们过往的做法中，我们通常采用经验值估算法、功能点估算法等方法对软件项目的成本做基本测算，这种方法毕竟因人而异，也会有一定偏差，往往很难让我们真正搞清楚软件项目的成本究竟有多少。同时，我们也会通过判断人员集中投入度等来大致判断软件项目成本，虽然有一定效果，但依然很难指导我们行动。从我个人角度来说，我更喜欢用数据说话，从数据中分析并找到一些我们可能想要的答案。为此，从去年开始，我在部门内部开始尝试探索基于项目资源实际投入工作量、人力费用明细数据、财务报销明细数据的研发成本费用核算模式，尽可能地核算到每一个项目中，从而帮助我们更好地分析判断项目成本费用分布及变化情况，为软件项目的成本控制提供一些基础的数据依据。当然，成本核算并不能做到100%的精确，但对我们管理软件项目成本并采取一些行动已经有很大的参考价值。
project 敏捷转型行动笔记：Scrum框架实践
前面我们提到看板搭建、价值流分析，本文谈谈敏捷转型之Scrum框架实践。 从我们的敏捷转型之旅来看，我们的试点团队是从看板方法及每日站会搞了一阵子之后，才开始实践Scrum框架的。究其原因，主要是两个方面：一是我们的团队之前的开发模式是典型的瀑布型模式，对敏捷的理解和认识非常粗浅；二是我们对用户故事、Scrum框架等的实践方法需要时间消化，需要预留一定的缓冲期。所以我们选择了从搭建看板和每日站会开始。 谈到Scrum，首先还是老调重弹地说说有关概念、方法论等方面的东西。 从概念上来说，Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。它把开发组织成被称为Sprint的工作周期。这些迭代每个都不超过4周（最常见的是两周），并且无间歇地相继进行。Sprint是受时间箱限制的，无论工作完成与否它们都会在特定日期结束，并且从不延长。 实施Scrum框架的好处也是显而易见的：（1）降低变更对系统造成的风险；（2）提高ROI（投入产出比）；（3）帮助我们持续改进；（4）持续快速的发布可用的软件产品；（5）所有人对真实可用的软件产品都有明确的认识，并在迭代过程中不停的改进。 目前，Scrum是全球使用最广的敏捷方法和实践。谈到Scrum，就一定要知道“3355”，即3个角色、3个工件、5个事件、5个价值观。 3个角色包括产品负责人（PO）、ScrumMaster、开发团队：3个工件包括：产品待办列表、迭代待办列表、产品增量。 Product Backlog（产品待办事项列表）即产品视角的需求清单，产品Backlog是需求动态管理的载体。产品backlog由所有的功能特性，包括业务功能，非业务功能（技术、架构和工程实践相关），提升点以及缺陷的修复等组成，这些内容也是将来产品版本发布的主要内容。 做产品待办事项列表时，一是要清楚表述列表中每个需求任务对用户带来的价值，做为优先级排序的重要参考；二是要动态管理需求，产品负责人要持续地管理和刷新需求清单，特别是在每一轮迭代开始前，都要重新筛选出高优先级需求进入本轮迭代；三是对需求分析过程要基于迭代分析的思想，在总体需求框架下，只对近期需要做的需求进行细化分析。Sprint Backlog（ 迭代待办事项列表）即此次冲刺周期内规划要完成的内容。 Product Backlog在得到了PO和团队的认可后会交付给团队进行开发，就变成了sprint backlog，转换成sprint backlog的过程一般还包括了任务分解和工期估算的工作内容。Increment（可交付产品增量）是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。 5个事件包括：Sprint、Sprint计划会议、每日站会、Sprint评审会议、Sprint回顾会议。 我们在实际实践过程中，主要针对每一个完整的Sprint的几种仪式来实践，而且根据项目团队的实践经验，主要按2周为一个迭代周期，一般在周一的当天召开由PO、SM和Team共同参与的Srpint计划会议，讨论产品待办事项列表，评估故事点和预估时间，细化开发计划，并进行任务分解，输出Sprint Backlog。要求全体团队成员要充分参与和讨论、确定相应的内部任务，做出相应的承诺。 之后，从第二天开始举行每日站会，每日站会一般在上班后的5-10分钟后举行，持续时长一般在15分钟左右，不同项目组有所不同。 在迭代完成后，会召开Sprint评审会议，除了PO、SM和Team会参加之外，如果条件许可，也会邀请客户一起对交付成果进行评审验收，进一步增加了沟通和互信。例如，PP Project，每一次迭代上线前邀请客户共同评审本轮迭代上线功能，减少了上线后的问题和业务变更；PPAPP 2.1 Project，邀请客户共同对迭代开发成果进行评审，改变了客户一开始不断扩大需求开发范围而不注重产品用户体验等核心要素的观念，通过与客户协作共同打磨，虽然首个版本交付功能并不算多，但用户体验等方面都做了很多改进，整体效果上比PPAPP 2.0 Project有了很大的进步。 在下个迭代开始前，会召开Sprint回顾会议，全体小组成员分别发言，分享好的经验和发现改进点，从而促进团队不断进步。而在迭代回顾会上，全体成员共同回顾迭代过程，总结做得好的、做得不好的以及需要改进的，并明确了下一个迭代的改进项，有利于构建团队的持续改进环，并在每一次迭代中通过考虑容量分配问题，对用户故事、技术债务及常规维护做了动态分配调整，整体上加强了质量管控。5个价值观包括：承诺、专注、开放、尊重、勇气。在做Scrum实践时，需要充分结合自身团队的实际情况，适当预留20%-30%的能力，以应对紧急事件处理、技术难题研究等等。因此，要想让Scrum真正发挥作用，团队就必须要理解集体承诺和自组织。而这个在实际实践中，就需要团队的共同努力：一是要让团队始终保持在固定时间内完成交付的节奏，二是要让团队有一个共同的清晰的目标从而牵引团队前进；三是要持续不断地实践Scrum框架，总结每一个迭代，并在下一轮迭代中持续改进。
和大家一起学 Project—项目管理与Project
这一次的分享主要是结合本人在实际使用Project2013过程中的一些方法技巧，其中有一些材料则来源于互联网，期待通过我的梳理成篇后能够给你带来Project2013的入门指导。在正式讲Project2013有关知识与操作、技巧之前，我们有必要先来简要了解一下项目管理的相关知识、Project的相关基础知识及项目管理与Project的一些关系。1.1.项目和项目管理的定义首先，我们要先来认识几个概念。什么是项目？什么是项目管理？项目管理又是做什么的？那么，什么是项目呢？项目，英文单词叫Project，是为了完成一个具体的目的而设计的一系列行动步骤。项目管理，英文单词叫ProjectManagement，是指为了完成一个特定的目标，应用一定的规范或规章制度对项目的资源进行全面的规划、组织，协调，控制并使之系统化的过程。1.2.项目三角形在项目管理领域中，有三个要素非常重要，分别是预算、时间、范围。而我们称之为项目三角形，因为这里对三角形的任何一边进行调整，都将影响其他两边。那么，在这个三角形里边，为了满足项目预算要求，结果可能是延长了日程和缩小范围；而为了按计划的完成日期完成，最终结果则可能是增加了成本和缩小了范围；同时，如果扩大范围，则我们的项目可能以资源（如工作人员）的形式花费更多的时间和资金。1.3.项目管理的五个阶段项目管理总体上包括五个阶段，分别是启动阶段、计划阶段、执行阶段、监控阶段和收尾阶段，这是项目管理的五个过程组。这五个过程组贯穿于项目的整个生命周期，对于项目的启动过程，特别要注意组织环境及项目干系人的分析；而在后面的过程中，项目经理要抓好项目的控制，控制的理想结果就是在要求的时间、成本及质量限度内完成双方都满意的项目范围。启动阶段是一个新的项目识别与开始的过程，这主要是确定一个项目可以开始并着手实施。启动涉及项目范围的知识领域，其输出结果有项目章程、任命项目经理、确定约束条件与假设条件等。项目的计划过程是项目实施过程中非常重要的一个过程，对项目任务进行计划并确保实现项目目标。通过对项目的范围、任务分解、资源分析等制定一个科学的计划，能使项目团队的工作有序的开展。
和大家一起学 Project—Project基础应用
为了更清晰容易地熟悉掌握Project的基础应用，我们在基础篇中一起来学习掌握在Project中如何做进度计划、资源计划、成本计划以及跟踪项目的执行情况并生成所需的项目报表。1.1.进度计划这里，首先要问各位朋友一个问题，你平时如何新建一个project项目计划的？很多用户初次使用project创建项目计划时，启动project以后直接在甘特图视图的区域内开始输入任务信息。其实这种做法是不符合使用规范的，为了提高计划编写的科学性、准确性，建议按下述规范顺序使用。首先是创建项目文件。这可以利用现有模板，也可以利用现有文件，还可以创建空白的项目，并通过保存新项目以实现新项目的创建。其次，要设置项目的基本信息，包括：1、设置项目日程排定方式（1）第一种是项目开始日期，按照从前往后的顺序推算出项目的完成日期（顺排）（2）第二种是项目完成日期，按照从后往前的顺序推算出项目的开始日期（倒排）2、设置项目开始/完成日期3、设置“任务模式”为“自动模式”或“手动模式”
和大家一起走进原型设计的世界—认识产品原型
这一回跟大家一起分享一些我在原型设计过程中的一些心得体会。1、什么是原型 根据不少产品经理网站和网络上的一些定义，原型，即产品草图。从产品流程来看，将想法形成草图原型，原型再由设计师形成效果图，程序猿们根据需求和效果图开发，出来的软件样子就是和效果图差不多。原型在过程中就是产品最终形态的骨架。 百度百科里面提到：产品原型可以概括的说是整个产品面市之前的一个框架设计。以网站注册作为例子,整个前期的交互设计流程图之后,就是原形开发的设计阶段,简单的来说是将页面的模块、元素、人机交互的形式，利用线框描述的方法，将产品脱离皮肤状态下更加具体跟生动的进行表达。 同时百度百科里面也提到：原型设计是交互设计师与PD、PM、网站开发工程师沟通的最好工具。而该块的设计在原则上必须是交互设计师的产物，交互设计以用户为中心的理念会贯穿整个产品。利用交互设计师专业的眼光与经验直接导致该产品的可用性。换一个角度理解，原型是产品经理人员将文字化的需求转换成图形稿，是设计方案的表达，是产品经理的重要产出物之一，是项目团队参考，评估的重要依据。它是产品功能与内容的示意图，是最终产品的雏形。2、原型的分类有哪些 那么，原型的分类有哪些呢？归结起来，主要有三类，分别是低保真原型、中保真原型和高保真原型。低保真原型是最轻松和省时间的原型，粗犷的风格让我们只重视结构和流程，原型不在乎太多设计细节。中保真原型这类原型最常见，低保真不容易描述产品最终样子，高保真容易干扰设计师，中保真汇集了各类优点，也是比较常用的。高保真原型对比中低保真，高保真可以称之为效果图了，如果加深细节可以直接对着开发咯，换句话说，高保真更强调细节。3、原型设计的重要性 随着互联网的迅猛发展，越来越重视产品的设计和用户体验的设计，因此原型设计也愈来愈重要。一方面能够让开发更轻松，同时能够通过更简单的协作意味着更容易反馈，一方面能够节省时间和金钱，最终能够逐步达到双赢的局面。 原型主要是用来演示UI是如何运作的，呈现流程的流向，不论它是否流畅是否足够合乎逻辑。不断地对原型进行调试意味着，你可以在迭代中不断优化用户体验和产品细节，直到最终完成设计。 4、好的原型是怎样的？ 那么，好的原型又是怎样的呢？主要包括以下几点： 5、原型设计的注意点有哪些？ 原型做出来是给大家项目评审用的，方便用户联想最终的产品。同时也让让每个使用者都可以明确自己要做的事情，不至于模棱两可。所以在做设计时，产品经理要尽可能的去规范原型。 在进行原型设计的过程中，至少需要注意以下几点： （1）结合业务特点及应用场景，进行整体构思，确定整体框架，合理进行布局，考虑视觉好的效果，提前和UI沟通。 （2）不要为了偷懒，使用页面截图；不要遗漏特殊状态的描述。 （3）要使用尽量真实的、符合逻辑的数据，避免给团队及用户造成不必要的困惑。此外，简单介绍一下有关原型的UI基础和界面规范： 最后再分享几个常见的资源网站：