推荐阅读
聊聊以项目型为主的定制化软件开发
各位，在你们的眼中，如何理解软件开发？我想这个问题定然会得到许多不同的答案，对于软件开发的定义，百度百科中提到：软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。个人认为，**软件开发过程就是一群人的思想相互碰撞的动态过程，既然是一群人，那么就人与人之间各有不同、各有所需；既然是思想相互碰撞，那么就可能会难以捉摸；既然是动态的，那么就一定会有变化。**这也就不难理解为什么说软件开发是一项复杂的系统性的技术工程。本人自2009年开始参与到软件开发的大军中来，掐指算来，已是十年有余。在软件开发领域十余年的摸爬滚打，积累了些许经验教训，对软件开发的理解也在逐步加深。鄙人不才，愿借此机会，与各位聊聊软件开发的那些事儿。 今天这里要聊的其中一个话题与软件开发类型有关。从软件开发类型来看，一般有项目开发、产品开发、技术研发等几类。在我们公司，从这几年的实践来看，我们的软件开发几乎都是项目型的软件开发，而且几乎都是以乙方身份承接的项目开发。项目型软件开发的最大特点就是定制化开发。谈到定制化开发，想必大家都非常清楚，不同客户的需求各不相同，即使是同一类型的客户同一类型的软件需求也会有差异，开发的可控性和难度必然加大。这里似乎说明了一个问题，定制化软件开发不好做。事实上，定制化软件开发确实存在多方难点，也确实很难通过完成所有客户提出的定制化需求就能做得很成功，这里还涉及到很多商务、技术、管理等方面的综合因素。但是，这并不是意味着定制化软件开发就没有前景、就没有空间。要想在项目型软件开发方面有大的突破，个人认为至少要考虑两个因素：一是可持续性，二是规模效应。 软件开发的可持续性意味着同一类型的软件项目我们可以持续做，继而带来业务的可持续、技术的可持续、团队的可持续。这有点像我们常常说的做完一期做二期，做完二期做三期，做完三期来个技术、业务大升级，再接着做。这种模式下，软件利润也许会有更大的空间。诚然，可持续性也有大有小，小的可持续性更多就是一个单点效应，特别是在项目规模仅在百万级别甚至更小一些的时候，虽然持续做几期规模或许也能有大几百万甚至上千万，但这并不是一件容易的事情，或者应该说对我们而言还是挺困难的一件事，至少这几年我们所做的各类型软件项目也鲜有非常成功的案例。大的可持续性有两层意思，一是大项目的可持续性，比如从一个千万级别的项目开始，历经几年时间下来，一般会有持续的需求需要开发，升级改造必不可少，这个从某种意义上来说就可以将其归结为一个典型的大项目的可持续；二是项目的规模化效应，通常由某一个软件项目开始横向拓展，比如从一个客户单位拓展到另一个客户单位甚至更多的客户单位。软件开发的规模效应意味着在几年内能够有效地促进业务发展，有利于形成一条业务线。这里也有两层意思，一是规模大，只有大项目才有可能形成规模效应，才有可能衍生出其他相关软件项目，继而带动技术服务、运维服务等其他相关项目；二是范围广，一个好的软件项目会借助政策、市场、客户、业务等方面的力量，能够迅速将受众面铺开，陆续在更广阔区域、更多客户单位落地，从而形成规模化效应。上述谈到的都是项目型的软件开发，即使有规模效应，也依然是需要定制开发的，不过从可持续性角度来看，定制开发也有其相应的好处，有需求就需要定制开发，有定制开发就为可持续性开发创造一些必要条件。除了项目型软件开发，还有就是产品型的软件开发，或者直接称之为产品开发。产品型软件开发的最大特点就是可复制性及可运营性。可复制性更多针对的是销售型产品，可运营性更多针对的是平台型产品。在目前我们公司所在的行业特点及我们多年来承接项目的情况来看，要做产品开发不是一件易事，需要市场、人才、时机等各方面的综合作用并顺势而为。
PPT转换DOC文档或DOC文档转换PDF技巧
常常看到有人在网上问到如何从PPT转换到Word文档，如何从Word文档转换到PDF格式，用什么工具转换。其实，一个免费国产办公软件就可搞定一切。从PPT到DOC的转换如果要在Word文档中引用PPT或PPTX演示文件中的图片或文字，是不是需要一张一张图“复制→粘贴”，一段一段文字“复制→粘贴”？那太out了，效率太低！其实，我们可以借助于WPS Office 2012 SP1实现直接转换。在WPS Office 2012 SP1中，我们只要用WPS演示打开PPT演示文档，再选择“WPS演示→另存为→转为WPS文字文档”命令，再在打开的窗口中作相应选择（图1），再选择保存文件夹和文件名。最后直接打开转换后的DOC文件，可以发现文字和图片都是可以选择和复制的，非常方便。图1从DOC到PDF的转换另外，出于格式的统一要求，很多办公场合需要将DOC文档输出为PDF格式。最简单且免费的方法是使用WPS Office。只要打开文档，选择“WPS文字→另存为→输出为PDF格式”，即可将其导出为标准的PDF文件。而且与其他Office不同，WPS在PDF输出时，能够完整保留原文档各种特殊内容，并提供完善的PDF文件权限设置功能，而且自动形成目录，还带有索引功能，功能相当强大（图2）。图2
PPT2003中抛物线的制作方法实例教程
相对以前的版本，PPT2003以上版本的动画制作功能有了很大的增强，很容易实现PPT课件的制作要求。本文通过介绍一个物理PPT课件的动画制作方法，帮助大家了解和学习PPT 2003的动画制作功能。在高中物理的“平抛运动”教学中，需要演示从水平飞行的飞机中投出炸弹的轨迹，以及多颗炸弹和飞机的位置关系。下面我们一起来制作这个PPT课件。将对象插入幻灯片 为了保证课件更加形象直观，我们需要把已经制作好的图片插入幻灯片。 如果放入幻灯片的图片大小不合适，可以将它选中，然后拖动图片四周的尺寸控点，就可以改变图片的大小了。 同理，如果要调整插入幻灯片图片的位置，只要将它选中，就可以用鼠标拖动的办法移动图片。 定义对象的动作路径 根据PPT课件制作的要求，图中的飞机作水平匀速直线运动。定义这个动作路径的方法是：选中已经插入幻灯片的飞机，打开PPT2003“自定义动画”任务窗格中的“添加效果”菜单，单击“动作路径”子菜单下的“向右”命令，以绿色三角形为起始点，红色三角形为终点画出一条水平虚线。其中绿色三角形是对象（飞机）动画的起始位置，红色三角形是对象（飞机）动画的终止位置，水平虚线则是对象的运动轨迹。如果你觉得默认的“动作路径”长度不合适，可以将表示动作路径的三角形和水平虚线选中，然后拖动红色三角形上的控点改变其长度。 接下来就要定义炸弹的运动路径了，操作方法仍然是选中插入幻灯片的炸弹，打开PPT2003“自定义动画”任务窗格中的“添加效果/动作路径/绘制自定义路径”子菜单，单击其中的“曲线”命令。当十字光标出现以后，就可以从炸弹所处的位置开始绘制曲线。 需要注意的是：绘制过程中单击鼠标一次即可留下一个“顶点”，线段可以以该点为中心任意地弯曲，即可绘制出比较平滑的曲线。最后将曲线绘制到飞机动画终止位置的下方，双击鼠标就可以结束曲线的绘制了。如果你感觉绘制出来的曲线不够平滑，可以用鼠标右键单击曲线。选择快捷菜单中的“编辑顶点”命令，此后曲线上就会出现许多小黑点（它是绘制曲线时单击鼠标的位置），你就可以使用鼠标拖动某个顶点，从而让曲线变得更加平滑。最后，按上面介绍的方法在飞机终点位置下方的位置分别放置两颗炸弹,图片所示，以表现飞机投弹后炸弹在其下方排成一条直线的规律。
在Excel2007/2010中绘制一次函数图像
本文介绍在Excel 2007/2010中用散点图和趋势线绘制一次函数y=kx+b的图像的方法。以Excel 2010为例，在同一图表中同时绘制y=-x+2、y=4x+3和y=2x三个一次函数图像。对每个一次函数，只需两个数据点即可。在工作表中输入这三个一次函数的两个数据点，在A列输入x值，在B列输入对应的y值，如图。 1.添加y=-x+2函数的数据：选择A2:B3区域，在功能区中选择“插入→散点图→仅带数据标记的散点图”，在“图表工具-设计”选项卡的“数据”组中单击“切换行/列”。 2.添加其他一次函数数据：在功能区的“数据”组中单击“选择数据”，弹出“选择数据源”对话框。在左侧的区域中单击“添加”按钮，弹出“编辑数据系列”对话框，将“X 轴系列值”设置为y=4x+4函数的x值所在区域A6:A7，在“Y 轴系列值”设置y值所在区域B6:B7，单击确定。 再次单击“添加”按钮，添加y=2x函数的数据。 3.添加趋势线：依次右击每个系列中的数据点，在弹出的快捷菜单中选择“添加趋势线”，弹出“设置趋势线格式”对话框，在“趋势预测”下对“前推”和“倒推”设置一个适当的周期数，本例都为“5”，并勾选“显示公式”选项。
最新发布
Project功能相关设置 Project资源和工时和里程碑
项目分解完，依赖设置完，接下来要就需要对任务分配资源，这里就需要用到我们最开始时添加的资源。设置资源和工时先把工时列添加进来（添加成本，也是如此，里面有很多内容可以自己看一下）添加完后可以开始对任务进行资源分配分配完资源后，系统默认是一天完成任务，根据实际需要，我们进行工时（或者工期）设置设置的时候，系统是根据有效工时来进行计算，我的是周末双休的日历，所以工时遇见周末会自动跳到下一周去进行计算。设置完后界面展示如下：
Project 如何建立项目和资源
安装好Project软件后，那就要开始建立项目。首先你得设置一下日历，系统有默认日历，但是可能不符合你得工作需求。日历设置点击工具栏里的项目栏，然后选择更改工作时间。红色区域是系统默认工作时间。如果要自定义，可以点击右上角新建日历。点击确定
和大家一起走进原型设计的世界—原型设计方法
这一篇文章简单谈谈有关原型设计的一些方法。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.项目管理的五个阶段项目管理总体上包括五个阶段，分别是启动阶段、计划阶段、执行阶段、监控阶段和收尾阶段，这是项目管理的五个过程组。这五个过程组贯穿于项目的整个生命周期，对于项目的启动过程，特别要注意组织环境及项目干系人的分析；而在后面的过程中，项目经理要抓好项目的控制，控制的理想结果就是在要求的时间、成本及质量限度内完成双方都满意的项目范围。启动阶段是一个新的项目识别与开始的过程，这主要是确定一个项目可以开始并着手实施。启动涉及项目范围的知识领域，其输出结果有项目章程、任命项目经理、确定约束条件与假设条件等。项目的计划过程是项目实施过程中非常重要的一个过程，对项目任务进行计划并确保实现项目目标。通过对项目的范围、任务分解、资源分析等制定一个科学的计划，能使项目团队的工作有序的开展。