作为一名前端开发经理，公司有多条业务线，协调资源支持各业务线日常需求成了我的日常。这篇文章主要记录这个过程的思考和如何生成一个直观的日历图。

现状

多个业务线需求，技术方案选型需要统一落地，所以最好能统一收集需求，合理安排；
跨部门（跨省）合作，目前项目流程并不规范，开发人员需求评估存在一定问题，存在延期情况；
通过开发同学工作日志了解工作情况，无法直观地持续跟踪；
部分产品线临时需求较多，开发同学的计划经常改变，加大跟踪难度；
靠文本输出进度、计划、问题给项目经理，不直观；

目标

所以，我希望通过项目管理工具来进行项目排期、资源协调，并输出直观的报告给上级、产品经理、开发经理，将前端工作安排、资源情况透明化，从而逐渐完善项目流程和合作方式。

奈何目前好的、完善的项目管理协同工具都需要收费，所以只能重新细化下需求，考虑在现有了解的资源基础上去尽可能达到目标：

方便的项目管理，可持续跟踪进展
支持里程碑，关键时间点，在关键时间点复盘，逐渐优化工作方式
将信息直观地同步给相关方，增加互相间的了解
- 需求排期情况、节奏点
- 资源投入情况
通过持续跟踪，复盘，逐渐减少临时变更，提前计划
资源饱和下，提供给各产品线需求PK，将重点放在优先级更高的任务上
输出到工作报告中

所以核心还是项目管理和报告输出，综合考虑

项目管理：最终还是决定使用OmniPlan，将项目需求按业务线分组管理起来，但是随着任务的增加，甘特图信息内容太多，不够直观，另外也不容易透明共享。
报告输出：更倾向于使用日历图，像日历日程那样，可以方便查看最近的任务、详情。

所以将重点放在，在OminiPlan项目管理基础上，如何进行合理的管理，将输出的甘特图信息转换成日历图，并形成了最后的解决方案。

最终效果

默认显示当月的项目安排
将任务按颜色区分，关联里程碑
任务展示：业务线、开发人员、需求名称，底下显示完成进度条
点击任务右侧展示详情，如果名称填写需求文档ID，可链接到需求文档
可以筛选业务线、开发人员，减少无关项

OmniPlan

为了最终的日历图展示，首先要确保甘特图数据符合一定的要求，所以先看下输出的CSV：

红框中是我们需要的信息，接下来会介绍OmniPlan使用中的一些点，保证最终输出的数据要求：

任务编号：任务编号按层级编号，以达到类似树形结构的效果
任务分组：
- 根任务按业务线或者大项目分组划分，以此来展示业务线信息
- 关联项目可以自由创建分组，最终任务按照树叶子节点来统计
里程碑：任务划分几个阶段开发，联调，测试，发布，其中后三项为里程碑，必须按此命名，并跟任务建立关联关系
使用关联线来连接任务：里程碑是通过任务关联和任务联系上的
资源安排：任务安排了资源才算计划内的任务，可以查看人员情况，检查未分配的任务
任务拆分：一个长时间的需求，可能会因为紧急或优先级更高的需求，需要进行拆分，但他们同属于一个任务，只要展示一个信息即可；这时候可以通过任务拆分，安排出合适的时间给其他需求
设置基线，持续跟踪：每周计划排好后，设置基线，用来定期复盘，对比计划和实际情况，发现问题

所以最终我们整理的甘特图如下：

日历图

项目管理起来后，只需要持续根据，更新完成情况，并进行数据同步即可。接下来我们需要需要将CSV转换成日历图，这里简单讲下思路：

明确日历图要展示的信息，形成数据结构

{
  productLine: '',  // 产品线
  title: '',        // 任务名称
  url: '',          // 需求文档地址，从名称中获取
  assigned: '',     // 分配
  // 开发
  develop: {
    startTime: 0,     // 开始时间
    endTime: '',      // 结束时间
    effort: '',       // 工时
    done: '',         // 完成度
  },
  // 联调
  jointDebug: {
    startTime: 0,     // 开始时间
    endTime: '',      // 结束时间
    effort: '',       // 工时
    done: '',         // 完成度
  },
  // 测试
  test: {
    startTime: 0,     // 开始时间
    endTime: '',      // 结束时间
    effort: '',       // 工时
    done: '',         // 完成度
  },
  // 发布
  publish: {
    startTime: 0,     // 开始时间
    endTime: '',      // 结束时间
    effort: '',       // 工时
    done: '',         // 完成度
  }
}

将各阶段数据聚合到一条，是为了避免前台再去查找关联关系，展示详情也更方便。数据通过csv进行解析 2. 日历图由两部分组成：日历+日程

先根据年份月份生成日历图
然后根据日历图开始、结束时间，筛选出范围内的任务
按周将任务拆分成数组，这样可以将任务展示成跨天连续的样子最终形成：

{
	dates: [
		[1, 2, 3, 4, 5, 6, 7]
		...
	],   // 日历
	tasks: [
		[
			{
				任务1,
				style: {
					根据开始时间，计算水平偏移
					根据覆盖情况，计算垂直偏移
					颜色区分
				}
			}
		],
		...
	]
}

颜色区分思路：

虽然是随机颜色，但是颜色要能很好区分，另外还要展示进度条，所以需要符合一定的规则。这里基于HSL，只生成色相（H），然后通过饱和度（S）、明度（L）来设置颜色深浅来区分进度条；

所以按照色相环上6大主色：360°/0°红、60°黄、120°绿、180°青、240°蓝、300°洋红不断进行拆分，让临近的两个任务尽可能处于两个主色上

为什么不设置OmniPlan报告模板？

首先模板语法能力有限，难于完成复杂的逻辑，数据处理，日历绘制
可交互性
报告主要是要透明，让相关方知道，同时可以随时跟踪

总结

这样的项目管理主要是为了了解项目安排和资源情况，方便开发经理跟进组员的情况，并统计反馈给相关方。只解决了特定需求，像一些大的项目，应该由PM来去维护项目计划细节来跟进。后续会继续跟进情况，学习项目管理，寻求更合适的方式。