全部的活动均可以看作一个项目来管理。在企业中更是这样。
因此项目管理平台，对于任何一个高科技企业来说都是必不可少的。
OpenProject（如下简称OP）就是一个不错的项目管理平台，软件开源，文档齐备。对于大多中小型公司来说，免费版也已经足以知足工做要求。最新版本的OP还对手机小屏幕的浏览进行了优化，彻底能够作到使用手机对项目进行管理。服务器
创建帐号
做为企业管理中私密性比较强的一类，OP用户帐号的创建须要由管理员完成。
其中的帐户实际只有普通用户和管理员两种，后者有权限对OP系统的设置进行维护和调整。前者则是正常的项目管理使用帐户。
项目管理帐户在具体项目中能够体现为不一样的身份，这个后面咱们再讲。工具
首页和登陆
OP系统页面都是能够定制的，也能够选择默认语言。使用出厂设置的状况下，一般首页语言是你电脑操做系统使用的语言。首页有项目的浏览功能，可是这里能够出现的项目，都是在创建项目时指定为“公开”的项目。
右上角点击“Sign In”按钮能够出现登陆框，登陆框出现后，鼠标不要移到其它网页菜单栏位置，否则登陆框又会消失。测试
OP设计思想和工做原则
OP定位是一个项目管理全流程的产品，能够管理从立项到完成的完整生命期。
在OP管理下的项目和人，基本都处于“任务驱动”的工做模式下。
所以就相似日常使用Email系统那样，天天一上班，OP页面就处于打开状态。随时响应、处理、并更新每一项任务。
虽然OP设计能够将全部的时间转发到Email，但一般的主要项目执行人员，会不断的被大量任务邮件淹没，最终仍是直接工做在OP页面上更方便。优化
创建新项目
首页上，还有页面左上角的下拉菜单中，都有新建项目的按钮。
项目名称必须以“标识符”开头，标识符是以小写字母开头，只包含小写字母、数字、下划线和短划线。这跟一般企业的档案管理要求是吻合的，便于项目的管理和归档。以后可使用中文或者你喜欢的语言，给项目起一个简洁易懂的名称。
项目的描述是对项目进一步的解释。
以后的“标识符”一栏，一般能自动从项目名称中提取，若是提取的不满意，能够本身修改一下。
项目的类型默认有两种，这个能够由管理员，根据团队的实际状况增减。这个类型并不影响OP对项目的具体处理，主要是提醒项目成员，根据企业的文化、共识、习惯，选择何种方式对项目进行管理。
默认的两种类型，Standard project是指标准项目；Scrum team通常是指当前比较流行的敏捷开发团队管理模式。
最后的“公开”选项，就是指项目是否在首页、不须要登陆就能供查看。
这部分介绍的比较详细是由于咱们刚刚接触OP,实际上除了项目名称，都是能够不填写或者使用默认值的。
完成项目的建立后，在左上角下拉菜单里面项目的列表里就能查看到项目。对于新项目，通常还有两件事情须要作：
选择左下角“项目设置”菜单，屏幕右侧，选择Tab中的第二列“模块”，在其中勾选在本项目中须要使用的工具。这些工具包含：spa
- Backlogs: 未完成工做的列表，能够理解为项目级别上的todo list。
- Cost control: 对项目进行成本管理，成本管理主要包括人员成本、设备成本和现金成本。（固然项目管理自己默认包含了时间成本）
- Cost reports: 造成项目成本报告。
- Documents: 容许你上传项目文档，并对文档进行分类管理。
- Meetings: 项目的会议信息，一般是起到会议通知的做用，并能够成为项目的沟通记录。
- 代码库: 支持SNV/GIT两种版本化的代码管理工具。
- 工做报告跟踪：这是整个项目管理的核心
- 新闻：一般是项目组相关的内部消息发布。
- 日历：至关于造成项目维度的平常工做计划。
- 时间线：造成项目的甘特图。这个模块是我比较喜欢的，不过官方已经计划使用工做包中的时间线工具替代掉了，并计划于8.0版本中取消此功能。但愿到时候工做包中的时间线也能拥有这样方便的定制能力吧。
- 时间跟踪：用于在用户活动中统计时间的消耗。
- 活动：这是对于管理人员比较有用的一个模块，用于实施了解到项目的具体工做，跟工做包的管理方式相比更微观。
- 维基：用于发布项目的最新进展、技术积累或者观点等内容，是项目的博客，一般的项目都是用于对项目组外的沟通。
- 论坛：一般用于项目组内的沟通、讨论及知识积累。
这些功能模块，根据项目的需求自主添加，理论上越多越好，但对于小项目，过多的模块会显著的分散工做人员的注意力，起到反面的做用。
另一个必要的项目设置是Tab中的第四项：版本。国内软件开发一般缺少版本化的管理和规划，但实际上几乎没有软件不须要版本化的管理，因此强烈建议你在新建项目时就在这里创建最初的版本计划。
一个比较特殊的用法是敏捷开发中的Sprint（冲刺）概念，能够在工做类型中添加（后面会介绍）。但更贴切的一个方式是把项目划分的足够小，而后用Sprint版本的方式来管理。操作系统
项目能够添加项目成员，默认的身份是Member，就是普通工做人员，也能够指定为项目管理员，就是中国俗称的项目经理。
每一个项目成员均可以指定成员的Cost，这是指在这个项目中，该成员的成本是多少。换言之，每一个不一样的项目，一样的人，能够有不一样的成本，这是合理的。由于项目不一样、岗位不一样、参与度不一样，固然都会带来人员成本的不一样。
(货币符号当前版本尚不支持修改，请在团队中自行规定使用方式，好比直接把欧元符号当作人民币。)
其余的合法用户，不是项目成员，也不是项目管理员，则自动成为Reader角色，就是能够了解项目，但不能参与和修改项目。
那么更高要求的保密项目怎么办？这个在OP中并无给出特别的处理。一般来讲，反正是一个免费的系统，服务器的需求又不高，须要保密的系统单独部署一套就行了。
设计
项目任务的添加
项目创建后，能够根据具体工做，向项目中添加具体的任务条目。
在OP中，项目条目是分类型进行管理的，这个类型能够在项目设置中增减和修改，但一般直接使用默认的7种类型已经能够知足大多项目。这其中类型分别是：项目管理
- Task: 一般意义上的任务。
- Milestore: 里程碑，指项目的阶段成果。
- Phase: 阶段。
- Feature: 产品特征。
- Epic: 史诗，其实就是大的用户故事。
- User story: 用户故事。
- Bug: 故障、缺陷。
这些类型，要根据本身团队的习惯来选择，或者再设置增减。做为一个通用的软件平台，OP确定提供了多于通常需求的重复、或者相似的类型，不加区分的在一个项目中使用每每会致使成员的困惑。
这些类型的重要之处是，对于每个不一样的类型，会有不一样的工做流程与之相对应。Bug是在各类项目管理流派中歧义最少的概念，咱们以Bug为例，能够有以下的工做（或者工做状态）：资源
- New: 测试人员提交一个新Bug。
- Confirmed: 开发人员确认这是一个Bug。
- In development: 正常开发解决这个Bug。
- Developed: 开发已经完成
- In Testing: 正在测试Bug是否仍然存在。
- Tested: 测试结束。
- Test failed: 测试失败（一般指Bug仍未解决。本Bug解决了，又致使了新Bug通常须要沟通，也有可能会新申报一个Bug)
- Closed: 问题解决，Bug流程关闭。
- On hold: 本问题存在，但因技术限制、资源限制、项目版本限制没法解决，暂时存档，未来会解决。
- Rejected: 驳回，经开发人员确认这不是Bug。
关于对于某一工做类型的工做流设置，须要由系统管理员在系统设置中修改。此外项目管理对于项目类型的增减，实际也是在系统管理员设置的多种工做类型范围内进行增减。
继续说项目任务的添加。对于每一个任务，指定任务的执行人（指定人）和责任人是很重要的，由于项目管理的核心是对人力资源的调配。执行人跟责任人能够是同一我的，也能够不是。二者的区别能够参考《彻底责任观》课程或者《当责》畅销书。
项目管理的另一个重要维度是时间，因此虽然新建一个项目和新建一个任务，有不少字段均可以空缺，但时间指标仍是必定要填写的。OP支持绝对进度和相对进度两种时间跟踪方式，前者指相似“本项目预计32个工时完成”，后者则指好像“本项目计划8月10日开始，到8月20日完成”。两种方式均可以根据本身团队特色选用，但通常不须要都用，不然计划调整时候，每一个项目都须要经过计算填写两次。由于大多的项目计划都须要输出甘特图，因此建议使用日期计划的方式。（仅供参考，我也见过不少规范的项目计划是二者都列出来）。
此外就是刚才说过的版本化管理，每一个新建任务，除非是共有性的，不然尽可能从属于某一个版本。并且这样分配，不少先进的特征，好比路线图管理，才能帮你自动的生成一些报告。
任务条目能够上传文档，用于描述更详细的内容，好比开发需求文档。理论上讲这个文档可使任意格式。但一般的习惯，这个文档主要供阅读使用，因此最好是pdf之类，直接能够在网页打开的文档。而能够编辑的版本归类到源代码进行版本化管理或者文档共享模块中管理。
任务条目创建后，在项目列表中就会出现该项内容，点击列表最后的“！”图标，能够查看条目的详细内容及再次编辑和工做状态更新。在最上面Tab条中的“关系”一栏，能够设置项目的前置项和后置项。对于不少强合做类的项目中，这个设置是很必要的。不然会出现，原本B任务须要等待A任务的结果才能执行，但甘特图中，A与B并列的状况。
开发
平常执行工做
执行工做一般都围绕着工做包这个模块进行，固然实际上不少其它维度的浏览界面中也能进行。好比对于任意一个具体的工做人员，每次登录后的首页中，就有了大部分涉及到他本身的工做项目。
工做人员只须要根据具体条目的内容，完成本身的工做，随后在条目的状态一栏修改项目的进展状态，就可让项目的总体进展更新。
注意强调一下，在一个规划很好的项目中，一般项目和项目内容创建后，是不须要进行大量修改的。平常的工做都是只须要更新项目的状态和补充上传项目的文档、代码便可。
若是一个项目在执行过程当中须要不断的调整项目的内容、项目设置、修改具体条目的内容和时间计划，只能说项目从立项的规划就存在了大量问题。
项目执行过程当中的沟通协调，是经过论坛、WIKI、新闻、会议的形式来完成的。项目成员都应当养成天天定时查看项目信息的习惯，特别是为了不大量的垃圾邮件而关闭了邮件通知的状况下。
平常管理工做
项目平常的管理工做同执行工做可能相似，但更多的在于使用OP的多个维度的浏览或者报表，对项目的内容和执行状况进行把控、分析。从中发现问题，随后对相关人员进行具体的沟通、协调或者辅导。
也较多会对项目的具体内容和项目计划进行调整的状况。
一般是由于，在国内的开发团队中，虽然是由项目经理对你们进行任务安排，但随后是由具体执行人员完成文档工做和指定执行计划。
若是项目经理认为执行人员的理解有误差，或者计划制定的有缺陷，项目经理也会直接对已经存在的条目进行编辑修改。但请注意，这种修改，一般要在线下的沟通完成以后。以避免发生管理层面的误会。
这些工做内容，由于一般都是在线下进行，因此在OP平台上每每并不会留下痕迹。但正因如此，管理人员必定要督促本身经过OP平台对项目的细节进行掌控，避免出现具体工做人员已经在平台上对项目状态进行了更新，或者发布了论坛求助信息，而得不到响应的事情。
本应双向的信息得不到响应，或者线上线下须要两次沟通，都会影响项目执行人员的心情和工做状态。