所有的活动都可以看做一个项目来管理。在企业中更是这样。
所以项目管理平台，对于任何一个高科技企业来讲都是必不可少的。
OpenProject（以下简称OP）就是一个不错的项目管理平台，软件开源，文档齐备。对于大多中小型公司来讲，免费版也已经足以满足工作要求。最新版本的OP还对手机小屏幕的浏览进行了优化，完全可以做到使用手机对项目进行管理。
建立账号
作为企业管理中私密性比较强的一类，OP用户账号的建立需要由管理员完成。
其中的账户实际只有普通用户和管理员两种，后者有权限对OP系统的设置进行维护和调整。前者则是正常的项目管理使用账户。
项目管理账户在具体项目中可以体现为不同的身份，这个后面我们再讲。
首页和登录
OP系统页面都是可以定制的，也可以选择默认语言。使用出厂设置的情况下，通常首页语言是你电脑操作系统使用的语言。首页有项目的浏览功能，但是这里可以出现的项目，都是在建立项目时指定为“公开”的项目。
右上角点击“Sign In”按钮可以出现登录框，登录框出现后，鼠标不要移到其它网页菜单栏位置，不然登录框又会消失。
OP设计思想和工作原则
OP定位是一个项目管理全流程的产品，可以管理从立项到完成的完整生命期。
在OP管理下的项目和人，基本都处于“任务驱动”的工作模式下。
因此就类似平常使用Email系统那样，每天一上班，OP页面就处于打开状态。随时响应、处理、并更新每一项任务。
虽然OP设计可以将所有的时间转发到Email，但通常的主要项目执行人员，会不断的被大量任务邮件淹没，最终还是直接工作在OP页面上更方便。
建立新项目
首页上，还有页面左上角的下拉菜单中，都有新建项目的按钮。
项目名称必须以“标识符”开头，标识符是以小写字母开头，只包含小写字母、数字、下划线和短划线。这跟通常企业的档案管理要求是吻合的，便于项目的管理和归档。之后可以使用中文或者你喜欢的语言，给项目起一个简洁易懂的名称。
项目的描述是对项目进一步的解释。
之后的“标识符”一栏，通常能自动从项目名称中提取，如果提取的不满意，可以自己修改一下。
项目的类型默认有两种，这个可以由管理员，根据团队的实际情况增减。这个类型并不影响OP对项目的具体处理，主要是提醒项目成员，根据企业的文化、共识、习惯，选择何种方式对项目进行管理。
默认的两种类型，Standard project是指标准项目；Scrum team一般是指当前比较流行的敏捷开发团队管理模式。
最后的“公开”选项，就是指项目是否在首页、不需要登录就能供查看。
这部分介绍的比较详细是因为我们刚刚接触OP,实际上除了项目名称，都是可以不填写或者使用默认值的。
完成项目的创建后，在左上角下拉菜单里面项目的列表里就能查看到项目。对于新项目，一般还有两件事情需要做：
选择左下角“项目设置”菜单，屏幕右侧，选择Tab中的第二列“模块”，在其中勾选在本项目中需要使用的工具。这些工具包含：
- 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平台对项目的细节进行掌控，避免出现具体工作人员已经在平台上对项目状态进行了更新，或者发布了论坛求助信息，而得不到响应的事情。
本应双向的信息得不到响应，或者线上线下需要两次沟通，都会影响项目执行人员的心情和工作状态。