读后感想

第一章

  在第四页的地方，我看到这样一句话：“2010年，中国还出过了一桩怪事：A公司要挟用户必须卸载B公司的软件，然后A公司的软件才能运行。”在大部分人看来，这样的做法有点过分，两个公司之间的竞争就应该是光明正大的，用这样的方法强迫别人用自己的软件未免有些不择手段。

  与此同时，我也产生了一个疑问，作为一个开发的团队，有着很好的能力是再正常不过的事情，但是不管是一个有多少人的团队，他们也不能保持时刻都有创新性的点子，我认为他们大部分还是做着其他团队正在做的或是已经做完的项目。或许有人说不同的团队做出来的项目有着大同小异的地方，在很多小的细节上还是有不同之处的。但是，我作为一个用户，以及从身边和网络上了解到，很多用户其实并会用到那些差异点，他们往往用的都是共同点。仔细一想，这也很好理解，不同的团队肯定还想要做的和其他人不一样，但同时他们还是选择保留这些共同点，那就说明这些共同点才是用户们真正想要的东西，其他功能其实可有可无。

  所以，我就很想知道，假如不同的公司开发出了两个相似的软件，他们是如何让更多的人去使用。是抱着反正不是用你的就是用我的心态在拥有和另一个公司差不多相同的用户中寻求一个和那个公司的平衡点，以等待一个有创新性点子的时候再战胜他们。还是就像文中那样用一些其他的手段。又或者是就专注于这个相似的软件上面，以求把这个软件做到完美，通过一个平淡但又完美的软件去吸引用户。

第二章

  “psp的目的是记录工程师如何实现需求的效率，而不是记录顾客对产品的的满意度。工程师有可能很高效地开发出一个顾客不喜欢的软件（例如用户界面很差，功能未能解决用户实际问题，等等），那么这位工程师还是一个优秀的工程师么？”这句话位于第36页。当我看到这句话时，我就会不由的想到我以后应该怎么做，如果我作为一个软件工程师，我当然希望自己是优秀的。在之前我都是认为只要我把我接到的项目在很短的时间内做到几乎没有错误我可能就会觉得我是一个比较优秀的软件工程师了，但书中的这句话也点明了，软件工程师所做的软件最后都是要面向用户的。所以说，如果想要一个软件真正的有价值还是要看用户的满意度，那么一个工程师是否优秀好像还要依赖于这一点，但是psp测试团队能力时并不要求满意度，仅仅是看实现需求的效率，难道一个团队只要满足效率这个要求就同样具备提高用户满意度的能力吗？还是说根本就不在乎用户满意度？

第十六章

  看完这一章，我满脑子都是创新两个字。在现在的社会，不仅是软件这个行业需要创新，其他任何行业都需要。创新不是一蹴而就，这需要前人给出足够的铺垫，就像生物的进化一样，想要样子我们现在样子需要很多年的进化。从古至今，所有人都在努力创新，有好多考古学家就发现古代人有好多创新点都是我们现在的技术，但是当时却没有实现，就是因为当时的科技并没有到达实现他们的创新的能力。这章的内容不像前几章，没有给我带来那么多疑问，而是给我很多的感悟。在这个寻求创新的年代，我知道了不应该一味的去寻求找创新点，首先要提高自身的能力，让自己有实施创新点的资本。