由于我们本身没有PM的经历，这里只是根据移山之道和自己生活的体验加上Microsoft Academic Search (MSAS)的特殊背景假想未来的规划：
First and the most：
找到这样的一群人有着同一个愿景：
“打造符合90%学术。。。。。的所有需求”
1、 首先是拉赞助（风险投资，没有风险不投资，越有风险越投资），然后招兵买马，一支高素质的团队，并不是要求每个人的技能都足够强，而是要求每个人都有passion并且懂得责任。现在假设我们钱财和人才都解决了（no money and only seven people now）。
而且现在是2010年11月6日，一个伟大的时刻。
2、 开发原则：网站的用户反馈处理不同于软件的用户反馈处理（Server Pack），由于网站反馈能更加迅速，故而对于网站功能的开发流程定位应该是尽量压缩开发周期，在测试通过后，可控bug下，提高发布频率，让用户能及时体验，根据体验进行项目修改。
以下是粗略估计的人员任务分配：
|
任务 |
需求分析（2） |
架构（2） |
开发（6） |
场景测试（2） |
项目管理（1） |
|
描述 |
前期需求调查，和整个开发流程中用户反馈收集整理 |
在MSAR基础上设计新的兼容功能，分解任务 |
根据架构设计和分解任务和测试反馈完善coding |
结合需求设计case，保证用户体验，及时反馈bug |
监督项目 也要coding |
3、 确定可开发的项目方向，建立共同的愿景（2010.11.6 – 2010.11.12 ）
1) 晓彬和方晓完成结合other comments然后survey（deadline 11.7）
|
|
优点（从技术上和设计上） |
缺点 |
|
MSAS的现状 |
|
|
|
Google scholar |
|
|
|
… |
|
|
|
|
|
|
2) 第一次team brain storm（11.8）
定位服务对象的特性，
· 需要大量的文献搜索，关注准确度和资源获取的便利性；
· 期望能从相关搜索结果中发掘可深入研究的项目，基于技术（文章）的发展趋势或者人物的热门程度
· 干净良好的学术交流平台（社区）********？？？
讨论得出三个
|
|
技术难点 |
实现价值 |
|
Topic1 |
|
|
|
Topic2 |
|
|
|
Topic3 |
|
|
3) 绪勇和周晓调查用户需求（deadline 11.11）完成report
|
|
对于T1, T2, T3的意见 |
关注的功能（按优先级排列） |
无法忍受的事情 |
备注 |
|
在校学生 |
|
|
|
|
|
研究人员 |
|
|
|
|
|
业外人士 |
|
|
|
|
4) 第二次team brain storm（11.12）
evaluate用户需求，确定哪些功能是一年的生命周期中可实现的，哪些是需要未来去完成的，建立一个可实现的里程碑，并通过各个步骤详细的报表制定，坚定的执行下去；最终定位服务服务意义和product目标。
4、 围绕目标学习和开发0.1个版本（2010.11.13 – 2011.5.13）
|
里程碑 |
快速版 目标，时间节点…… | |||
|
修订版 | ||||
|
成熟版 | ||||
|
what |
when |
who |
how |
why |
|
ID1:技术调研已有该功能网站 |
11.13 – 11.18 |
晓彬 周晓 |
争取到老师的支持 |
需较为完善、全方面 |
|
ID2:研究MSAR平台构架 |
11.13 – 11.30 |
方晓 … |
|
|
|
ID3: |
|
|
|
|
|
…“帮助文档” |
|
|
|
|
5、 发布0.1版本测试版，收集用户feedback，更新改进（2011.5.13 – 2011.10.20）
1) 更新周期初定为1个月，根据echo作版本更新，每个版本建立新的里程碑（项目管理）；
2) 建立平台推广平台（需求分析师）；
3) 反馈收集（需求分析师和架构师）
|
反馈内容 |
人群 |
频度 |
价值评估 |
指定解决人 |
解决时间 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
由于刚刚发布的一个月暴露的问题可能比较少，则团队工作重心转为宣传推广，建立广泛的用户基础。
6、 正式发布MSAS的新功能（2011.10.21 – 2011.11.5）
正式发布，整理文档，方便二次开发，并指定产品维护人。
2265
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
