程序员杀产品经理祭天(SacrificePM)团队

1.团队成员简介和个人博客地址

故事

我们队伍的建立过程稍具戏剧性，大家看我们也颇为奇怪，这么一支8人队伍是怎么诞生的呢？其实我们原本分属三组，而第一周组队结束后退选了接近50%的人，许多小组被拆的七零八散，我们小组经历一次退课潮后从七个人到只剩下了3个人。怎么办？我联系了群里想做游戏的王子铭和王辰昱(高工大佬)，说服他们加入了我们队伍，但在他们确定加入之前，我又跟助教联系了另一支队伍，这就是原来的程序员杀产品经理祭天队(英文名是叫KillPM还是SacrificePM呢？)，这支队伍也还剩下三人，我们就暂时合在了一起。

姓名:博客园ID

李金奇:crvz618
陈鑫:silenti
解小锐:xxrxxr
杨森:YoungForest
蔡帜:RedPotion
王辰昱:hitaku
刘亚洲:修炼爱情
 王子铭:永远与须臾的罪袋

2 团队项目介绍

2.1 游戏开始

我们组的出发点是制作一款能够经得住玩家考验的游戏，在游戏类型上最终选择了模拟经营，当时还考虑了射击,rpg等风格，但是没有非常仔细的比较分析，只是凭着兴趣和想象选择了制作模拟经营类型的游戏。
当时觉得这类游戏应该会是比较容易上手制作的，但是实际的开发过程没有想象的那么简单。题材上我们选择了经营软件公司，因为这是一个大家都比较熟悉的事物(更别说我们正在上软件工程课)，还因为有一些成熟的游戏有着类似的题材(开罗游戏发展国)。

2.2 寻找用户

相关博客:
NABCD分析
 功能规格说明
可能的用户类型

对游戏非常感兴趣，经常玩游戏，而且熟知各种游戏机制流程，并且喜欢骚操作的重度(中毒)玩家他们是游戏老手不会被表象迷惑知道游戏内容的好坏有着自己的风格和追求但一旦喜欢一个游戏就会深入地了解它心甘情愿的作一个死忠粉
对游戏较感兴趣 时不时地浏览各类应用市场寻觅目标通过玩游戏来填补空闲时间但没有重度玩家那样主动和热情这类玩家不会那么追求游戏深层的品质能够吸引他们的东西主要是新鲜、简单、而且能够经的住玩的游戏他们也常常变换自己的口味不会对一个游戏入迷太深他们是成长中的游戏玩家
对游戏不感兴趣 不是一个经常玩游戏的人但是如果有朋友推荐还是愿意尝试他们属于萌芽中的游戏玩家对游戏了解不深讨厌过于复杂的操作和难以理解的东西没法忍受长时间的失败但是一旦接受一个游戏也会花上不少时间尝试
讨厌游戏 认为游戏是毒害周围人的坏东西自己从来不接触游戏也不愿意接触很难让他们尝试一个游戏他们属于种子状态的游戏玩家要改变他们的态度需要一个契机等待阳光雨露浇灌来发芽
开明的看待游戏 将游戏作为生活中的一部分，合理安排时间，适度游戏，这类人很成熟很理性，有着自己的生活节奏，将游戏作为一种尝试和体验他们对游戏的态度更像一个探险家有目的有计划享受探索的乐趣，而且懂得保护自己
对游戏爱恨交织 被游戏破坏了日常的生活，或者有类似的经验，对游戏敏感但是往往不愿意去玩
因为担心游戏的副作用带来的影响他们属于受到了伤害的休眠期游戏玩家

群体1显然不是我们的目标用户，这类人喜欢的往往是有成熟开发经验的团队开发的成功作品，群体2非常值得关注，因为他们的标准不是那么高，更容易接受一个未成熟的游戏作品，而且用户群体很大，群体3接受线下传播的可能性更大，由于我们肯定要从线下推广，因此也需要仔细考虑，群体4和6的影响应该不会很大，群体5就国情而言虽然人数比例较少，但普遍受过较高的教育或者有丰富的人生经验是很有价值的用户群体但满足他们的需求也相应的比较困难

得到的结论:群体2和群体3是我们的主要目标用户群体

2.3 游戏设计目标

为了满足群体2和3的需求，游戏必须要容易上手才能够被接受，而为了有一定的存活时间，游戏必须有一定的粘度。
考虑到我们的题材是经营软件公司，如果加入一定的养成机制会很适合这个题材，员工的培养，公司规模的提升，以及技术的进步等。
另外商业模拟普遍需要玩家对投资进行考量和选择，这要求一定的策略性和平衡性才能保障游戏的体验。
将这两个目标细化可以变成如下的品质

简单-游戏机制集合小，学习成本低
休闲-有让人放松的氛围，图形文字让人感到亲和
故事-游戏有着吸引人的背景、世界观和故事
趣味-事件、人物及相关细节让人感到有趣
真实-游戏规则中对现实规则的合理继承
策略-资源选择、投资、目标与风险、竞争与合作的要素
硬核-很困难，但是也会给人很大的成就感
精细-细枝末节，不重要的地方，一般人不留意的地方也精心设计，完美主义，巴洛克倾向

这个表格写在了功能说明文档里，但是很可惜，我们并没有进一步深入讨论游戏设计相关的内容。这点之后会提到。

2.4 具体设计

这一块是彻底失败了...

2.5 原型

2.6 分工

我们按组别将人员分成了4组

组别	人员
策划组	蔡帜王子铭
开发组	陈鑫解小锐李金奇
美术组	王辰昱
测试组	刘亚洲杨森

最后证明这样的分工存在两个软肋，一是策划组的我(PM)高估了自己的能力和战胜拖延症的决心，同时承担PM的工作和策划的工作的确有些力不从心，另外又经常拖延导致策划这块我分担的责任没有很好的完成。另一个软肋是美术组，由于游戏开发存在大量的美术工作，而美术工作与程序的耦合又过于紧密导致实际工作量大部分都落在了一个人身上。

2.7 管理

使用github进行issues分配，重要节点开会，其他时间小组内部讨论解决，有重要的事情在群里讨论。
这是当时写的WBS图

2.8 平衡

我们在实际开发的时候由于策划的软肋导致没有一个完整的游戏设计说明，为了满足时间需要只好先进行一些非核心功能的开发，原本预期在非核心功能开发的同时完成策划的设计，但是实际上来说由于分工和效率问题没有解决，导致这一点也没有实现。最后我们还是只能采取折中的方案，由开发和美工以及数值自行设计相关细节，以质量损失为代价挽回了一些进度。

2.9 文档和规范

git仓库中的wiki部分存放了相关文档及说明不过齐全的文档确实找不到，有的人做到了坚持更新，有的人没有，PM没有有力的督促，因此这一点上没有做到完善。

2.10 用户反馈

评价博客

3. 进展情况

3.1 燃尽图

燃尽图
可以看到初期项目进展有些平缓，这是因为项目刚开始进行，需要一段时间学习相关知识，之后督促了一段时间，完成了不少工作，但之后有一大段空白时间几乎处于停滞状态，这确实是真实发生的事情。之后就一直在时赶时停，一直没能追上进度，也没有认真的反思。从燃尽图上来看，项目的管理确实出了很大问题，虽然后面有所改善，但仍然只是勉强恢复正常工作速度，而没有加紧将之前落下的进度追上。

3.2 发布说明

博客地址

3.3 发布平台

酷安
其他平台正在注册申请

3.4 测试报告