Project
聊聊软件项目管理及成本核算
谈到项目管理，想必大家也非常清楚其重要性。由于项目具有临时性、独特性、渐进明细等特点，因此每一个项目的管理都各有差异，特别是对于软件项目来说，这种差异更是受人的主观能动性影响差异和变化更多。几年下来，我们做了大大小小、林林总总、各种各样的软件项目，有一些在当时的情境下似乎做得还算可以的软件项目，也有大部分做得普普通通、不好不坏的软件项目，还有一些是做得比较失败的软件项目。总的感觉就是，软件项目管理是一门学问，不是某一个项目经理单打独斗的学问，而更多是团队协作的学问。固然，一个优秀的项目经理能在项目中起到至关重要的作用，但软件项目开发，终究是一群人的战斗，因此共同保持对项目的敏锐度，才有利于项目的顺利推进，也才更有利于对项目的可持续性。早些年，我们常常会出现销售、售前、售后（交付）容易脱节的问题，甚至是相互挖坑的问题。举个例子，销售人员在完成合同签订将项目转到交付环节后基本上就不怎么关心后续项目交付的情况而是等着项目验收及收款，售前缺少与售后（交付）团队的沟通衔接导致需求理解出现偏差甚至是重复做用户调研等问题，项目交付团队缺少与销售、售前沟通而导致多走了不少弯路等等。这类问题其实很常见，但凡在一些做得不好的项目中基本都能找到这些影子。做甩手掌柜这种行为在项目执行中会带来很大的问题，而且往往很难取得客户长期的信任与持续合作的机会。因此，销售、售前、售后（交付）协同融合是做好项目的根本保障。另外一点就是，每一个软件项目都有其特定的使用场景，都有其存在的特定意义。我们要想将项目做成功、做漂亮，就需要思考个中奥秘，就需要抓住关键干系人，帮助客户做出一些亮点、特色出来。这些亮点、特色不在乎多少，而在于要与客户取得共鸣，解决客户的痛点、戳到客户的痒点、触到客户的爽点。要做到这些，往往不是一两个人的事情，而是整个项目团队甚至包括销售、售前及相关人员在内的共同责任。比如当初本人在全省各地市做系列项目的时候，也是抓重点地市单位、抓创新意愿强烈的地市单位，有的放矢、凝心聚力地做好一些关键节点并做出一些亮点。当然，那些具有可持续性的软件项目或者能产生规模效应的软件项目更值得我们这样做，我们更应该也必须全力以赴。从项目管理的角度来讲，每一个项目都会经历启动、规划、执行、监控、收尾等过程组。个人认为，项目管理过程除了交付团队必须要重点关注和着重做好之外，对于销售人员也是有必要了解的，并且在整个项目的执行过程中保持良好的沟通渠道，共同应对软件项目实施过程中的各类问题及可能出现的风险。此外，相信大家都很关注软件项目的成本问题，到底一个软件项目是不是挣钱、能不能挣钱，是挣现在的钱还是挣将来的钱，是挣项目自身的钱还是挣关联项目的钱等等，都会关系到我们项目型软件开发的走向。在我们过往的做法中，我们通常采用经验值估算法、功能点估算法等方法对软件项目的成本做基本测算，这种方法毕竟因人而异，也会有一定偏差，往往很难让我们真正搞清楚软件项目的成本究竟有多少。同时，我们也会通过判断人员集中投入度等来大致判断软件项目成本，虽然有一定效果，但依然很难指导我们行动。从我个人角度来说，我更喜欢用数据说话，从数据中分析并找到一些我们可能想要的答案。为此，从去年开始，我在部门内部开始尝试探索基于项目资源实际投入工作量、人力费用明细数据、财务报销明细数据的研发成本费用核算模式，尽可能地核算到每一个项目中，从而帮助我们更好地分析判断项目成本费用分布及变化情况，为软件项目的成本控制提供一些基础的数据依据。当然，成本核算并不能做到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、设置“任务模式”为“自动模式”或“手动模式”
如何评估项目的开发时间
在项目开发中如何进行时间评估，是一件很难同时又很重要的事情。一定即做到准确客观又做到有理有据。通常领导希望评估的时间越短越好，而对开发人员来说时间越长越好，这似乎是矛盾的，但站在不同的利场又都有道理可讲。如何进行项目时间评估是非常考验一个项目经理的工作能力。以前工作基本上一直在做项目，在实际工作经验中对项目时间评估有一些自己的总结。当收到市场明确项目意向后，首先会确定一个有多年项目经验的PM并跟甲方接口人进行对接，如果条件允许乙方项目经理会进入甲方公司现场跟接口人详细沟通项目情况，经过多次沟通和需求确认最终达成两个意向：一是软件规格说明书和项目DEMO。这是非常重要的，软件规则说明书和DEOM最终都要经过甲方接口人确认并需要签字。这些要做为附件并做为合同的一部分，因此以后验收要用到。关于规格说明书的内容通常包括：项目建设背景，功能需求（前台和后台所有功能点）、数据结构、接口相关、UI相关，架构相关，环境相关(软件环境和语言环境)，服务器相关、安全性上的考虑、性能上的考虑和部署相关考虑等等，每一项都要非常细致，精确到最小颗粒。这些都是项目评估的重要参考参考依据。还有就是DEOM，这也是前期跟客户确认的一个非常重要东西。文档虽然可以把所有功能需求都考虑到，但不直观，通过DEMO制作，把项目的前台，后台需求都可视化的展现在客户眼前，非常直观，非常清晰，一目了然，特别是UI和界面非常容易就能确定。当然规格说明书和DEMO是一个整体，文档上的内容都要按照DEMO来写。也就是说跟甲方接口人确认以DEMO为主，文档为铺。当软件规则说明书和DEMO都跟客户确认清晰后意味着软件需求分析阶段已经完成。阶下来要做的就是制定开发里程碑和时间评估，前期需求采集详细与否直接关系到此阶段的功能点评估。时间评估主要通过以下几个方面来考虑，采集需求（已完成），需求分析（开发和测试人员了解需求），系统架构设计，环境搭建（软件环境和硬件环境），UI设计与切图（还包括跟甲方再次确认），数据库设计，代码编写，测试相关（测试与问题修改）、部署相关（测试版本部署和正式环境部署），文档编写（概要设计、详细设计、数据库设计手册、使用手册等）等，通过这些惟独对软件进行时间评估。如何进行时间评估？通过多个项目经验我是这样做的：按上面的提到各个点我会评估出三个时间：最理想状态下项目完成时间，正常情况下的项目完成时间，最慢的情况下项目完成时间。同时也会找一个或两个相关的开发人员同样评估出这样的三个完成时间。我会把几种时间汇总到一起，例如我评估的三个时间分别为T1,T2,T3其它开发人员假设一个评估的时间为T01,T02,T03,我会把这6组数据累加到一起同时除以6即(T1+T2+T3+T01+T02+T03)/6求出平均时间，但求出这个平均时间还是不够的，还要加上一个风险控制时间，假设平将时间为60天，风险控制时间=60*10%，10%是自己通过做很多项目得出来的一个权重值。所以总的项目时间为 60+10 =70天，即70人/天，当然天都是以工作日单位。通过这样来评估时间并通过项目验证基本上没有太大的误差，也就是说相当准确的。时间评估完成了，如何能保证在规定的时间内完成工作任务？这就是体现了项目经理的控制能力，控制包括：时间控制，质量控制，成本控制和沟通协调等方面。这时对项目经理的要求是非常高的，做项目我的习惯一般是前期要紧张起来，特别是时间上要一定要控制非常严格，规定什么时候完成的任务一定要在规定的时间内完成，完成不仅仅是代码开发完成，还要包括单元测试以及对功能需求的回顾，最终都没有问题了这才能叫做完成。每一个功能或者模块都这样去做，到后期的测试是很有利的。如是前期控制的好的在中期可以把节奏稍微调整一下，让项目成员可以稍微的松口气。
Project 怎么批量设置条形图样式
在甘特图区域空白区域双击，弹出【条形图样式】窗口后，在最左侧的【名称】栏中找到并点击【任务】行，默认第一行就是，然后点击下方的【文本】，这里会看到左、右、上、下、内部共5个位置可以设置条形图要显示的内容，显示的内容就是直接调用对应"列"名称里的信息。比如要在左侧显示任务名称，就在【左侧】后面选择【名称】。点击确定后，所有"任务"条形图左侧就都显示其任务名称了。需要注意的是，在条形图样式窗口中在【任务种类】那里显示的是针对哪些任务进行设置，比如刚刚操作的"任务"，就是针对"标准""非关键"等，那么就是说，是针对非摘要任务、非关键任务、非里程碑任务、非手动计划(即自动计划)。如果要批量设置摘要任务、关键任务、里程碑任务，再在【条形图样式】窗口中找到对应的"名称"或"任务种类"进行设置即可。Project软件把这些不同任务种类分开，实际上是给用户多了批量设置不同任务类型的可能性。
Project 怎么添加劳动力资源和数量
第一步是创建资源，是在【资源工作表】视图，总共有三种类型的资源：工时、材料、成本。在动图演示时，我分别创建了这三种类型的资源。 第二步是分配资源，其实在很多视图都能给任务分配资源，但是最方便的视图是在【任务分配状况】视图中操作。 资源和成本是相关的，如果要体现任务或项目的成本，必须通过资源来体现。
Project能不能在时间刻度上按照每月1~10日、11~20日、21~月底这样来显示
Project能不能在时间刻度上按照每月1~10日、11~20日、21~月底这样来显示，这是完全可以的。 在时间刻度上双击，弹出【时间刻度】窗口后，首先把中层默认的显示单位从周改为月，至于标签选择自己喜欢的样式就行。然后在底层把显示单位从默认的天改为旬，然后在标签里选择1/1, 1/11, 1/21这种形式，最后点击确定就大功告成了。
Project各版本在功能上的差异
Project各版本在功能上的差异并不大，之前曾专门发过一篇文章总结了各版本的差异。 另外，Project 2010中文版的翻译与2013/2016/2019略有差异。 比如基准这个概念在各版本的英文版中都叫做Baseline，但是在Project 2013/2016/2019中文版中翻译为“基线”，Project 2010的中文版翻译为“比较基准”，其实都是一个意思。 再比如，在计算关键路径时有一个人为可以设置和影响的因素叫做期限，在各版本的英文版中都叫做Deadline，在Project 2013/2016/2019中文版中翻译为“最后期限”，而在Project 2010的中文版翻译为“期限”，也都是一个意思，只是中文界面略有差异。
在使用Project排计划的时候，有同学可能会遇到任务循环的错误提示窗口。这是什么原因呢？
在使用Project排计划的时候，有同学可能会遇到任务循环的错误提示窗口。这是什么原因呢？不能给摘要任务与它的子任务之间设置彼此的关联关系。 因为摘要任务与它的子任务是包含与被包含的关系，而FS的关联关系则是两个任务在时间上的先后关系，所以它是冲突的。