三个多月过去了，我们软件开发经历了Alpha版本、Beta版本、Beta2 版本，最终做出来了，在该月末就会发布，alpha版本过后组员一起开了会，然后在beta版本，beta2版本我们软件设计和alpha版本UI设计基本完全不一样， 工作量也比alpha版本大很多，队员们的热情也此起彼伏，设计草案也换了很多……回首起来，确实值得很多反思

…………

…………

…………

如果我们重新来过，那么我会做的比现在更好么？ 如果我们继续改进，那么我们会有什么其他突破？如果？

下面我将从这几个方面来一起回首我们的软件开发以及改进流程

我们软件具体实现和设想已经在上一篇博客里写的很清楚，这里我就不在此阐述

http://www.cnblogs.com/OMG-Team/archive/2011/11/26/2264704.html

1. 软件的设想和计划

可以说任何事情都要有个大纲，大纲可以保证我们正确无误的沿着计划前进，我们在Beta版本继续明确了我们会议助手的核心：帮助那些参加会议的人高效而又便捷的参加会议，听talk，记录自己喜欢的论文和会议。 为了更快地展示会议的日程，我们设想分两个层次，第一个层次是session和下面的talk，第二个层次是talk detail 界面， 然后支持session , talk 添加按钮并闹钟提醒功能。然后为了实现我们强大的功能，我们选择添加作者以首字母为索引的作者列表，然后点击作者列表可以到作者的详细界面，添加地图，添加记事本，添加关键字搜索，添加会议设置，添加主办方提供的其他信息。其实我们只是为了完成这个设想而假设了很多结果，这个肯定会有用，那个肯定也会有用，想着feature越多，肯定越好

Feature越多，功能越强大？ 这样是对的么？

虽说我们做过了用户调查，但是我们调查的结果并没有很满意，我们并没有很好的手段去了解用户的痛苦，去聆听他们的心声，因为真实的用户都是我们的导师，我们害怕耽误他们的时间，所以用户调查做的不是很好，用户在开会的痛苦除了如何高效地展示agenda之外我们的定位也不是很准。 通过现在的用户反馈，除了展示agenda和展示用户提供的其他信息（宾馆，会场等） 我们发现其他feature并不是很突出，或者说对用户来说要不要都是差不多。

而且还有一点是： 我们的设计缺少用户粘性，有可能这个软件用户用了一次，就不用了，因为这个软件不是social的，都是individual，没有一个用户交流的场景。

根据真实用户反馈，其实开会时候，很多参会人员都会推荐这个会议，那个会议，都会讲述自己看了写什么论文，或者感觉什么论文不错，也会交流自己的心得，甚至会交流自己的联系方式

因此如果我们重做的话，除了展示agenda以外，我们想可以有多个标签，如果感觉喜欢或者有意思的或者已经读过的，或者将要读，或者推荐给其他人的都可以进行分类，一旦标好之后，我们就可以通过这些标好的论文或者会议进行交流了。 可以实现近场通信，或者和周围的服务器进行通信，这样我们既可以满足用户的多样化需求，也可以满足用户快速交流的需要，甚至有这样一个场景，用户两个手机像握手一样摇一摇，就可以通信了。

2. 人员管理分配以及具体实现

我们软件工程有5+1，其中一个是临时调配过来的，对以前的代码也不是很熟悉，所以我选择分配给他比较独立的任务，而其他五个代码能力相差很大，可以这样说其中有一个人代码能力很强，代码风格也很不错，但是此人很有自己的特点，对任何事物欲望不是很强烈，而且比较独立，所以很难改变他的想法或者激励他干什么事情，平常开会时候精神状态也不是很好，从此看出，他对这个任务不是很喜爱。 其他四人代码能力平平， 对c#也是刚刚入门，在alpha版本出现了一个很不好的现象就是那个人能力超强，基本上把所有代码都写了。 其他人的代码贡献率很低。为了排除这个现象，同时保证确保整体的代码质量，我决定前期把所有人的任务分配的差不多，那个代码能力很强人的负责底层代码的构建，其他人负责没有涉及构架代码的其他模块，而且也保证了每个人的代码分配，最后一旦其他人的代码完成了，可以把重心都转移到整合和框架的扩充上面。

事实证明这个方法挺好的，确实保证了整体的良好代码风格和质量，但是问题也相继出现，我们没有分很详细的task，没有很详细的时间，是一个模块一个模块的分给他们每个人，因此每个人的进度不好确保，不好量化，因此不好估计他们的工作。

我们又想了想，发现如果我们继续走一步，把每个人的模块化工作也量化好，尤其是底层框架那个大骨头也能量化好，这样的效率应该更高一点。

作为PM我又考虑到我们队员的整体代码能力不强，所以我把时间节点调的非常密集，共有两周的任务，我基本上都放在了第一周完成，虽说当时我们的一周没完成，但是至少保证了两周之内完成了。给我们很多预留了时间保证了我们的工作进度。

这一点挺不错的。所以趁着大家的热情，把主要任务放在前面，把时间压缩，能有效保证我们开发进度。

3. 代码质量

虽说我们团队有一个人代码质量很好，但是他始终替代不了我们所有人，在异常处理方面是最明显的，我们很多人都没有意识，如果代码出现异常怎么办？如果解析不成功怎么办？ 但是经过后期的bug 修复，以及test 整体的代码还是挺强健。

代码质量其实是需要tester来进行监督的，可能是前期我们的tester充当dev的缘故，后期的tester 做的并不是很到位，很多情况下都是PM催着他们，有时是一遍遍催。可能我并没有很大调动他们的积极性，或者项目到了后期，大家的热情降低导致战斗力下降。

这方面，PM要加强tester的作战能力，调动他们的热情，比如聊天，或者物质奖励之外， 还应该监督tester有一个规范和严格的检测标准。

4. 团队的合作和效率

经过alpha版本的团队合作训练，我们总体的合作还是挺好的，有什么问题确实做到了即时报告PM，但是效率这方面还是有点欠缺，最主要因素是我们的代码实现能力还是有所欠缺，很多情况下是我们有一些想法，但是限于代码的实现有时候不得不折中或者妥协。但凡是都有第一次，相信我们的代码能力会越来越强，以后效率会越来越高。

5. PM协调

此次软件工程，说实话PM干的活挺多，既充当传统的PM角色，还揽有一个dev的活，这样的PM好么?

其实这样的PM不好

因为PM其实不是每天写些博客，监督下队员的进度就行了的，也不是认为你PM写代码就牛逼了，牛更加调动队员的积极性了的。

其实PM的核心在于想法，在于沟通，在于防微杜渐，在于保证进度，在于确保团队的方向，在于协调领导和用户需求。在于决策下一步该怎么走？走的好不好？在于观察队员们的战斗力，时不时给他们打打气，给他们聊聊天，看看他们的问题，看看他们的需求，第一时间解决。

而这次的PM充其量就是苦力，就是苦力鼓励机，PM用自己的时间和热情想鼓励大家，其实这样的鼓励是不持久的，是短暂的。

而事实证明也是这样的，即时现在我再苦力，在用心，他们的激情并没有很好的被调动，甚至现在的队员有时一动不动。

如果重新开始，PM会选择做好用户调查，提供更多简洁的设计，果断做些决策，加强PM的影响力和感染力。

分析每个队员的特点，并针对每个队员进行疏通，进行交流。

6. 总结

其实我们的软件不是一个完整的软件，是一个在学术搜索平台上搭建的一个新的应用，没有独立性， 很多想法受束，这也可能是我们队员后期激情不是很高涨的原因，另一个方面是我们的软件用户使用人群虽说很明确，但挺少，而且还面临着这样一个问题，要得到Host的支持和推广。

虽说路途有些纠结，但是既然是PM ，我就要站出来，为我们的努力说话，为我们的软件上线做出更多努力，更多推广，要让队员们看到即使前面的路有些艰难，我们仍会坚定地走下去。