把“血”注入到产品里

(求轻拍）

首先企业内部，是需要一套专门针对项目或者需求进行管理的软件的。

内部的协作，我认为是主要解决以下三个问题：

1. 信息共享与沟通，包含文档、聊天信息等；
2. 项目监控与推进；
3. 管理架构到绩效架构的制度。

分享一些第三方的系统：

禅道： 上手难度：★，实用程度：★★★

Atlassian系：上手难度：★，实用程度：★★★★★

Slack： 上手难度：★★★，实用程度：★★★★

Tower： 上手难度：★，实用程度：★★★

产品流程规范

步骤：需求搜集→需求整理，成型→需求评审→立项，需求分发→敏捷→需求迭代

1. 需求搜集和需求迭代：可考虑开产品运营会议或其他形式的需求评审会议，以周为单位总结上周工作以及安排下周工作，同时可上传到wiki便于查看需求路程。建议产品与运营是需要开会的，同时产品自身应与BD多沟通，毕竟一线人员最懂客户场景和竞品动态。

整个产品逻辑的讨论应围绕核心问题驱动：How to drive it works ！

• Drive的逻辑，我认为会建立在两个基础上：数据衡量和可接受故障度；
• 有效的、全面的Dirve，也是需要逐步迭代的；
• Dirve，意味着找到核心驱动能力，意味着求证充分必要性

2.需求整理和成型

代表性文档：PRD，中保真原型。

其中，PRD着重描述包含但不止于系统架构、系统逻辑、业务背景、可衡量开发目标。中保真原型着重体现系统交互和UI。

3.需求评审和立项，需求分发

举行快速沟通会议。团队针对可能产生的问题进行快速沟通，敲定。例如使用Atlassian系产品，可考虑部署jira（其他项目管理软件）进行需求分发。它可以以群组形式，按照产品→项目（故障、改进、任务）层次，查看某具体项目简述和需求文档，并标注项目起止时间和状态变更。使用wiki（其他知识管理软件）进行知识管理，例如产品部贡献产品逻辑，BD部门贡献客户对接逻辑。

4.敏捷

• 拆分开发任务，分发到具体人身上，列出预估开发时间，便于监控项目进度。对于人的分发，我比较崇尚游击队+正统军队式，即对小改动小项目，能灵活安排人快速处理，同时对于多人协作项目，能指定某部分人参与，也可以是指定某个人为该部门在此项目上的直接沟通人，而绩效考核，也可以通过每个人的完成任务数和难度来衡量。
• 在业务正确的前提下，严格执行PRD和原型制定的可衡量标准。

Q：遇到多个紧急需求拥挤，应如何处理？

通常遇到多个紧急需求，多数在这个场景下发生：你干着活呢，突然抛过来N个需求 ，说非常紧急，需要立刻完成。这都是建立在需要立刻完成的前提下，都是你几乎没办法腾出时间来逐个解决。

个人感觉还是有办法衡量一下的，一般来讲影响与客户合作项目或公司流水的，我会认为是最紧急。

其次是老板或高层直接下达的需求，再其次是影响其他部门或其他人的项目的需求。