提问回顾与个人总结

提问回顾

旧的问题

Q.文档这个东西在软件工程里到底是个什么地位？

这个问题是我在第二次阅读作业中提出的。当时我给出了一个比较明确的答复————首位。这个答案在本学期的几次实践中得到了更好的验证。
有几个笑话说的好。

程序员最讨厌的两件事：别人的工程没文档没注释；写文档写注释。
“用一句话让我全心全意跟你合作”“我会写文档”
不论是设计文档、前后端接口文档等等，这些都是让别人充分了解自己项目的最好方式。
我在之前的博客中说过：
文档分为很多：设计文档、使用文档等等。不同的文档给不同的人看，设计文档给程序员和PM看，使用文档给客户看...文档几乎可以说是除了交流之外的最重要的沟通方式了。而由于会出现功能过多，地点不允许等等情况，交流变得不太方便时，文档就显得极为重要。

我认为这里可以更正一下：文档比交流更加重要。
在项目中，交流一般用来交换想法、决定任务分配等等。而文档更加具体，将所有的事情具体化（比如哪个人分配什么任务需要多少时间、封面的设计布局按钮在某某像素位置）。
写文档如同写文章，事无巨细都记录下来并不是一件容易的事。把“开始按钮左移一点”转化为“开始按钮向左移动20px”需要非常多的精力；把想法转化为设计说明书同样很有挑战。将所想转化为文字是一门技巧，这种技巧让文档的地位始终占据龙头。

Q.到底什么样的功能才有必要实现？

这个问题由当了两个月PM的我来回答再合适不过了。
一个功能是否需要实现，很大程度上取决于用户是否需要。这里引用提出这个问题时同样的例子：

说到商用软件和爱好者写的程序的区别，我们还可以看看这个例子：

如果一架民用飞机上有一个功能，用户使用它的概率是百万分之一，你还要做这个功能么？你会选择：

根本不考虑
如果没时间实现这个功能就算了
做了，但是不用告诉用户
做了，而且不厌其烦地告诉用户如何使用
你会如何选择呢？选择之后，这个功能究竟是什么呢？
对于这样的选择，如果说选1.2或3，那请考虑飞机的安全功能。

我在之前的博客中说这个例子并不好，他并没有强调这个百万分之一功能的重要性。而现在“重要性”其实就体现在了“用户是否需要”这一点。

两个月的团队开发，作为PM的我几乎定夺了所有功能的取舍，但我决定的依据几乎没有变化：这个功能用户需不需要？

“是否需要”这个标准比较宽泛，更加具体的是：是否让用户能感到产品的完整性？是否能够让用户体验提升？
其实甲方、用户有些时候也并不知道他们需要什么样的功能。所以PM不仅需要对已有的需求定夺和具体化、还需要尽力将藏在用户内心的需求挖掘出来。

当然除了“是否需要”这个依据，资源也是一个比较重要的标准：时间是否允许、开发人手是否够等等。在有限的资源和工期内，这些也是需要考虑的。
或许我们可以将产品的cost和effect列出来，然后再来决定。

其他的一些问题我的理解其实并没有太多改变，我认为一学期的时间让我更加确定了我的理解。

新的问题

场景测试和直接使用产品来测试的区别？

我认为这两者好像不太有区别，或许就是一件事的两个“马甲”？
场景测试是构想许多常见的场景；使用产品可能会有许多其他的误操作等。
我很想知道场景测试包不包括“反复点赞”、“快速刷新”等等。

做中学

需求

• 印象最深的就是NABCD原则了。"Need Approach Benefit Competitor Delivery"。在这之前我很难想象一个产品需要从这几个角度来分析需求。而这样的分析能够为整个项目打下框架、为后续开发理清思路。

设计

• 在Beta阶段我做的是前端的设计工作。我自己补充了不少交互设计上的知识。
• 圆角设计比直角设计更加温和；设计一个页面的元素时，要考虑用户从哪个页面来、要到哪个页面去、在这个页面停留是为了什么；配色尽量统一和谐……

实现

• 结对编程阶段，软链接和硬链接的实现。
• 前端vue框架的编写，在开发前端时，对于html、js和css这三剑客更加熟悉了。

测试

• 结对编程阶段的单元测试。为了完成高覆盖的单元测试，需要进行大量的场景构想。
• 一说到场景构想，也就不得不提到场景测试。从用户的角度出发使用软件，相比于单元测试和压力测试，他更能全面的测试软件的功能。
• 当然如果遇到了一些极端的场景，那么就应该算是压力测试了。同时，我还学会了使用siege和Jmeter对服务器的接口进行压力测试。

发布

• 宣传需要把握好用户心理：什么时候用户愿意使用软件？哪些用户愿意使用软件？什么样的文案吸引用户？
• 宣传的方式可以多种多样。除了文案，可以用宣传动画和视频辅助宣传，这样的效果更好。

维护

• 小心数据库被黑，注意权限的管理。虽然我们的项目并没有出现这样的情况，但是我身边的同学有。
• 建立用户反馈群，让用户及时反馈问题。

心得体会

个人项目

个人项目的感想大多都在三篇博客：软工个人阅读作业一、软工第二次阅读作业、软工案例分析中。其实这个阶段更多的是“体验”、“感受”和“思考”软件工程。

结对编程

关于结对编程，该说的也都写到了博客里：结对编程第一周总结、结对编程第二周总结、结对编程总结
引一段话吧，正好合适：

接着实践总结部分的最后，我想来谈一谈结对编程任务。
首先，毋庸置疑的是，这两周的经历让我收获非常多。收获不仅在于代码，设计层面的知识，更是在合作，交流的层面。知识固然重要，但学习别人的优点，与优秀的人交谈，领会他们的思维和思想，更是一件幸福的事。我不仅从我的队友身上学到了很多，我还有机会通过博客的方式，与大佬们进行交流。本人代码能力并不强，身边优秀的同学思考得还比我更加深入，我深感惭愧。当然，这也会不断激励着我变得更好。

团队项目

首先我要特别感谢我的几位非常给力的队友！后端的大腿dxy，讨论积极十分有想法的lmx，前端大腿hsw，勤勤恳恳的djj。是我们所有人的努力才让整个AIApe问答机器人能够在最后完整地展现出来。
先不说这个产品的好坏和定位。我认为我们组选择这个题目就是非常有挑战性的：机器人+用户问答社区。我认为两个都可以单独拿出来当做一个项目进行开展。
但这两个元素其实是密不可分的，机器人不能做到面面俱到、而问答社区又显得有些冰冷，社区质量不高。再加上我们组只有5名劳动力，所以开发整个项目是非常吃力的。
遗憾的是，软件最后的得分并不取决于他的开发难度，而是取决的他的开发结果。我们的结果其实并不理想，但我们已经尽力而为，问心无愧了。
跟其他组一样，我们也有通宵，也有紧锣密鼓的开发阶段，也有对于产品定位的迷茫。作为PM的我能够深切感受到组内所有人的压力和紧迫感。但是作为PM，作为小组中的一员，我必须为组员负责，为产品负责。所以及时我对后端的.NET框架并不熟悉，我也看了大部分后端的代码；在Beta阶段，我也加入到了前端的设计和开发当中。
最后的产品一定的不完美的，有缺陷的。即使很多评委为我们的组打了低分，但看到任何一个表扬，我都认为是我们的努力得到了肯定！
尽力而为，问心无愧！