项目管理的黑洞
有不少非软件工程科班专业的老板表示，真的不知道如何管理和把控软件项目的管理，因为那些编程的专业和编程语言他又不懂。
也有不少新晋的开发管理者，从以前负责系统的核心开发人员晋升到团队管理者，刚开始对项目管理、向上汇报、跨部门沟通也表示有点力不从心，不知从何处入手。
软件工程，是一门工程，也是一门艺术。研发管理不应该是黑洞，应该是有科学、有条理、有工具、有流程的。本次来分享下，如何更清晰地洞悉自己的项目状态，从而进行更好的项目把控。
如何看懂你的项目健康状态和完整度
软件项目是指在一定时间段内需要完成的有限需求集合。
从需求被提出开始，到最终发布上线，中间的协作流程，根据敏捷开发、Scrum、瀑布流程，各有各的不同。但对于中间的输出物和协作环节，大同小异。
了解了软件项目的定义和协作流程后，我们就可以在过程中进行实时的把控，而不是在项目最后交付和冲刺的阶段才发现进度风险问题，再迟迟做出反应。
为此，我们需要一个概念，一个统一的通用语言，一个工具。
概念是指我们大家都能理解这个概念是有助于我们每个从整体上把控项目的进度；通用语言是方便开发人员、项目干系人、老板、和非专业的业务部门人员都能通俗易懂地了解，不需要过多解释；工具是借助于在线的图形化工具进行恰当的表达。
巧用项目地图
借鉴于建筑学的经验，结合在买房时销售人员都会通过沙盘图进行讲解、形象生动的介绍。
（图片来自网络）
这里，我们使用【项目地图】这一概念来整体概括和表达项目的整体进度和协作情况。它是一个动态、形象、概要的流程统计图。
从上往下，由浅入深，项目地图分别依次从产品、项目、研发和测试四个层面进行了剖析。
在产品侧，我们关注需求提供的质量，重点关注PRD（即产品需求原型的梳理），拒绝口头上的一句话需求。凌乱的需求是“万恶”之源。一开始的需求定义有多随意，后续的研发就会有多痛苦，因为需求不明确，开发很痛苦。在产品侧的最后，我们关注已完成和已上线的需求，从而构成需求交付的最核心把控。如果一个项目迭代中，有10个需求，这10个需求都完成了，那么此项目也就结束了。
第二层，在项目侧，是由项目负责人、或者技术经理、或产品Manager把控的。他们更多是关心项目的进度、项目风险、项目的整体资源安排。其中，最核心则是关注项目工时的开发进度。从最开始的项目总工时开始，到项目的燃尽图、项目的甘特图、项目的排期表、项目里程碑，到最后的项目整体进度。
第三层，在一线研发执行层面，关心的维度是：项目工时、代码提交、开发文档和发布次数。项目工时方便我们知道项目的规模和侧面的复杂度（一般而言，工时越大，项目复杂度越高，风险越大）；代码提交方便我们及时知道最真实的代码提交情况（可以通过和Git代码托管平台的web hook自动对接和集成）；开发文档是当前开发最为缺失但又是很重要的一环，好的开发文档有利于核通复杂需求的设计思路、技术评审和日后的低成本维护；发布次数是指真实的上线发布次数（通过接入YesDev的一键发布后系统会自动记录）。
最后，在测试层面，关注的是项目质量，通过测试用例、测试计划、Bug修复的进度来体现。
来看看你的项目协作评分
为了方便团队每个人清晰地知道当前迭代项目的协作情况和整体情况，我们设计并提供了项目协作评分，满分是120分。如果协作下来，你的项目协作评分在80分及以上，则是良好的，在100分及以上则是优秀的，如果低于80分，则表示内部的协作不顺畅、或缺乏、或未使用此工具进行协作。
整体上看，项目地图，使用了单向有向图，如果图中的节点未被点亮，则表示这个协作环节是缺失的。至于是否对项目协作和团队的管理来说是必须的，则需要自己来判断。
关注项目的收入/预算、成本和ROI
最后，作为老板或经营者或管理层，可以关注项目的收入/预算、成本和ROI。
在开发项目的同时，也要留意项目预算的消耗，项目不延期、项目不亏本、项目无风险，内部协作顺畅、高效又士气高昂，便是人间好时节。
