[I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	软件工程
这个作业的要求在哪里	个人作业：阅读和提问
我在这个课程的目标是	掌握软件工程的核心理论，协作完成软件项目开发
这个作业在哪个具体方面帮助我实现目标	通过阅读《构建之法：现代软件工程》提前思考项目协作中可能遇到的问题，更清楚软件项目开发流程

阅读提问

Q1：MVP方法在什么情况下具有实际可行性？

从2009年开始，一些互联网产品团队在试验MVP方法：MVP——MinimalViable Product，最小可行产品，又称为MinimalFeature Set，最小功能集。具体的做法是：把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。例如，一个社交网站已经有很多用户，都是免费的，产品团队想设计一个付费的VIP服务，MVP的做法可以是这样——在目前的用户入口页面中加一个“VIP服务”的链接，指向一个简单的介绍页面（用最小成本做出来）。观察到底有多少用户点击这个链接。如果点击量太小，那么这个VIP服务就不用做了。

在5.3.6节中提到MVP方法，把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见。对于这个方法和他举出的例子我有一些不认同的地方。

通过观察用户点击连接的次数来判断VIP服务是否有完成的必要是缺少逻辑支撑的。用户点击VIP服务的连接可能是出于好奇的心理去尝试，但实际上的体验结果以及是否愿意为此付款都是未知的。同理，VIP服务一般对应着会进行付费，一部分认为已有功能已经足够的用户根本不会去点击链接。所以，点击了的用户不一定认为这个服务是有必要的，没点击的用户不一定认为这个服务对他们没有帮助，通过点击量去判断不能达到快速征求用户体验的目的。

MVP方法仅仅把产品最核心的功能用最小的成本实现出来。用户在实际使用时是没有办法使用时仅仅关注一个最核心功能，而忽略其他的使用感受的，较为简陋的功能会导致用户体验感不好，从而认为这个功能是没有必要的。在这种情况下，征求得到的用户意见还具有多少程度上的参考性？

Q2：非功能性需求的优先级判断标准是什么？

非功能性需求：这也叫“服务质量需求”（Quality of Service Requirement），例如，股票交易系统必须在一定时间内返回用户查询结果（它对时间的要求要比“科技文献检索”网站要高），火车票购票系统、大学选课软件必须能支持一定数量的用户同时访问，等等。

在8.1节中对软件的需求提到了非功能性需求，但却没有说明在实际使用中我们该如何判断非功能性需求的优先级。

例如，在实际系统开发中，我们往往会遇到 “响应速度”“并发支持”“数据安全性” 三个非功能性需求冲突。优化并发会导致响应速度下降，强化安全防护又会增加开发成本。当多个非功能性需求相互矛盾时，作为开发者，我们是应该优先满足用户最直观的 “响应速度”，还是提高多名用户同时使用时的”并发支持“？

Q3：我们应该如何平衡创新与调研之间的矛盾？

我们要充分了解用户的痛苦，他们对已有软件、服务不满意的地方。但是用户往往也不了解颠覆型的创新。例如，亨利·福特是汽车行业的先驱，如果他深入用户（马车夫），征询他们的需求，马车夫会告诉他：我希望我的马跑得更快一些！

在8.3节中，作者列举了焦点小组、深入面谈、调查问卷等多种用户调研方法。而在第8.4节中，又指出很多创新需求并非用户直接提出，而是技术突破带来的。

做调研似乎只能得到渐进式改进的点子，而真正的颠覆性创新，例如第一代iPhone，似乎更多源于产品团队的洞察和远见。当我们想要进行创新，而非在市场的基础上进行优化时，我们该如何进行需求分析，此时用户并不一定能完全想象到实际的使用场景，例如之前我们一直进行实体店购物，若有人提出网店的形式，可能会得到并不方便我们试衣服，退货很麻烦等理由。但实际上是，现在网络购物成了主流形式，对实体店的运营造成了巨大的打击。

当我们进行创新时，用户调研具有多大的参考意见？团队该如何避免闭门造车的同时还避免被现有认知束缚？我们如何平衡用户调研和产品愿景之间的矛盾？

Q4：怎样动态调整产品功能的四个象限？

杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等。外围功能：良好的界面设计，在各个平台上都能运行。

必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）。

辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）。

这四个象限能让软件团队清楚地看到自己感兴趣的功能处于什么地位，有了这些分析，我们就可以决定怎么处理不同类型的功能。重要的是，不要把资源平摊到所有象限中，而是倾斜到可以产生差异化和独特用户价值的地方。

在8.5节中，作者提出了用四个象限来分析产品功能，并建议对不同的象限采取不同的策略。

但是在实际使用中，功能在四个象限中的位置并不是一成不变的。例如，某个功能一开始是杀手功能，但随着竞争对手的跟进，它逐渐变成了外围功能甚至必要需求。又或者，某个辅助需求可能因为用户习惯的改变而变得至关重要。

在项目的发展过程中，团队应该如何定期重新审视和调整功能的象限定位？当一个曾经的杀手功能变成必要需求时，我们是应该继续投入资源优化它，还是只需要维持它，而把资源转向寻找新的杀手功能呢？

Q5：定义典型用户和场景是否容易变成一种形式主义的练习？

那么，什么是典型用户？在产品开发的过程中，我们经常需要描述一组典型的用户。以前大家通常是以一些抽象的名词来表示用户，如“家用电脑初学者”、“经验丰富的系统管理员”，现在我们建议用一个“典型用户”来代表。典型用户不再是一个抽象的概念，而应该是一个活生生的人物。典型用户一般有哪些特性？一个典型用户往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。

在10.1节中，作者通过Visual Studio和Stone网站的例子，详细展示了如何定义典型用户和场景。但是在实际定义典型用户的过程中会遇到很多困难，这些人物是虚构的，缺乏真实的数据支撑，他们的行为、动机和困难都显得很模式化。就如同”何不食肉糜“，我们也很难完全感同身受得到这些人物的具体使用感受和使用需求，用这样的人物推导出的场景和功能，似乎都只是通过想象，实际使用效果有太多的未知性了。

在没有真实用户数据的情况下，定义典型用户和场景是否容易变成一种形式主义的练习，反而限制了团队的创新思维？我们是否必须结合第8章中提到的深入面谈、人类学调查等方法，才能让典型用户更真实，发挥其应有的价值吗？

Q6：图形建模工作是否真的必要？

在11.2节中，作者介绍了ER图、DFD、UML等多种图形化建模工具，并引用了Joshua Bloch和Peter Norvig等人对这些工具的不同看法。

畅销书Effective Java的作者JoshuaBloch对于“你用过UML设计工具么？”的回答是：“没有。能把设计画成图，让别人理解当然很好。但是说实话我真的记不起来哪些模块应该是圆形，哪些是方形。”谷歌研究院的院长PeterNorvig被问及同样问题的时候说：“我从来不喜欢UML类型的工具，如果你不能通过计算机语言表达（UML要表达的东西），那就是这种语言的弱点。”像任何新技术一样，以UML为代表的图形化分析方法的确解决了不少实际问题，但是也引发了一些误解、误用、狂热和“银弹”的信仰。UML的设计者和推动者之一Grady Booch说到：在UML出现之前和之后，软件项目成功的关键依然是——智慧地使用技术、遵从一个好的软件开发过程、有经验的开发者、和适当的技能组合。

在以往的课程项目中，我们被要求画UML图，但很多时候是为了画图而画图，代码写完之后再反过来补图。这些图除了应付作业，对实际的编码和沟通帮助不大，团队成员更愿意直接看代码或口头讨论。

对于中小型项目或敏捷团队，这些繁重的图形建模工作是否真的必要？我们学习这些工具，是为了掌握一种建模思维，还是为了能读懂别人的设计文档？