mod

极客时间专栏/软件工程之美/需求分析篇/17 | 需求分析到底要分析什么？怎么分析？.md

@@ -0,0 +1,227 @@
+<audio id="audio" title="17 | 需求分析到底要分析什么？怎么分析？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/df/27/dfe3040c9e5c4cec65635f4b439b1927.mp3"></audio>
+
+你好，我是宝玉，我今天想与你分享的主题是“需求分析”。
+
+通过前面的学习，我们知道在瀑布模型中，第二个阶段就是需求分析阶段，同时需求分析的结果也决定了后续的系统设计、开发、测试等阶段能否顺利如期进行。即使是用敏捷开发，同样也少不了对需求的分析整理。
+
+可以说需求就是整个产品的源头，所以需求分析的结果往往决定了产品的成败。如果没有正确把握客户需求，可能就会一步错，步步错！
+
+就像我在《[特别放送 | 从软件工程的角度解读任正非的新年公开信](http://time.geekbang.org/column/article/82255)》提到的秋千的案例：
+
+> 
+客户想要一个给三个孩子玩的秋千；产品经理以为就是一个板子加两绳子就行；架构师发现除非把树截开，否则秋千没法荡起来的；程序员以为用绳子和板子连一起就完事了；而真正满足客户需求的，也就只要在绳子上挂个轮胎而已！
+
+
+<img src="https://static001.geekbang.org/resource/image/2a/70/2a196741845cc6533716f7ff66fa3c70.jpg" alt="">
+
+所以在本篇文章中，我将带你去了解：需求分析到底要分析什么？以及我们怎么样才能做好需求分析，抓住用户的真实需求，做出来客户想要的软件产品，避免失败或浪费。
+
+## 什么是需求？
+
+我们日常在项目中，经常会听到“需求”这个词，比如说：
+
+- 项目经理对产品经理说：用户给我们提了一个需求，想要一个给三个孩子玩的秋千，你分析一下；
+- 产品经理对架构师说：我们现在有一个需求，在树上拴两绳子，再吊一块板子，你做一下设计。
+
+很明显，这两个需求的意思不一样，**前面这个需求是用户需求，后面这个需求是产品需求。**
+
+用户需求是由用户提出来的，期望满足自身一定需要的要求，例如用户说：“想要一个给三个孩子玩的秋千。”这种原始的用户需求通常是不能直接做成产品的，需要对其进行分析提炼，最终形成产品需求。
+
+产品需求就是在分析提炼用户真实需求后，提出的符合产品定位的解决方案。就像上面“在树上栓两绳子，再吊一块板子”，就是产品经理针对用户需求提出的解决方案。
+
+## 需求分析是要分析什么？
+
+其实对用户需求的分析，不是一个动作，而是一个过程。需求分析，就是对用户需求进行提炼分析，最终形成产品需求的过程。
+
+而针对每个用户需求的需求分析过程，需要经过三个步骤。
+
+**第一步：挖掘真实需求**
+
+大部分用户提的需求，都不见得是其真实的需求，需要透过现象看本质，去挖掘其背后真实的需求。就像福特汽车创始人亨利福特说过的：
+
+> 
+如果我最初是问消费者他们想要什么，他们应该是会告诉我，“要一辆更快的马车！”
+
+
+这里“要一辆更快的马车”就是一个典型的用户需求，但这并非是用户的真实需求，用户的真实需求，需要通过分析才能得到。
+
+要分析用户的真实需求，可以从三个角度入手。
+
+1. 目标用户：用户不同，诉求也不一样；
+1. 使用场景：使用场景不一样，解决方案也会有所不同；
+1. 想要解决的问题：用户背后想要解决的问题是什么。
+
+我们假设目标用户是普通乘客，使用场景是日常出行，那么用户想要解决的问题其实并不简单是“要一辆更快的马车”，想要更快的马车只是用户自己能想到的解决方案，而他想解决的问题是“更快更舒适的出行方式”。
+
+而现实项目中，大多数人需求分析的不正确，就是因为没有挖掘出用户的真实需求。
+
+我们再看之前的秋千项目，目标用户是三个孩子，使用场景是一起户外玩耍，想解决的问题其实是能有一起玩的娱乐设施。
+
+**第二步：提出解决方案**
+
+我们知道了目标用户，其使用场景和想要解决的问题，就可以结合产品定位，提出相应的解决方案。
+
+比如针对想要“更快更舒适的出行方式”日常出行的乘客，我们就可以提出汽车的解决方案，而不一定要局限于马车，汽车能更好的满足用户需求。
+
+针对三个孩子想有一个在户外一起玩的娱乐设施这个需求，我们可以提供一个轮胎式的秋千，就可以很好的满足他们的需求，我们甚至可以建一个小型游乐园。
+
+**第三步：筛选和验证方案**
+
+在提出方案后，我们需要对方案进行筛选，比如对于秋千项目，建小型游乐园的方案虽然能满足需求，但是成本太高，需要排除掉。
+
+在选好方案后，还需要对方案进行验证，以确保方案能解决用户需求。
+
+在传统瀑布模型中，选定方案后，会写成产品设计文档，走相应的评审流程，评审完成后再进行设计、开发和测试，测试完成后会让客户再进行验收。而敏捷开发，在整个开发过程中，每个迭代或者关键的里程碑，也一样需要客户进行验收。
+
+通过以上三步，就可以对用户需求进行提炼分析，最终形成产品需求。
+
+所以在需求分析过程中，分析的就是一个个用户的需求，找出背后的真实诉求，再有针对性的提出解决方案。
+
+对于解决方案，要进行筛选和验证，有些不可行的用户需求不会变成产品需求，可行的用户需求会按照优先级进入实施阶段，最终变成产品。
+
+## 怎样做需求分析？
+
+前面我介绍了对单个用户需求的分析，主要经过三个步骤：
+
+- 第一步：挖掘真实需求；
+- 第二步：提出解决方案；
+- 第三步：筛选和验证方案。
+
+而软件项目的用户需求，从来就不是单一的，而是一系列需求，所以对于软件项目的需求分析，还需要增加收集整理的步骤。整个过程是迭代进行的，如下所示：
+
+- 收集需求：对用户需求进行收集整理；
+- 分析需求：对需求进行分析，挖掘用户真实需求；
+- 需求评估：筛选过滤掉不可行的需求；
+- 需求设计：针对用户需求提出解决方案，设计成产品方案；
+- 验证需求：验证方案是否可行。
+
+<img src="https://static001.geekbang.org/resource/image/b4/76/b4f5e9676ed215c1d80da73a15281776.jpg" alt=""><br>
+我在美国DePaul大学读书的时候，曾在学校兼职，当时接到一个项目，要为计算机学院的网络教学系统做一个网页版的播放器。
+
+我们知道现在的课堂里面，老师上课的时候，会用电脑放PPT或者课件，同时还要在黑板（也有的是白板）上写写画画辅助说明。
+
+DePaul大学的网络教学系统，就是在老师上课的时候，用摄像头把老师讲课的整个过程都录制成视频，同时也会用特殊的软件，把当时电脑屏幕上显示的内容，和白板上写的内容，都录制下来。
+
+这样选网络课程的同学可以通过网络直接观看，既不会漏了老师讲的内容，也不会错过老师在电脑上放的和白板上书写的内容。播放器要做的就是要播放录制的教学视频、电脑屏幕和白板。
+
+我将以这个项目为例，讲讲如何做需求分析。
+
+**1.收集需求**
+
+这个项目的原始需求是老师给我的，只是告诉我要做这样一个播放器，让学生能看教学内容。而这个需求还不够，我还需要继续收集用户需求。
+
+收集用户需求有很多方法，这里列举部分：
+
+- 头脑风暴：就是大家一起开会头脑风暴讨论；
+- 用户调研：通过调查问卷或者访谈，通过问用户一些问题收集反馈；
+- 竞品分析：通过分析其他同类产品的功能获得需求；
+- 快速原型：通过原型来收集反馈，收集确认需求。
+
+拿播放器的项目来说，头脑风暴没有足够的项目成员，也没有同类产品可以做竞品分析，做原型的话，成本有点高，所以用户调研就是最适合的收集需求的方法。它不仅简单，而且能收集到真实的用户反馈。于是我通过微信群、邮件、用户访谈从老师、领导和学生那分别收集了一些反馈。
+
+老师们没有什么有效反馈，因为他们基本不需要用到这个软件，领导们有个需求就是希望能播放字幕，而很多学生希望能有2倍速快进功能。
+
+**2.分析需求**
+
+收集了需求，就要分析用户的真实需求，这是最难的部分，也是最体现产品经理需求分析水平的地方。
+
+用户需求背后的真实需求有三个层次：
+
+- 表层需求：用户对解决问题的期望，例如马车更快；
+- 深层需求：用户的深层次动机，诉求产生的原因，例如乘客对出行速度的要求；
+- 底层需求：人性本能的需求，例如对安全感对舒适的追求。
+
+要分析好用户需求背后的真实需求，就是要结合“目标用户”和“使用场景”，按照上面三个层次去思考。
+
+我们拿刚才播放器为例，目标用户是学生，使用场景是学校机房或者家里，希望解决以下问题。
+
+字幕的问题：
+
+- 表层需求：显示字幕；
+- 深层需求：语言不好，跟不上老师节奏；
+- 底层需求：聋哑学生无法听到声音，只能通过字幕学习。
+
+快进的问题：
+
+- 表层需求：能快进播放；
+- 深层需求：可以节约学习的时间，提高效率；
+- 底层需求：取得好的学习成绩
+
+经过这么一分析，基本上就对于用户的真实需求心里有数了。
+
+**3.需求评估**
+
+需求收集分析完了后，还需要进一步评估，以决定做还是不做，优先级如何，先做哪些再做哪些。
+
+需求评估考虑的因素有：
+
+- 可行性：技术能否实现；
+- 成本：人力成本、时间成本；
+- 商业风险和收益：有没有商业上的风险，收益是否合理；
+- 紧急性与重要性：是不是用户迫切的需求。
+
+如果确定可行，还需要评估其优先级。评估优先级一个简单的方案就是用“紧急重要四象限”的方法来区分：
+
+<img src="https://static001.geekbang.org/resource/image/43/d8/43965aae9c1a2f294fb5664731e9cdd8.jpg" alt="">
+
+复杂一点的有KANO模型，如下图所示。
+
+<img src="https://static001.geekbang.org/resource/image/71/7f/71cb6e674f8b633be802a02c2e616d7f.jpg" alt="">
+
+- 红色曲线，是用户认为必须要有的功能；
+- 绿色曲线，就是用户明确提出的需求；
+- 黄色曲线，属于兴奋型需求，就是用户自己没想到，超出预期的功能。
+
+回到我们播放器的例子：
+
+- 红色曲线（必须要有的功能）：能播放视频、播放电脑屏幕，播放白板；
+- 绿色曲线（用户明确提出的功能）：字幕、2倍速快进；
+- 黄色曲线（超出预期功能）：10秒快进、10秒快退、在时间轴上记录笔记。
+
+**4.需求设计**
+
+在分析和评估完需求后，还需要提出解决方案，也就是对需求进行设计，做出来有效的产品设计方案。最终的产品设计，会落实到人机交互上面，用户可以通过软件界面交互。
+
+现在产品设计方面，各个平台都有一套比较成熟的界面标准控件，大部分产品设计都可以基于标准界面控件，组合成满足需求的用户界面，在满足功能的前提尽可能做得易用和美观。
+
+在需求设计的时候，可以用草图、原型设计工具、界面设计工具进行设计。
+
+在需求设计阶段，可以参考其他成熟的产品。比如我在设计播放器时，也是通过借鉴其他软件的设计来完成的，比如说向Youtube借鉴了视频播放器的设计，向Skype的电话会议系统借鉴了其播放区域切换的交互，最终完成了产品设计。
+
+<img src="https://static001.geekbang.org/resource/image/a2/77/a2c1d84a3422cf77bd2a903303249977.png" alt="">
+
+**5.验证需求**
+
+在需求设计好后，还需要进行验证，看解决方案是否能满足用户的需求。
+
+对需求的验证方式其实是贯穿整个软件项目生命周期的，在需求分析阶段，会反复验证确认设计好的需求是否满足用户的真实需求，例如各种设计评审。
+
+在产品开发完成后，也需要有需求的验收，以确保开发出来的软件产品是客户想要的，满足客户需求的。
+
+现在很多互联网产品，还有一种基于数据的验证需求方式，也就是A/B测试。
+
+设计好一个功能上线后，并不直接让所有用户使用，而是先给一小部分用户使用，然后分析数据，看使用这个功能的用户群和不使用这个功能的用户群，在营收、访问量、活跃度等关键数据上是更好还是更坏。如果好，就加大比例，如果数据不好，可能就会调整甚至取消这个功能。
+
+我在设计播放器的时候，首先用PPT做了一个简单的草图，拿去给老师确认，收集一些反馈后，写了一个PC版的软件原型，拿给一部分同学试用。在收集反馈后，做了一些修改和调整，最终确认了产品的设计。
+
+<img src="https://static001.geekbang.org/resource/image/96/f1/96ffb31d8373ed35bbfc3ea66e4011f1.png" alt="">
+
+在需求分析完成后，就可以基于需求分析形成的文档，进行设计和开发了。（[DePaul大学的网络教学系统产品演示](http://courseonline.cdm.depaul.edu/html5player/?lectureid=89646)）
+
+## 总结
+
+今天带你一起学习了软件工程中一个非常重要的知识点：需求分析。
+
+需求分析，就是一个将用户需求变成产品需求的过程。要做好用户需求的分析，需要找出来隐藏在用户需求背后的真实需求，还要针对用户的真实需求提出解决方案，最终验证方案是不是能满足好用户需求。
+
+需求是整个产品的源头，很多软件项目失败的原因就在于没有做好需求分析，软件中很多浪费也来源于需求没想清楚导致的返工。做好需求分析对于软件项目来说非常的重要。
+
+要做好软件项目的需求分析，需要做好需求的收集整理工作，然后对收集好的需求进行科学的分析，评估是不是可行以及划分优先级，对可行的需求项进行设计，最后还要验证设计出来的结果是不是满足需求。
+
+希望你通过这节课的学习，能科学地运用好需求分析的知识，对项目的需求分析把好关，保证最终产品能满足用户需求，超出用户预期。
+
+## 课后思考
+
+你工作中有没有遇到因为需求分析没做好导致项目失败的案例？你了解AB测试吗，有在项目中用过AB测试吗？极客时间的课程为什么要支持音频？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/需求分析篇/18 | 原型设计：如何用最小的代价完成产品特性？.md

@@ -0,0 +1,202 @@
+<audio id="audio" title="18 | 原型设计：如何用最小的代价完成产品特性？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/29/38/29168c346cc31516fcfb2cdd87e32538.mp3"></audio>
+
+你好，我是宝玉，我今天想与你分享的主题是“原型设计”。
+
+我们都知道，软件项目中很多问题都和需求相关，比如说需求不明确，需求变更。这些问题轻则导致返工造成浪费，重则导致项目失败带来巨大损失。所以在软件工程中，搞明白需求是一件至关重要的事。
+
+上一篇我带你学习了如何分析需求的方法，而分析需求，同样也离不开工具的支持。所以这一篇，我将带你学习需求分析中原型设计的用法，借助原型设计，用最小的代价完成产品特性。
+
+## 什么是原型设计？
+
+对于原型设计，很多程序员可能比较陌生，但是对于产品经理来说，原型设计却是日常工作中最常用的技能之一。因为原型设计，是产品经理确认需求、设计产品最重要的沟通工具。
+
+其实最早的原型设计，并不是作为一个需求沟通工具存在的。
+
+## 原型设计的发展历史
+
+早在上世纪70年代，在瀑布模型提出后，很大程度上改进了软件项目的开发。但是需求不明确、需求多变的问题从那时候开始就是一大难题。
+
+《人月神话》的作者弗雷德里克·布鲁克斯（Frederick P. Brooks, Jr.）在《没有银弹-软件工程中的根本和次要问题》中第一次提出了：“在获取和制订软件需求时，将快速原型开发作为迭代计划的一部分”。
+
+后来快速原型就逐步发展成为一个开发模型，叫快速原型模型，我在《[04 | 瀑布模型之外，还有哪些开发模型？](http://time.geekbang.org/column/article/84054)》这一篇里也有介绍。这种模型的特点就是快速开发，快速修改。目的是为了解决客户的需求不明确和需求多变的问题。
+
+**注意，这里的快速原型模型，是开发软件项目的一种模式，还不是工具。**
+
+给你举个例子，如果用快速原型模型开发网站，大概分三个阶段。
+
+第一个阶段就是纯静态HTML页面，能看到页面什么样子，没有后台，无法保存数据。这种静态页面开发成本不高，速度很快，改起来也方便，做好了就可以拿去跟客户确认需求。
+
+客户看了后就能知道产品长什么样子，是不是满足要求，会提出明确的反馈意见。根据反馈，开发方会继续修改静态页面。
+
+第二个阶段就是模拟一个后台服务，没有数据库，数据直接保存内存中。但是可以让网站有真正的交互：从网站添加内容就能显示出来，修改网站内容，网站显示的内容也会跟着修改。
+
+这个阶段客户可以在网站上体验交互，也能完整的体验操作的流程，可以进一步针对交互再提出反馈，开发方根据反馈继续修改。
+
+第三个阶段就是完成最终的后台服务，接入真正的数据库或者其他后台服务，完成整个网站的开发。由于前面两个阶段，产品经理已经把需求和交互确认清楚，所以这个阶段的开发，就没有太多需求上的反复和修改，可以高效的完成设计和开发。
+
+简单来说快速原型模型就是，**第一阶段确认界面布局和内容，第二阶段确认交互，第三阶段实现。**
+
+通过快速原型模型来开发，可以低成本、快速地确认好需求。但也有一个问题：**整个过程单靠产品经理是无法完成的，必须要有开发人员配合才能完成。**而对产品经理来说，要开发人员配合还是一件高成本的事情。
+
+- 低保真原型设计
+
+于是有产品经理用线框图来代替第一阶段。线框图画起来简单，纸和笔就可以，展示效果不错，通过线框图可以直观地看到界面上有什么，布局是什么样的，一样可以用来和客户确认需求。
+
+[<img src="https://static001.geekbang.org/resource/image/6a/de/6a121d4c74a1daffdf8d39833ef24bde.png" alt="" title="图片来源：WikiPedia">](http://en.wikipedia.org/wiki/Website_wireframe)
+
+线框图简单方便，可以起到沟通需求的效果。但缺点也很明显，就是看起来不够真实，不方便反映界面之间的关系，另外也不能反映界面交互。所以线框图这种模式也叫低保真原型。
+
+- 中等保真原型设计
+
+再后来就有像Axure这样专业的原型设计软件产生，不仅可以反映界面上的布局和内容，还可以展示网站的整体结构和交互。也就是说，借助原型设计工具，可以达到前面快速原型开发前两个阶段同等的效果。
+
+<img src="https://static001.geekbang.org/resource/image/00/19/00f3aa9d97f1ab7171653bcb4bcc9419.png" alt="" title="图片来源：我参与过的某项目原型设计截图">
+
+这种原型设计，可以很好的用来确认需求和界面交互，虽然制作难度上比线框图要复杂一点，但是不需要开发人员介入，产品经理完全可以自己搞定。
+
+但这样制作出来的原型，也不能做到100%真实，因为它在界面的真实度、色彩上要比最终产品差一些，所以也被称之为中等保真原型。
+
+- 高保真原型设计
+
+近些年移动端快速发展，对于移动端来说，因为界面比较小，布局和内容上已经没法玩出什么花样。所以客户更追求界面的美观和交互的炫酷，对原型的保真度要求也就越来越高。
+
+所以很多原型工具就在高保真方面狠下功夫，让你简单操作就可以做出漂亮的界面和炫酷的交互，甚至完成后都不需要再做UI设计了。
+
+当然，高保真原型的学习成本和制作成本都要高于低保真原型，所以变更成本更高，而且也很容易导致产品经理花大量时间在细节的调整上，影响整体的进度。所以通常高保真都会和低保真原型设计配合使用，先用低保真原型快速确认清楚需求，再用高保真原型确认最终的交互和UI设计。
+
+就这样，原型设计从最开始的一种快速开发模式，逐步演进成了今天的原型设计工具。让产品经理不需要会编程知识，也可以做出很酷的软件原型，从而可以低成本、高效率的确认清楚产品需求。
+
+## 怎么做好原型设计？
+
+虽然说现在原型设计工具已经让制作原型越来越简单，但即便如此，原型设计也可以算得上是一个小项目了。因为要做好原型设计，不仅要考虑单个界面怎么设计，还要考虑这个产品整体有多少个界面，各个界面的关系和流程是什么样的。
+
+要做好原型设计，可以借鉴我在《[02 | 工程思维：把每件事都当作一个项目来推进](http://time.geekbang.org/column/article/83277)》中讲的内容，用工程方法来完成。
+
+<img src="https://static001.geekbang.org/resource/image/c4/4e/c45b734291f8a36d4c3d7ed87e384e4e.jpg" alt="">
+
+参考工程方法，我们可以将每次原型设计过程分成四个部分：分析、设计、实施和验证。
+
+这里，我以极客时间App为例，假设我们需要制作一个极客时间的iPad版，应该如何制作原型呢？
+
+#### 第一步：分析
+
+在原型设计时，通常属于需求的最初阶段，需求还是很模糊、不具体的。所以这个阶段首先要做的，就是要对用户的需求有个初步的了解，分析清楚原型设计的目标是什么。
+
+比如说，我们要设计极客时间的iPad版，其实在内容上，完全可以基于iPhone版本，只是在布局上，交互要重新设计，充分发挥iPad大屏幕的优势，展现更多有价值的信息。
+
+#### 第二步：设计
+
+在对需求进行初步分析后，需要开始对原型进行整体设计。在设计阶段，主要从两个维度来考虑：
+
+1. 从信息架构的维度，考虑清楚整个产品的信息架构，划分出模块；
+1. 从使用流程的维度，考虑清楚界面之间的流程。
+
+**画产品的信息结构图**
+
+产品的信息结构，就像一本书的目录，整体描述了架构信息。
+
+在做原型设计前，先梳理清楚整体结构，有助于帮你想清楚产品有哪些功能模块，模块之间的关系如何，哪些模块是公共的，哪些模块是面向不同用户显示不同内容的。
+
+参考极客时间iPhone的结构，我们可以把主体的信息架构梳理出来，如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/1b/23/1b2705ff5e06367b51a133f016de1d23.png" alt="">
+
+在考虑清楚主体结构后，可以进一步细化。例如其中“讲堂”下面虽然分成了“专栏”、“视频课程”、“每日一课”和“微课”，但其实点进去都是一样的，我们可以称之为“课程模块”，对于课程模块，我们可以进一步细化。如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/c6/61/c6fecc876ce699fb7331d5f54238c661.png" alt="">
+
+这样你就可以一步步将整体信息结构从粗到细，一点点整理清楚。
+
+**画产品使用流程图**
+
+用户在使用产品时，会在不同的模块之间跳转，比如说你从极客时间进入到一个没订阅过的专栏，还可以点击订阅按钮进入订阅界面，订阅成功又可以返回专栏界面。
+
+所以，**需要用流程图把这些界面之间跳转的逻辑梳理清楚。**在设计流程图的时候，要重点考虑用户的使用场景，结合使用场景设计好流程。
+
+举例来说，如果当前用户进入到专栏首页，如果用户没有订阅，最重要的就是让用户可以方便的订阅，然后继续阅读；如果用户已经订阅，就没必要显示订阅相关内容，直接可以看到文章列表，选取想看的文章直接阅读。
+
+需要注意，画产品使用流程图时，不仅要考虑正常使用的流程，同时也要考虑清楚异常的情况。比如说用户留言输入错误，网络失败，怎么处理？如果把用户辛辛苦苦输入的消息弄丢了，将会让用户体验大打折扣。
+
+我们以进入专栏，阅读专栏文章这个流程为例，画一个简单的流程图，来说明各种不同情况下的流程和跳转关系。
+
+<img src="https://static001.geekbang.org/resource/image/b3/b1/b3fea691c445e12ef8bd7f10129f7eb1.png" alt=""><br>
+通过这样的流程图，可以考虑清楚界面和界面之间的跳转逻辑。
+
+#### 第三步：实施
+
+在设计好整体的信息架构和使用流程图后，就可以开始对每个界面画流程图了。
+
+在具体到界面时，**要优先考虑满足产品需求，然后是让界面好看好用。**
+
+比如说阅读专栏文章这个界面，在iPhone上，屏幕很小，显示的信息有限，到iPad上，有了更大的屏幕，就可以增加更多的内容。但是注意不能造成太多的信息干扰，要突出重点，增强体验。
+
+所以我们可以保留Tab导航的设计，让用户可以随时回到一级界面，并且针对iPad界面特点，对位置做一些针对性调整。
+
+<img src="https://static001.geekbang.org/resource/image/31/2e/31b84de7cdd2a9f751e1744f6a78372e.jpg" alt="">
+
+另外在专栏阅读时，一个常见的场景就是看完一篇后，想切换到目录查看其他文章。可以针对iPad的交互特点，点击显示目录，方便在文章之间切换跳转。
+
+<img src="https://static001.geekbang.org/resource/image/de/ad/deffb10912b51a3d206d5faa4d0948ad.jpg" alt="">
+
+这样一个界面基本上就初步完成了。接下来还可以对一些可以点击的界面元素，例如按钮，增加跳转操作，按照前面产品使用流程图的设计，将界面之间连接起来，让用户可以方便的从一个界面跳转到另一个界面。
+
+#### 第四步：验证
+
+原型设计完成后，还需要一个很重要的环节就是验证，产品经理自己反复验证几遍，如果发现有流程上走不通或者使用不方便的地方先自己调整。调整好了交给其他人去体验，让他们提出反馈意见。
+
+一般在正式的项目中，针对原型设计，需要有相应的评审会议，让大家提出反馈，根据反馈再作出调整。
+
+比如说我前面设计的文章阅读界面，在交给朋友体验后，他给我的建议是：这样的设计看起来文章之间跳转方便了，但是要返回专栏页面反而是不方便了。而相对来说，返回专栏是一个更常见的操作。所以对竖版界面来说，这样的设计可能会让用户不知道如何回去，不如还是改回传统的返回式导航。
+
+我觉得他说的很有道理，所以最终界面变成了这样：<br>
+<img src="https://static001.geekbang.org/resource/image/dc/67/dc20050af02790ceb4c4327f523d8d67.jpg" alt="">
+
+而这样的调整，在原型设计工具中，几分钟就完成了，非常小的代价就完成了一个产品设计的确认。
+
+经过分析、设计、实施、验证这四个阶段，再反复的修改和确认几次，基本上就可以做出来不错的原型设计了。
+
+## 如何选择合适的原型设计工具？
+
+原型设计工具，选择非常多。我建议你选择的时候，可以从几个维度考虑：
+
+- 面向的平台：Web、桌面、手机；
+- 保真度：中等保真度还是高保真度；
+- 功能：是否满足你的要求；
+- 成本：价钱是否可以接受。
+
+这里推荐几款主要的原型设计工具，供参考。
+
+**Axure RP**：[Axure RP](http://www.axure.com) 曾一度是原型设计工具的代名词，历史悠久功能强大，可以制作网站、桌面软件、移动App的原型。 缺点是专业度较高，价格高。
+
+**墨刀**：[墨刀](http://modao.cc) 是一款优秀的国产原型设计工具，可以制作网站、桌面软件、移动App的原型。上手相对容易，价钱也较Axure便宜很多。
+
+**Adobe XD**：[Adobe XD](http://www.adobe.com/cn/products/xd.html) 是Adebe出的一款设计兼原型设计工具，可以制作出高保真原型，对于设计师尤其容易上手。
+
+**ProtoPie**：[ProtoPie ](http://www.protopie.io)是一款高保真原型设计工具，不需要编程基础，可以做出逼真强大的交互效果。
+
+**Framer X**：[Framer X](http://www.framer.com)是一款高保真的原型设计工具，功能很强大，但是需要一定的编程基础，尤其适合程序员使用。
+
+关于原型设计工具更多的资料，可以到“人人都是产品经理”网站的[原型设计](http://www.woshipm.com/category/rp)分类下，可以找到很多有价值的资料。
+
+## 总结
+
+今天带你一起了解了原型开发的演变历史。原型开发，从一个软件开发模型，逐步演变成了一个需求设计工具，让产品经理不用依赖程序员就可以作出逼真的产品原型，也大大降低了项目成员了解需求的难度。
+
+原型设计，让产品经理可以用最小的代价完成产品特性，逐步成为产品经理确认需求、设计产品最重要的沟通工具。原型设计工具有很多可以选择的，建议从面向的平台、保真度、功能和价格等多方面因素综合考虑。
+
+要做好原型设计，可以结合工程方法，分成四个阶段：分析、设计、实施和验证。
+
+- 分析阶段，搞清楚用户的需求，原型设计的目标；
+- 设计阶段，划分好产品的信息架构，设计好产品操作的流程；
+- 实施阶段，按照设计的结果，对每个界面制作原型，并且将界面组织起来，让界面之间可以相互跳转；
+- 验证阶段，和项目成员、客户进行确认，收集意见反馈，根据反馈进行修改。
+
+如果你的项目还没有把原型设计作为确认需求、设计产品的沟通工具，可以考虑推广应用起来，不仅上手容易，而且可以帮你降低确认清楚需求的成本。
+
+如果你打算做自己的产品，先不要着急动手写代码，不妨先做一个原型出来。
+
+## 课后思考
+
+如果你给极客时间设计一个iPad原型，你打算做成什么样？你所在项目中，在做产品设计时，会用到原型设计工具吗？用的是什么设计工具？你对原型设计是怎么看的呢？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/需求分析篇/19 | 作为程序员，你应该有产品意识.md

@@ -0,0 +1,184 @@
+<audio id="audio" title="19 | 作为程序员，你应该有产品意识" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8e/e9/8e259222d331cd53422cb2646ff9e4e9.mp3"></audio>
+
+你好，我是宝玉，我今天分享的主题是：作为程序员，你应该有产品意识。
+
+最近电视剧《都挺好》热播，没想到其中一段台词却引发了很多程序员的集体焦虑。台词说的是：“作为一个程序员，你的年龄已经很大了！我问你，你学新东西有年轻人快吗？”
+
+是呀，年纪越来越大，而新技术却层出不穷，是难免会焦虑。但如果你真的每个新的热点技术都去跟，都去学，就可以不焦虑了吗？我看也未必，因为新技术一直会有，学习也都是有成本的，只要你不能一直跟上新技术的步伐，你就会一直焦虑。
+
+那焦虑是怎么产生的呢？
+
+在我看来，焦虑通常来源于压力，压力来源于对未来的不确定，对未来的不确定来源于不知道自己的价值在哪里，不知道未来是不是还能持续创造价值，会不会失业。
+
+会不会失业，取决于你创造的价值是否高于你的工资水平，否则确实是有失业的风险。所以要想不焦虑，我们就要考虑如何提升自身价值，只要自己创造的价值够大，就不担心自己会失业，减少很多不必要的焦虑。
+
+## 程序员的价值
+
+虽然通常来说，技术水平越高，工资越高，但并不都是这样。你的工资，通常是和你创造的价值正相关的。而程序员的价值通常体现在两个方面。
+
+**第一，你的价值体现在你所做的产品之上。**
+
+也就是说，你所做的产品越有价值，你的价值就越大，相应的工资也就会高。
+
+这也解释了为什么同一个公司内，负责热门产品的部门，奖金都能多分一点；在效益好的公司，不但不担心裁员，反而钱也拿的多。这些年程序员的待遇相对于其他行业要高，也主要是因为软件和互联网行业的产品估值高。
+
+所以说，程序员的价值，并不完全是体现在技术上的，而在于用技术做成了产品，产品创造了价值，再回过头来成就了程序员的价值。
+
+**第二，你的价值体现在团队中的稀缺性。**
+
+很多时候程序员其实没机会去选择产品的。但即使在同一个产品中，技术水平相当的程序员，价值也有差别。那些价值高的程序员通常在技术上或者技术之外都有一技之长：
+
+- 有的程序员能搞定别人搞不定的技术难题；
+- 有的程序员擅长培训新人；
+- 有的程序员擅长和业务部门沟通；
+- 有的程序员能高质量地完成功能模块；
+- 有的程序员能按照需求设计好的架构，可以让团队高效率低成本地完成需求。
+
+这些有一技之长的程序员，能帮助团队创造更高的价值，也因为其独特性，难以被取代，具有稀缺性，所以价值也更大。
+
+那怎样来提升价值呢？努力提升自己技术水平，让自己成为技术大牛，这肯定是每个程序员都坚持在做的事。但技术水平提升到一定程度后，会有瓶颈的，进展会非常缓慢。
+
+这时如果也在其他领域同步发展，就会起到事半功倍的效果。比如说有的程序员会发展写作能力，写很多好的技术文章，在业界具有影响力；有的培养产品意识，让自己在技术之外，还能更好理解产品需求，能很好地和产品经理沟通，根据业务需求做出好的设计，写出高质量代码，帮助团队在项目过程上做的更好。
+
+写作固然是提升个人价值很好的方式，但要在写作上有成就，需要建立在长时间不断练习的基础上。而产品意识，是程序员的固有思维中比较欠缺、正好可以互补的，相对比较容易掌握，也能取得明显的效果。
+
+## 什么是产品意识
+
+产品意识，本质就是一种思维方式，一种站在产品角度思考问题的方式。如果细分一下，产品意识包含：商业意识、用户意识和数据意识。
+
+#### 商业意识
+
+所谓商业意识，就是所做的产品是要有商业价值的。比如说成功的商业产品有Windows、iPhone、Google等，这些产品不仅满足用户需求，同时也能创造商业价值，让这些公司变成成功的商业公司，雇用了大批优秀的程序员，从而可以继续研究更多产生商业价值的产品。
+
+其实很多程序员也有做产品的梦想，而且也有人付诸行动，业余时间做了不少产品，但是鲜有成功的。其中一个根本的原因就是，他们做的产品其实没有什么商业价值。
+
+比如说程序员热衷于做个Github客户端、博客系统，虽然说确实有用，但是却没什么商业价值，没有用户愿意付钱，导致难以持续。
+
+商业意识的另一方面其实是成本，成本意识也是程序员容易忽视的。比如说：
+
+- 有时候为了炫技，采用了更难更酷的技术方案，而忽视了所采用的方案会导致很高的开发成本；
+- 花了太长时间去开会而忽略了开会的成本；
+- 有时候又为了省钱，舍不得买一些成熟的商业组件或服务，反而是浪费了更多成本。
+
+如果程序员有商业意识，就可以在项目中有更好的成本意识，为项目节约时间、经济等成本，帮助团队打造更有价值的产品。
+
+#### 用户意识
+
+所谓用户意识，就是说做产品时，你要能挖掘出用户的真实需求，让产品有好的用户体验。这需要你要有同理心，能站在用户的角度去思考和体验产品。
+
+大部分程序员可能更多专注于程序上，所以在用户意识上确实有所欠缺。举例来说：
+
+- 一个产品功能，产品经理在细节上没有定义清楚，程序员可能并不会主动提出，最终做出来的产品会不好用；
+- 在做技术方案时，更追求技术炫酷，而不是用户体验更好；
+- 在设计接口时，并没有考虑调用者的便利性。
+
+如果程序员能跳出纯技术的局限，多一点用户意识，想到的问题将会多了很多维度，比如说：
+
+- 能让自己的负责的模块有更好的体验；
+- 让自己的技术方案更好地满足用户需求，用户更满意；
+- 让自己设计的接口、API更好用，与同事愉快合作。
+
+做到这样，无论对产品还是对自身，都是价值的提升。
+
+#### 数据意识
+
+所谓数据意识，就是在产品设计、产品运营时，通过数据来发现问题、证实结果。
+
+典型的有A/B测试，通过数据来发现用户更喜欢哪个功能，哪个功能带来更多的收入。像微博的“时间乱序”功能，虽然很多大v吐槽，但是数据证明了这是一个好的产品设计，最终还是一样上线。上线后新浪根据数据不断优化，到现在反倒是很多人喜欢这个功能。
+
+程序员虽然逻辑很好，但是大多对数据倒是不敏感，对编译警告、测试覆盖率、程序Crash的比例、API错误率、一个函数内上千行代码、性能指标等等这些数据经常选择性忽略。
+
+还有个典型的例子就是语言框架之争，程序员经常为某些语言或者框架争论不休，其实不妨基于数据分析，讨论上会更加客观。比如，从数据里你就可以明显看到jQuery和React近些年在前端的发展趋势。
+
+<img src="https://static001.geekbang.org/resource/image/69/44/693f7a58619701f51ac6a36bba8a0d44.png" alt="">
+
+其实产品意识，并不难理解，只是需要你往前更迈一步，在商业意识、用户意识和数据意识上去多思考，就可以帮你在项目中做的更好。
+
+## 如何培养产品意识？
+
+那么程序员要怎样培养产品意识呢？要培养产品意识，其实和程序员转管理的类似，首先要解放思想，然后要改变习惯，最后要多实践。这么说可能比较抽象，我们逐条展开来看。
+
+#### 首先要解放思想
+
+解放思想，其实就是说，对于程序员，不要总是单纯的用技术眼光看问题，也可以从产品的角度看问题。这两者有什么区别呢？
+
+举个例子，办公聊天软件Slack可能很多人都知道，是一款在线沟通协作软件。在国内可能知名度要低一些，但是在海外有大量企业用户，非常的火。
+
+这款软件在刚出来的时候我就知道，不过那时候我觉得这不就是一个聊天室么，我都能写一个！我站在技术角度也做了不少分析：
+
+1. 这个软件前端还是用的jQuery，如果用React应该可以做的更好；
+1. 这个软件跨平台是基于HTML5，如果是原生代码也许性能可以更好；
+1. 还是REST API，如果用GraphQL那API请求效率会更好；
+1. 从国内访问的话，速度太慢了，应该架设一些国内的服务器或者CDN。
+
+而现在，我会同时也从产品角度分析Slack：
+
+1. 它的商业价值，在于它把工作的沟通，变得高效又好玩；
+1. 消息都在云端，检索也方便，也不担心像微信一样换设备消息就没了；
+1. 其开放API的设计，让它和很多其他办公软件可以无缝集成，极大提升了效率；
+1. Slack需要付费才能查看到10000条之前的消息，这是个很有意思的设计，当你已经有10000条消息时，说明已经有足够的意愿去付费了。
+
+其实这两个角度也代表了两种不同的思维方式，一种是很多程序员熟悉的技术思维，一种是产品思维。
+
+**技术思维会关注用什么技术，关注技术细节，关注功能“如何”实现；产品思维会关注用户体验，关注一个功能所创造的价值，会去思考为什么要或者不要一个功能。**
+
+这两种思维不同，也很容易导致沟通上的误解。比如程序员会更多考虑技术实现，产品经理会更多考虑产品设计。如果都能往前迈一步，程序员有产品意识、产品思维，产品经理能有一点技术思维、工程思维，那么相互沟通起来就会更通畅。
+
+这两种思维之间的差别，其实也正是要培养产品意识的关键点。要想培养产品意识，就是要从纯粹的技术思维，有意识地培养产品思维。从关注技术、技术细节，到关注用户体验，关注产品创造的价值。
+
+#### 然后要改变习惯
+
+改变习惯是是指在日常使用产品、开发产品的时候，多站在产品的角度思考，去思考它的商业价值、用户体验、使用场景等等。
+
+比如你学习专栏用的极客时间App，你聊天用的微信。使用一些具体功能时，可以思考一下这些问题：
+
+- 这个产品的商业价值是什么？
+- 为什么要有这个功能？是为了满足用户哪方面需求的？
+- 这个产品目标用户是谁？
+- 这个功能的使用场景是什么？
+- 这个功能的体验好不好？有没有更好的方式提升体验？
+
+也许你没法马上有清楚的答案，但寻找答案的过程也是一个很好的学习的过程。
+
+如果你是程序员，在开发功能、设计架构的时候，也不妨跳出技术之外，从产品角度思考一下：
+
+- 这个功能的需求是什么？我是否完全理解了需求？
+- 如果你是这个功能的用户，你觉得还有哪些地方值得改进？
+- 哪些技术可以帮助提升用户体验？
+- 这个API用起来是不是好用？有没有更好的设计？
+- 除了对产品的思考，日常工作中，遇到一些问题，也可以从产品思维的角度去想想。
+
+一个常见的场景就是，产品经理一下子提交了一堆新的需求任务，影响了正常的开发进度，这时候你不一定要拒绝他，你就可以和他一起把需求的优先级梳理一下。你就知道哪些要优先做，哪些其实没有那么着急，方便更好的安排你的工作。
+
+还有像产品经理提交了一个技术很复杂的需求，你可以不用着急马上拒绝或者说要很长时间，而是跟他探讨一下这个需求背后要解决什么问题，是不是可以有替代的解决方案，既能降低技术难度又可以满足需求。
+
+自己开发的功能模块完成后，可以把自己当成用户试试，如果觉得体验不好或者有更好的建议，都可以反馈给产品经理。
+
+#### 最后要多实践
+
+光有理论还不够的，最好能自己实践一下。
+
+你不妨在业余时间做个小应用程序，或者设计一个原型，做完了再找你的朋友试用一下，让他们提提意见。在做产品的过程中，你自然会去站在产品的角度去思考，这会让你对产品方面有更多感悟。
+
+其实不用担心没有什么好的想法，可以从日常生活中，自己的需求、家人和朋友的需求中，去找到合适的产品需求。我当初做过很多产品都是这样的来的：
+
+- 给孩子照的照片太多，写了个工具批量生成缩略图；
+- 老婆工作上需要经常对网页截取整张图片，设计一个帮助截图的工具；
+- 帮父亲建了个家谱应用；
+- 给校友们建了一个网上交流的论坛，写过一个论坛系统。
+
+用心观察，类似的需求你也可以找到很多。
+
+## 总结
+
+今天，我们一起分析了程序员的价值体现，主要体现在两方面：所创造产品的价值和自身的稀缺性。程序员有产品的意识，可以帮助产品和自身提升价值。
+
+产品意识，主要包括商业意识、用户意识和数据意识。要提升产品意识，首先要解放思想，然后要改变习惯，最后要多实践。
+
+当你慢慢培养了产品意识，不仅可以通过技术来打造更高价值的产品，也可以让你在技术之外有一技之长，能在项目中创造更大价值，减少技术快速革新带来的焦虑感。
+
+## 课后思考
+
+请你也从技术角度和产品角度分析你常用的一款产品，同时也欢迎你分享一下你对于产品意识的思考或故事。欢迎在留言区与我分享讨论。
+
+感谢阅读如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/需求分析篇/20 | 如何应对让人头疼的需求变更问题？.md

@@ -0,0 +1,169 @@
+<audio id="audio" title="20 | 如何应对让人头疼的需求变更问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/89/88/8930a1a8fd6d466789f75997911f1e88.mp3"></audio>
+
+你好，我是宝玉，我今天分享的主题是：如何应对让人头疼的需求变更问题？
+
+我以前在国内做开发的时候，加班加点是家常便饭。这几年在美国工作，极少加班，但是产出却并没有下降，所以我一直在思索其背后的原因。这里面涉及因素很多，包括大环境、管理水平、配套设施等，但是有一个因素至关重要，那就是需求变更。
+
+在国内很多软件公司，需求变更是常态，开发到一半，很多原始需求就发生了变化，这时候当初的设计已经不能满足要求了，很多代码需要修改，不得不加班加点来赶上进度。
+
+反观不加班的美国公司，需求确定后很少变更。这样开发人员就可以针对需求有良好的架构设计，而不用考虑太多可能的变更，从容地在项目计划的时间内完成任务，而不需要加班加点。
+
+**在需求变更这个事情上，没有赢家，每个人都是受害者。**
+
+程序员自己辛苦的工作白费了，得不到成就感，因为频繁变更的需求，不得不在设计的时候考虑很多可能的变更，导致代码臃肿，代码质量降低，加班加点成了常态。甚至有人说：“杀一个程序员不需要用枪，改三次需求就可以了！”
+
+产品经理也觉得很委屈：“客户要改，我有什么办法？”程序员和产品经理似乎变成了两个对立的岗位，程序员怪产品经理乱改需求，产品经理觉得是客户造成的，人人都觉得自己委屈。客户同样不满意，觉得做出来的软件不是他想要的，进度总是在延后，还想加钱？
+
+既然大家都不满意，那么我们就需要想办法去改善，这也是软件工程这门学科存在的目的和意义。
+
+目前也已经有很多管理需求变更的解决方案，比如这两个常见的解决方案。
+
+**方案一：增强需求变更流程，让需求变更规范起来。**<br>
+这个方案简单来说，就是通过严格的流程，来避免一些没有意义的变更，从而达到管理需求变更的目的。
+
+**方案二：快速迭代，缩短版本周期。**<br>
+这个方案是另一个思路，就是将大的功能拆分，每个版本周期仅实现一部分功能需求，周期较短，这样需求发生变更时，就可以快速响应。
+
+不过，在看到这两个方案后，我还是希望你不满足于当前的答案，自己停下来思考一下这两个问题：
+
+1. 这些方案是否解决了你当前项目的问题？
+1. 如果换一个项目环境，当前方案是否依然适用？
+
+之所以要思考这样的问题，是因为对于像软件工程这样偏理论知识的学习，你一定不要仅仅停留在了解有什么样的解决方案上，**而是要追本溯源，研究问题背后的原因，研究理论背后的来龙去脉。**
+
+因为，就算你记住了再多的解决方案，换个项目环境可能就不适用了。所以我们要多去思考和分析逻辑，这样未来遇到类似的问题时，才可以做到对症下药，选择合适的解决方案，甚至在没有现成解决方案的情况下，能自己创造合适的解决方案。
+
+## 为什么建筑工程中少有需求变更？
+
+要解决需求变更的问题，你首先要知道，软件开发行业中的需求变更是怎么来的。
+
+我很喜欢拿软件工程和建筑工程进行对比，你可以思考一下，同样是工程，建筑项目也是有需求变更的，但却不会像软件项目这么频繁和失控。为什么呢？
+
+我总结一下，这里有两个主要原因：**需求的确定性和需求变更的成本。**
+
+#### 原因一：需求的确定性
+
+建筑需求是很具象的，而软件工程的需求是抽象的。所以建筑项目里面，无论是提出需求还是变更需求，客户和施工方都明确地知道他们想要什么。
+
+软件需求则经常是抽象、模糊、不精确的，模糊不清的需求导致在软件开发有了雏形后，才慢慢想清楚真正的需求是什么，从而导致需求变更。
+
+举个例子，客户最开始对软件界面的颜色是没有任何要求的，当第一版本的软件给客户看的时候，客户觉得白色背景太难看了，希望换成蓝色的；第二版本换成蓝色后，客户现在已经觉得黄色更好看，希望改成黄色背景；第三版本的时候，产品经理担心客户还想换颜色，就直接做成了换皮肤功能，用户可以自己选择颜色，客户还是不满意，问能不能把背景换成图片……
+
+是不是很熟悉？类似的事情其实经常发生在我们日常的工作场景里。
+
+#### 原因二：需求变更的成本
+
+建筑项目里面的需求变更，我们都很容易和成本挂钩，因为这些东西已经是生活常识了。而与此相对的是，很多人，包括很多老板都对软件项目需求变更导致的成本增加缺少系统认识。
+
+举个例子，装修房子的时候，如果墙面已经刷成白色了，但是客户想都刷成蓝色，那么他会很清楚，这涉及一系列成本：需要重新购买涂料、需要找人重新粉刷。
+
+但换成一个软件项目，客户想把界面的白色背景换成蓝色的，他会觉得这是很简单也是理所当然的，甚至产品经理也会这么想，他会对程序员这么说：“不就是换个颜色吗？几行代码的事，客户让换就换了嘛！”
+
+但是实际上，软件项目的需求变更，哪怕是换一个背景颜色，同样是要涉及成本的：需要修改所有涉及背景颜色的代码，需要更新相关测试代码，还需要对涉及的界面重新测试。
+
+你可以说这成本是架构设计水平不到家导致的，但是如果设计时就考虑到要有支持换背景颜色的功能，那么开发的工作量从一开始就上去了，成本同样是提升了。
+
+回到文章开始时我们提到的美国程序员不加班的问题，为什么美国的产品经理不敢随意更改需求？因为在美国很多IT公司都是工程师文化，工程师相对比较有话语权，正常情况下是不会加班加点的，所以产品经理变更需求的成本很高，在确定需求时，必须慎之又慎。
+
+## 如何解决需求变更问题？
+
+说完了原因，咱们再来看看解决方案。
+
+首先，你需要意识到，在软件项目开发中，需求变更其实是不可避免的，一味抵制需求变更也是不可取的。你能做的就是利用软件工程的知识，理解需求变更背后深层次的原因，找到合适的方案来改善，积极拥抱合理的需求变化，减少不必要的需求变更。这是大的前提条件，也是共识的基础。
+
+好，既然引起需求频繁变更的原因我们已经清楚了，那么，怎样有针对性地想解决方案呢？这里你也不妨停下来思考一下，你会想到哪些办法？
+
+我的经验是从源头着手，既然需求变更的原因是需求不确定和需求变更成本太低，那么我们就针对性地提出相应的解决方案：
+
+- **提升需求确定性，把需求分析做好，减少需求变更；**
+- **提高需求变更的成本，让客户或者产品经理不能太容易就变更需求，这样就可以达到减少需求变更的目的。**
+
+但在实施的时候，我们会发现一个问题，假如一味提高需求变更的成本，会让客户满意度下降，也造成了产品经理和开发人员之间的对立，不利于项目协作。
+
+所以我们从另一个角度思考：需求变更之所以让你痛苦不堪，也是因为需求变更让项目成员付出了高昂的代价，例如返工、加班，如果我们可以低成本地响应需求变更，那么一样可以达到管理需求变更的效果。
+
+所以解决方案上可以再加上一条：
+
+- **降低响应需求变更的成本，可以方便快捷地响应需求变更。**
+
+接下来，我来举一个在实际项目遇到的案例，我们一起来分析一下，通过对这个需求变更场景的分析，来解决以上提到的这些问题。
+
+#### 案例分析
+
+我有个大学同学叫加龙，毕业后自己开了个公司，早些年企业建站火的时候专门接企业网站的活。刚开始的时候很艰苦，也没几个人，甚至都没有专门的产品经理。
+
+开发流程比较简单，就是先把项目谈下来，客户提一个建站的需求，然后他们去开发网站，开发好了拿给客户演示。而客户在看到网站演示后，几乎每次都会提出很多变更的需求，例如说颜色变一下、布局变一下、给留言功能加上关键字过滤功能等等。客户还喜欢直接在QQ上找负责开发的程序员，让给改一下。
+
+创业初期，加龙同学真的是不容易，每天和几个程序员一起加班加点，就是为了应对客户这种频繁变更的需求。如果你是加龙，参考前面总结的几种解决方案，你会怎么做？
+
+加龙作为软件工程专业毕业的学生，我觉得他当时运用软件工程知识去改善需求变更问题上是做得非常好的。他其实并没有采用一个单一的解决方案，而是分阶段逐步改进。
+
+**第一步：规范变更流程，提升客户变更成本。**
+
+加龙其实也知道，通过提升需求确定性，做好需求分析，和客户多沟通确认，是可以有效减少需求变更的。但是他当时确实人手太有限，也没有专业的产品经理，不能短时间内去提升需求分析、产品设计的水平，所以他第一步选择提升客户变更需求的成本，这样可以马上产生效果。
+
+于是在后面的项目中，在和客户签订合同时，他会和客户约定，如果有需求变更，先统一提交到他那里，然后他甄别后再决定是否做，什么时候做，是否要重新签订新的附加合同（增加额外费用）。通过制定一系列标准，让双方合作的流程变得更规范。
+
+这样，程序员就可以专注于开发，也不会因为频繁的需求变更影响进度，大家不用那么累，收入也在稳步上升。但是需求变更的情况还是时有发生。
+
+**第二步：用原型设计低成本响应需求变更；做好需求分析和确认，减少需求变更。**
+
+加龙在挺过最艰难的创业初期后，雇佣了一个全职的产品经理，专门去和客户确认需求。这个产品经理很专业，每次在了解完客户的需求后，不急于让程序员马上去写代码，而是自己先用Axure这样的原型设计工具，做一个简单的交互原型，给客户演示。
+
+于是客户会针对原型的效果提出一些修改意见，他再快速地修改原型，这样反复确认，等到客户没有什么修改意见后，再让开发着手实现。
+
+**通过原型设计的方式，不仅可以方便地与客户沟通需求，还可以灵活响应需求变更。**
+
+通过提升需求确定性，加龙的公司进一步降低了需求变更的情况发生，营收又上了一个台阶，又增加了几个程序员和产品经理。
+
+**第三步：通过灵活的架构和强大的配置，低成本响应客户需求变更。**
+
+加龙公司经过两年的发展后，敏锐地发现其实大部分企业网站的功能都是很相似的，主要差别还是在界面样式上。
+
+这些年大部分网站的开发其实都是把前一个网站复制一份，修修改改，但是这样还是效率太低，如果可以做到定制化，就可以更高效地定制网站。
+
+于是加龙从公司抽调了几名骨干程序员，成立了一个专门的项目组，把这两年做的网站类型做了分析，做了一套建站系统，有点类似于后来流行的像WordPress这样的博客系统，可以通过换皮肤的的方式来定制界面，通过插件的方式增加功能。
+
+由于前期积累充分，大约半年后他们就开始使用这套系统去建站，一下子就把建站的成本大大降低啦。而且当客户的需求有变化时，只要后台做简单的配置就可以马上支持需求变更。
+
+但是这个模式也有问题，就是有些特别个性化的定制需求，还是满足不了。不过这也没关系，对于需要个性化的客户，要么增收额外的费用，要么就直接放弃掉。
+
+如果咱们对他这三步采取的方案做一个总结，还就是我前面说的三个方案：
+
+1. 提升需求确定性；
+1. 提高需求变更的成本；
+1. 降低响应需求变更的成本。
+
+只不过他根据公司不同阶段的特点，来灵活运用。这就是我的同学加龙在处理需求变更时分阶段采取的方案，是不是跟你想的一样？
+
+## 总结
+
+今天我通过对比建筑工程中的需求变更，和你一起分析了软件工程中需求变更产生的原因。需求频繁变更，主要是由于需求不确定和变更成本过低导致的。并由此提出了三种不同的解决方案。
+
+<li>
+提升需求确定性，来减少需求的变更。这种方案的优势就是对需求理解透彻，后期返工少，缺点是对产品经理的需求分析能力要求很高。
+</li>
+<li>
+提高需求变更的成本，规范需求变更流程，减少需求变更。这种方案的优势就是可以马上起到效果，缺点就是过于繁琐的流程不利于项目协作。
+</li>
+<li>
+降低响应需求变更的成本，积极应对需求变更。这种方案的优势在于可以快速响应需求变更，能快速试错尽快调整，缺点在于对软件架构和项目管理要求比较高。
+</li>
+
+就像我的同学加龙那样，你可以根据项目的实际情况，对比这些方案的优缺点，选择适合你的解决方案。
+
+例如你是做企业外包项目的，客户不懂又喜欢瞎掺和，那么就可以适当提高变更成本，甚至每次变更都可以计入项目成本中；如果你是做互联网项目，需要快速推出产品，那么就可以选择降低响应变更成本，快速迭代，快速试错，尽快调整。
+
+如果你是项目经理，希望你通过这次对需求变更的学习，能针对项目特点，制定合适的需求变更流程，选择适合项目的开发模式，管理好需求变更，从而提升整个项目的开发效率，避免重复返工导致的浪费。
+
+如果你是产品经理，希望你通过这次学习，对需求变更导致的成本有很高的重视，努力提升专业水平，勤于和客户、开发测试人员沟通，勤总结，尽可能将需求变更的可能性降到最低。
+
+如果你是开发或者测试，希望你在以后遇到需求变更时，不要置身事外，抱怨产品经理不专业，因为需求并不是产品经理一方的事情，项目参与者都有责任一起把需求分析做好。
+
+在一些需求分析和变更的关键阶段，要主动参与其中，从开发和测试的角度提供一些专业的建议，去思考需求产生的背景，避免对立情绪。
+
+## 课后思考
+
+在你参与的软件项目中，需求变更多吗？你们是怎么管理需求变更的？你觉得哪些地方可以做得更好？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/需求分析篇/“一问一答”第2期 | 30个软件开发常见问题解决策略.md

@@ -0,0 +1,541 @@
+<audio id="audio" title="“一问一答”第2期 | 30个软件开发常见问题解决策略" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d0/e1/d07a3eedcaf3a5e1706b92dec4a6b9e1.mp3"></audio>
+
+你好，我是宝玉。我们专栏已经完成了项目管理和需求分析这两个模块的学习。这两个模块看起来都和技术没什么关系，但却是项目中至关重要的部分。
+
+项目管理贯穿项目始终，需求是项目的源头。希望通过对这两个模块的学习，能加深你对项目管理和需求分析知识的理解，能应用其中一些方法，帮助你个人能力更上一层，项目越做越好。
+
+这个过程中一如既往的收到很多同学的精彩留言。其中有一些是提问，一些是针对文章主题自己独到的思考，这些内容都是对专栏内容最好的补充，可以加深你对软件工程的理解和学习。
+
+## 一问一答
+
+No.1<br>
+**Charles：**可行性分析形同虚设，小公司岗位职责不清晰，互相照顾面子怕得罪人，谁都怕犯错背锅，感觉谁都对，最终就导致谁是“老板”谁拍板！我感觉这个问题挺严重的，很影响决策正确性，只能等所谓的市场反馈。也用类似项目成员“扑克牌”打分的方式可以解决吗？核心问题出在哪里？
+
+**宝玉：**这个问题已经不是可行性研究的问题了！核心问题在于没有一套合理的类似于扑克牌打分的机制和流程。
+
+扑克牌为什么是个好机制：
+
+1. 公平合理，每个人都有机会不受他人影响的表达
+1. 不用背锅，估错了也没关系，意见不一致还可以讨论
+
+可行性研究是不是也可以形成类似机制？有专门会议，大家提前准备，会议上一起讨论结果，不用背锅，根据讨论结果形成最终决议。项目结束后在回顾对比当初的分析，作为下一次的参考。
+
+No.2<br>
+**川杰：**架构师是否也属于管理者的范畴？因为他需要对产品的整个框架的负责，进而涉及到对每个人的代码的管理，必要时还要给带领团队成员去做重难点问题的攻坚。那么对于架构师而言，是更偏向技术还是管理呢？
+
+**宝玉：**我觉得架构师和管理有相通的也有不同的，简单说一下我的观点：
+
+**相同之处：**
+
+- 都需要大局观；
+- 都需要好的沟通能力，让团队清晰的理解自己的意图；
+- 都需要用好流程和工具；
+- 都要善于“分而治之”，把复杂的问题拆分成小的具体的问题。
+
+**不同之处：**
+
+- 项目经理更多的是跟人打交道，对项目负责；
+- 架构设计更多是专注技术，对架构负责。
+
+两者互为补充，架构师有项目管理能力、项目经理有架构能力，都是非常好的！
+
+No.3<br>
+**天之大舒：**目标的一致性是遇到的困难，公司没有激励制度，导致项目经理和组员目标不一致，如何解决这个问题很挠头。
+
+**宝玉：**解决目标一致性问题，一个方法是多一对一沟通，你了解组员想法，组员知道你的期望；另一个方法就是不必依赖于公司现有制度，自己创造激励制度，激励制度并不一定要花钱或者花很多钱，有时候正式的表扬比钱还有价值。
+
+No.4<br>
+**titan：**小公司如何进行技术管理的问题？我所在的公司，开发人员多的40、50人，少的10多个人，这个阶段，是用制度来进行管理，还是人来管理比较合适？
+
+**宝玉：**我觉得无论大小公司，一定都要多用合理制度流程，多用工具，摆脱对人的过度依赖，只是在设计流程规范时，要充分结合公司特点、项目特点。
+
+比如说小公司老板权力很大，有些流程普通员工有效，老板直接无视了，你还得做好隔离措施，让他不要破坏流程。比如说大公司很多工具、系统都是自建，小公司就不如买来的合算。
+
+大公司各种会议和文档相对多很多，小公司这方面就可以多精简，但必要的也不能少；大公司用瀑布模型开发，一个项目几年耗得起，小公司还是敏捷一点，早点能看到产出更好。将来有一天，小公司也会变成大公司，如果你之前没有做好制度建设，将来团队壮大，项目多了，可能就会成为你的管理瓶颈。
+
+No.5<br>
+**风翱：**“团队的成功，才是你的成功“，以前也坚信这个观点，但自身的例子，让我有些动摇。把下级培养起来了，结果不是升职，而是上级越来越把我边沿化。对于这种情况，怎么调整自己呢？
+
+**宝玉：**心情完全能理解，但建议还是看长远些。人生不只是一个下属，不只是一个老板，也不只是一个项目。以前我也纠结过这问题，现在不纠结了。因为我不止能培养好一个下属还能培养更多的下属，我能做好一个项目还能做好更多项目，我不需要靠一个老板的赏识与否来证明自己。
+
+No.6<br>
+**冰封血影：**针对一些曾经贡献大的技术怎么管理呢？然而传统思维模式和产品迭代模式遗留的一些诟病，很难用新环境、新模式让他们去做改变。（这里并不是否定以前的模式）<br>
+比如：对新推出的KPI这类漠不关心、对整个团队表现不出积极的面，反而带来了一些不好的点和面，但是做东西质量相比其他又高；这类怎么去处理和更好的提升整个团队的战斗力、协作力？
+
+**宝玉：**几点建议：
+
+- 多一对一沟通，了解他的诉求，让他了解你的期望；
+- 尝试安排一些有挑战的任务；
+- 充分发挥其优势；
+- “鲶鱼效应”，招聘技术相当的或者更高的，减少其不可替代性。
+- 如果负面因素较多，可考虑隔离到某个项目中，避免对其他人造成负面效果；如果负面影响大于正向贡献，劝退也是个方案。
+
+No.7<br>
+**Dora：**技术人员呢一般很傲，所以做项目管理，可能要面对被技术人员心里瞧不起，甚至不听话。怎么办？
+
+**宝玉：**几点建议吧：
+
+- 如果管理者技术牛，或者懂一点技术，那么就容易很多；
+- 让项目成功，就是最好的证明你实力让他们服气的方式；
+- 多换位思考，尊重技术，平等沟通；
+- 多帮助他们：帮助成长、帮助涨工资、帮助他们少无谓加班；
+- 多用流程规范来管理，少基于人管理。
+
+No.8<br>
+**tcny：**如果因为开发不紧不慢耽误了时间，如何处理呢。应该设置什么样的奖惩制度呢？
+
+**宝玉：**这是个好问题！计划恰恰就是为了预防类似于开发不紧不慢耽误了时间的问题。具体例子，一个模块，正常估算（开发和PM都认可）需要5天，但是如果你的计划粒度是5天，那么你到最后一天才能知道是不是会延迟，这时候补救已经晚了。
+
+如果你能把粒度设置到半天一天，那么第二或第三天你大概就能知道进度是不是有问题，然后马上作出调整，要么加班，要么找人帮忙，要么换人，要么改计划。这样才可以做到防患未然！至于奖惩制度，只是手段，而不是目的！
+
+No.9<br>
+**一路向北：**计划是否也会有一个迭代的过程呢？
+
+**宝玉：**计划一定是个迭代的过程，计划也是个粗到细的过程。一开始不建议做特别细的计划，整体粗一点，定好大的时间节点，也就是里程碑，然后对于下一阶段的计划细化。
+
+细化过程中要拉上具体参与的人一起制定，这样结果才科学也不会导致抵触。里程碑定了后不要轻易变，不然就失去了DeadLine的意义，即使变也不能过于随意和频繁。
+
+No.10<br>
+**Geek_85f782：**如果是采用敏捷方法的项目，项目计划是否应该就是迭代计划？在这种情况下WBS的结构其实就是一轮接着一轮的“规划-分析-编码-测试-集成发布-与敏捷配套的一系列总结”？每一轮迭代的成果就是项目的里程碑？
+
+**宝玉：**敏捷的项目计划确实有些不一样，WBS分解后会变成backlog，backlog的项会被打分（参考扑克牌打分），根据分数大致可以算出来需要多少Sprint。因为敏捷开发磨合好后，每个Sprint能做的任务分数大致相当。算出来多少Sprint，就能大概知道需要多少时间。通常里程碑不会那么密集的，一般会几个Sprint一个里程碑。
+
+No.11<br>
+**纯洁的憎恶：**制定计划最好能让项目相关各方充分参与，这样计划更可行，偏差低，结果更可控、可预期。但我的经历却是需求、开发、运营、用户等角色几乎不参与制定计划，就连需求分析、功能设计、测试、验收也以工作忙为借口很少介入。项目管理人员主动拉他们，也遭到厌恶与不配合。在观念与体制不支持的环境里，如何能更好的调动各方充分参与、支持项目呢？
+
+**宝玉：**你这种性质的单位我确实没经历过，缺少经验。不过我可以帮你从另一个角度分析下，就是如果我不愿意参与计划可能有这些方面原因：
+
+1. 跟我利益不相关，做了没好处，不做没损失；
+1. 你已经做的够好够细了，没什么好发挥的；
+1. 就算参与了提了想法和意见也没用，最后还是项目经理说的算，那我还掺和个啥劲。
+
+所以你可以看看能不能让这事变成一个跟大家利益相关的事，跟绩效考评啥的扯上关系，必要的话拉上领导狐假虎威一番。拉他们参与时不用太细，让他们有机会参与制定，制定时能平衡好他们的利益关系。尤其是里程碑的确定，我觉得应该是和大部分人利益相关的，至少这个点得让他们参与进去。
+
+No.12<br>
+**bearlu：**我一直想自己私下做一个项目，但是不知道如何开始，是不是第一步要确定做个什么软件？
+
+**宝玉：**对的，第一步先想好做什么。给你的建议是：
+
+1. 做个小的；
+1. 做个实用的，最好自己能用或者身边人能用；
+1. 迭代开发，第一版本只做核心功能。
+
+No.13<br>
+**哥本：**在做里程碑的时候需要花时间整合做集成测试吗？就比如像您说的，服务端开发完成后需要与pc客户端联调，那这就涉及到发布，环境搭建，部署…做WBS时要把这些时间也算进去吗？
+
+**宝玉：**做里程碑要不要整合做集成测试，取决于里程碑的目标，比如说如果目标是具备测试条件可以联调，只要能调就可以；也可以定义目标是要测试验收通过，这就需要做集成测试的。<br>
+这种需要人需要时间去做的事情，都应该放到计划里面。文章中的计划表没有放，是考虑不周。
+
+No.14<br>
+**alva_xu：**需求文档和测试用例怎么验收？对于性能测试是否合格问题，你们是怎么解决测试环境和生产环境可比性问题的？
+
+**宝玉：**需求文档验收可以通过需求评审会议，评审时开发和测试都要有代表参加，一个是提出反馈，另一个是及早了解需求。评审会议通常要开几次才能最终定下来。测试用例通常是产品经理协助验收或者辅助确认。
+
+原来我们在飞信时，会有一个模拟生产环境的压力测试环节，从生产环境同步真实数据过去，规模按生产环境比例缩放。还有的压力测试是直接在生产环境做的，在半夜人流量少的时候。
+
+No.15<br>
+**张驰：**在日常工作中，流程应该由谁来制定呢？普通开发人员还是领导者，亦或者是公司有这种专职专岗的人？往往很多人都能够发现问题，甚至也有一些自己解决问题的方式方法，但是要想具体流程化对公司整体产生作用，往往感觉是有力无门，没有一个好的渠道。
+
+**宝玉：**一个好的流程经常是跟问题切实相关的人员提出来的，或者把问题反馈出来，大家一起想办法，最后由项目经理或者部门负责人帮助落实推广。
+
+其实像敏捷开发每次迭代结束后的Sprint回顾会议就是一个很好的讨论问题的方式。可以考虑参考Sprint回顾会议的做法，定期有专门的会议讨论这样的问题。另外如果有组员之间的“1-1”会议，也是讨论问题和解决方案的途径。也可以通过邮件、聊天工具讨论解决。
+
+No.16<br>
+**bearlu：**能不能说说开会要留意些什么内容，我是个新手，每次开完会议，到开发的时候又找产品确认具体功能。
+
+**宝玉：**我想你说的应该是需求评审会议或者需求讲解会议，对于这类会议，建议你会议前读一下文档，这样心中有数，同时对于文档中觉得不清楚或者有疑惑的地方记录下来，在会议中提出。不同的会议重点不一样，开会之前你都可以实现了解下这次会议的主要目的是什么，然后事先准备一下，这样开会就会更有效率一些。
+
+No.17<br>
+**hua168：**整个项目开始前到项目完全结束，一般都要开那些会议呀？目的是什么？
+
+**宝玉：**整理如下。
+
+**项目启动会议：**
+
+通常在项目启动后，会有一个正式项目启动会议，俗称Kick off meeting，通过这个项目，你可以了解几个关键信息：
+
+- 项目目标：这项目是要干什么的，达到一个什么目标；
+- 项目里程碑：项目的开始结束时间，项目的阶段划分，以及各个阶段的时间点；
+- 角色分工：项目成员的分工和角色是什么，每个人知道自己的任务是什么，知道遇到问题该找谁；
+- 流程规范：项目开发的主要流程是什么，基于瀑布还是敏捷。
+
+**瀑布模型各个阶段的评审会议**
+
+瀑布模型因为阶段划分清楚，每个阶段都有明确的产出，所以通常每个阶段都有评审会议，典型的像需求评审会议和架构设计评审会议。这种会议主要目的是用来收集意见。
+
+**瀑布模型各阶段的说明会议**
+
+在评审会议结束后，需求设计、架构设计最终确定后，通常还会组织会议对需求设计和架构设计做说明，所以会有：需求设计说明会和架构设计说明会。
+
+**进度报告会议**
+
+无论是采用瀑布模型还是敏捷开发，通常都少不了进度报告会议。只是瀑布模型通常是以周为单位的周例会，而敏捷开发是以天为单位的每日站会。可以通过会议，了解项目的进展，了解当前的困难和瓶颈，及时调整计划，解决问题。另外在会议上，每个人都要当众讲一下做过的事情和计划要做的事情，也是一种无形的监督和约束。
+
+**项目计划会**
+
+在敏捷开发中，每个Sprint开始前都会有一个Sprint计划会（Sprint Planning），决定当前Sprint要做哪些内容。在瀑布模型中，每个版本开始之前也会有项目计划会。有所不同的是，瀑布模型通常是项目经理和开发经理、测试经理等少数几个人决定的，而敏捷开发中则是全体成员一起针对Backlog的内容进行选取和打分。
+
+**产品演示验收会**
+
+在瀑布模型中，项目在测试通过后，会对客户有一个产品演示验收的会议，向客户展示工作成功。敏捷开发中也有Sprint评审会（Sprint Review），在每个Sprint结束后，向客户演示当前Sprint成果。
+
+**项目总结会议**
+
+在项目结束，通常项目经理需要组织一个总结会议，希望大家能在会议上总结一下项目的得失，把经验总结下来，帮助下一次做的更好。在敏捷开发中，更是每个Sprint都会有一个Sprint回顾会议（Sprint Retrospective）。
+
+**一对一会议**
+
+虽然项目中有每日站会或者周例会这种让项目成员可以反馈问题的方式，但是对于很多人来说，并不愿意在很多人面前说太多，但是如果是一对一的私人对话，则更愿意反馈一些更实质性的内容，从而项目经理或者管理者能了解到更真实更准确的信息。
+
+No.18<br>
+**kirogiyi：**能否把项目管理每个阶段用到的典型工具分享一下？
+
+**宝玉：**我们专栏每个阶段都有关于工具的章节。
+
+- 需求分析篇的工具要讲原型设计，需求阶段还有需求收集管理工具，通常可以用Ticket管理系统（如Jira）、源代码管理（如git）或文档管理工具（如Google Docs/石墨文档）来做。
+- 设计阶段其实主要用文档工具，用MS Visio/PPT画图。
+- 编码阶段主要是源代码管理工具、各种IDE、持续集成平台（Jenkins）的搭建。
+- 测试阶段主要是有测试用例管理系统（例如TestRail），有Bug跟踪系统（基本上和项目管理工具一起的，例如Jira）。
+- 运维监控有日志管理系统（例如ELK），监控（例如Wavefront），报警（例如PagerDuty）。
+
+No.19<br>
+**纯洁的憎恶：**我看燃尽图好像是根据ticket数量的历史变化情况，线性的预测未来的工作进展。但工作真实进展很可能不是线性的，这是否说明燃尽图的剩余工作预测存在天然偏差呢？
+
+**宝玉：**燃尽图是有天然偏差的，因为任务的复杂度其实不一样的，有的几小时就完了，有的得好几天，有时候你看只剩下一个任务了，但这个可能是最难耗时最长的。所以我个人更喜欢看板视图，可以直观看到当前Sprint具体什么任务还没完成。
+
+No.20<br>
+**busyStone：**请问新的这些工具还能看到并方便的编辑任务依赖么？有没有工具可以直接通过修改状态就自动换看板的?另外，像同一个需求需要多端，安卓，苹果，PC同时开发的，请问有没有好的方法来建立任务? 之前都是一样建一个，有点烦。
+
+**宝玉：**以Jira为例：
+
+- Ticket之间是可以建立关联的，好像不是强依赖。
+- 修改Sprint属性就可以切换看板，修改状态就可以切换看板的泳道。
+- Ticket可以克隆（Clone），同一个需求可以克隆多份，然后稍作修改。
+
+No.21<br>
+**oldlee：**请问前后端开发分离工具有没有好产品推荐？现在遇到的问题是，客户端经常需要等待服务端开发完，才能调用接口联调。
+
+**宝玉：**这个问题有几种解决方案：<br>
+服务端先实现一个模拟的接口；<br>
+客户端自己模拟接口；<br>
+第三方服务。例如：<br>
+[https://github.com/easy-mock/easy-mock](https://github.com/easy-mock/easy-mock)<br>
+[https://getman.cn/mock/](https://getman.cn/mock/)<br>
+[https://apizza.net/](https://apizza.net/)
+
+No.22<br>
+**alva_xu：**项目的不同时间节点，项目风险及其处理手段也是不一样的。所以，在讲风险管理的时候，还要加一个时间维度。老师能不能就这个维度来谈谈风险及管控处理方法？
+
+**宝玉：**其实要考虑时间维度，你只要把时间范围成本三要素的约束加上就好了。因为时间变了，这三要素的约束也在变。
+
+给你举个例子：一个创业公司，人少缺钱，这时候人就是个很大的风险，有人离职项目就很危险，这其实本质就是三要素的成本；等到熬过这阶段，进入发展阶段，活下来有钱了，人也多了，相对来说，成本就不是最大的约束了，人的风险就没那么大了，这时候就是求快，时间会变成约束，所以如果你的技术和架构跟不上开发的效率，就会成为新的风险。
+
+No.23<br>
+**Bo：**已经写好项目文档，但想更另一步优化文档，老师可以分享一下项目中需求规格说明书、概要设计、详细设计、代码规范文档、测试文档、部署文档等的优秀具体案例吗？
+
+**宝玉：**有些内部文档不方便分享。我在文中附了一个开源项目的链接：[https://video-react.js.org/](https://video-react.js.org/)
+
+这个是一个组件使用文档，其实类似的有很多开源项目的文档都写得很好。比如：<br>
+Vue: [https://cn.vuejs.org/v2/guide/](https://cn.vuejs.org/v2/guide/)<br>
+Redux: [https://redux.js.org/](https://redux.js.org/)
+
+还有可以网上搜索一些，例如：<br>
+产品需求文档模板：[https://www.jianshu.com/p/e89e97858be1](https://www.jianshu.com/p/e89e97858be1)<br>
+微服务，从设计到部署：<br>
+[https://docshome.gitbooks.io/microservices/content/2-using-an-api-gateway.html](https://docshome.gitbooks.io/microservices/content/2-using-an-api-gateway.html)
+
+No.24<br>
+**hua168：**老师能简单说一下项目前–&gt;项目中–&gt;项目完成，一般都需要哪些文档呀，有没有示例或链接或搜索关键词？
+
+**宝玉：**我大致列一下，可能有遗漏的。
+
+**项目立项：**
+
+- 原始需求文档；
+- 可行性分析报告；
+- 立项说明书。
+
+**需求相关的：**
+
+- 原型设计文档；
+- 产品设计文档。
+
+**系统设计相关的：**
+
+- 技术方案文档；
+- 详细设计文档。
+
+**开发相关的：**
+
+- 代码规范文档。
+- 测试相关的：
+- 测试用例；
+- 测试验收报告。
+
+**运维相关的：**
+
+- 部署文档；
+- 故障报告。
+
+No.25<br>
+**邢爱明：**对于详细设计文档的颗粒度一直有点疑问。是写到类图或者时序图这种级别，说明不同类和方法之间的关系？还是要细化到类似于伪代码级别，需要写操作哪个数据库表，和调用哪个api接口？
+
+**宝玉：**我们2002年学软件工程的时候，推荐的写设计文档就是你说的这种细化到为伪代码级别，当时初衷是学习建筑行业，把写代码变成像搬砖砌墙一样，招一堆蓝翔培训出来就可以写代码。据说当年日本软件产业就是这样的。
+
+实际上这些年下来，这种方法是不可行的（至少我没看到过成功案例），一个是设计文档写得太细，其实成本上已经跟写代码没差别了，不利于分工协作；另一个是写代码本身是一种创造性的劳动，当你把文档写到伪代码那么细，具体负责代码实现的没什么好发挥的空间了，都变成体力劳动了。
+
+推荐的做法是写设计文档时不要太细，同时应该把具体模块的设计交给负责这个模块开发的人去做，指导他完成设计。这样既可以更好地分工协作，也可以让程序员有机会成长和充分发挥其主观能动性。
+
+No.26<br>
+**晓伟呢。☀：**需求分析之后是不是应该还有产品需求分析文档（PRD）和产品需求规格说明书？
+
+**宝玉：**其实不必困惑这个问题，因为这本身没有特别的标准的。如果用瀑布模型开发，确实会有你说的文档，但如果是敏捷开发，可能会是另外的形式存在，例如每个小功能一个独立的用户故事，或者是独立的产品设计文档，只是讲清楚一个功能。
+
+虽然形式不一样，但其目的都是一样：让大家可以讨论需求，可以理解需求。之前我有回复过有哪些文档的问题：
+
+- 这件事需要讨论需要评审，要有文档作为讨论的依据，以及记录讨论的结果。比如各种设计文档；
+- 这件事要有规范，要有文档保证规范统一，比如各种规范文档；
+- 这件事要记录下来，作为以后的一个参考。比如各种报告、环境配置、操作手册、API文档等。
+
+No.27<br>
+**hua168：**什么是模块呀？模块有哪些分类？一般说的模块是业务模块？模块间“高内聚低耦合”，如果模块之间要进行通讯是不是用接口实现？如果有依赖关系越多的话的话那不是独立性越差？要实现“高内聚低耦合”，如果项目复杂一点，会有难度吧？
+
+**宝玉：**这个话题其实属于架构下面的。在技术里面，模块其实是对某一种类型需求的抽象。举个例子来说，一个博客系统，博客的帖子是一个模块，评论是一个模块，用户是一个模块，帖子和评论又可以进一步抽象成内容模块。
+
+模块的分类看你是从架构层面看还是从业务层面看。比如说从架构层面看，一个普通的博客网站可以看成三层：UI层、业务逻辑层和数据访问层。其中UI层包含帖子列表模块和博客文章阅读模块；业务逻辑层则是帖子业务模块、用户业务模块。
+
+如果从业务层面看，包含博客阅读模块和后台模块，更偏向功能的分类。
+
+高内聚低耦合是架构里面的概念。因为架构设计，需要把大的系统拆分成小的模块，拆分后，还要通过约定的协议通信。典型的有前后端分离然后通过REST API通信，还有像类库之间直接通过公开的方法调用。
+
+低耦合意思是项目没有什么依赖，改动互相不受影响。比如说前端和后端之间通过API通信，只要API不变，无论你后端用什么语言，跟前端都没关系。
+
+高内聚指的是一个模块都是关系很紧密的代码，比如用户模块，所有用户操作的功能都在用户模块里面，关系紧密，也不需要依赖于其他模块。
+
+No.28<br>
+**kirogiyi：**在敏捷开发中产品部门怎样参与产品设计会更好，或者以什么方式参与会更好？
+
+**宝玉：**你问的是产品部门参与产品设计，还是开发部门？
+
+首先从技术角度，好的产品设计要让产品设计在技术上实现不要成本太高，所以在一些技术难度高的设计上两边要多沟通确认，共同制定出技术难度适中，又满足好产品需求的设计。
+
+然后从产品角度，开发必须充分理解产品设计才能设计出符合产品需求的架构，才能开发出满足需求和好的用户体验的产品。所以开发需要多和产品设计反复沟通需求，然后将确认后结果体现在文档上。
+
+至于参与方式，主要还是看什么形式比较好。比如可以安排需求评审，关键节点让主要开发人员参与确认技术可行性和成本以及建议。比如有分批次的需求讲解会议向开发讲解产品设计，回答理解不清楚的问题。每个Sprint产品经理都要参与其中，及时和开发沟通确认需求不明确的问题！
+
+No.29<br>
+**alva_xu：**在目前前后端分离、Restful 风格的应用架构下，是否更容易实现原型设计时的代码的重用率，以提高开发速度？具体是怎么做的？
+
+**宝玉：**以前在讨论开发模型的时候有介绍，快速原型开发模型有两种模式，一种是抛弃型的，就是用工具开发的这种；一种是演化型原型，就是类似于MVP，先做简单核心功能，然后不断演化，变成最终产品。
+
+如果你要提升代码的重复率和开发速度，这种前后端分离的呀，我给你的建议是用一些第三方API云服务：<br>
+[https://www.apollographql.com/](https://www.apollographql.com/)<br>
+[https://firebase.google.com/products/firestore/](https://firebase.google.com/products/firestore/)
+
+这样你就完全不用考虑后端开发了，直接用它们定制就好了。等到产品开发出来，你再考虑后端迁移。
+
+No.30<br>
+**LDxy：**Windows 系统已开始就是作为一个产品开发的，最初的项目团队应该是很有产品意识的；而Linux 系统的开发者最初好像并不是把它作为产品开发的，这是不是也是造成如今Linux 和Windows 相比对大多数用户的易用性差别很大的原因？这是不是也是产品意识差异导致的结果？能不能作为一个说明产品意识的例子？
+
+**宝玉：**我觉得Windows和Linux产生的差别还是因为产品定位的不同导致的。前者是商业产品，面向普通用户；后者是开源产品，面向专业用户。
+
+## 精选留言：
+
+西西弗与卡夫卡：<br>
+最近有个项目延期，原因之一就是用到的第三方库需要https绑定域名，测试环境因为用http所以没有发现该问题。事先的可行性研究，目的就是消除或者平衡项目中的技术风险、能力风险、协作成本、法律、部署等风险。
+
+总结里给出了一个可行方法，即尽早上线部署，不对外公开服务即可。像法律问题，靠软件部署没法解决，可以有个检查清单，每类风险都给出适当评估意见。
+
+相关阅读：[09 | 可行性研究： 一个从一开始就注定失败的跨平台项目](http://time.geekbang.org/column/article/85730)
+
+Felix：<br>
+机缘巧合转管理已经快两年了，以下说说我的看法：
+
+1.大局观，我十分赞同老师的观点，我领导经常潜移默化地这么教我们，我也觉得这是我转管理后的最大收获，不能像以前看着自己的一亩三分地，站在全局考虑问题；正如张一鸣说的那句，“工作时不分哪些是我该做的，哪些是我不该做的”，这句话对我影响很大，做事不设边界，才能我有更大的成长，而这些对管理来说尤为如此
+
+2.流程规范，接手管理后，发现虽然我们有一大堆流程规范的wiki，但很多形同虚设，我个人总结有以下几点问题：（1）不能很容易找到对应规范wiki； (2)很多规范冗长复杂，不知所云； (3)流程规范太多，没时间看。
+
+于是我第一步就是整理杂草丛生的wiki，先保证目录清晰，让大家按目录写wiki，对号入座，查阅起来方便有条理，接下来挑出重点的流程规范进行了简化微调，每周会重点强调1-2个，在本周工作中重点关注，并适当提醒，渐渐大家一起走入流程的正规，并也体会到了按流程规范走所带来的便捷。
+
+3.管理该不该写代码，我觉的这事不能一棒子打死，我的观点有点像党的一句老话：从群众中来，到群众中去，在项目关键时刻负责一个小的Ticket，我觉的有以下几点好处：
+
+- 因为平时的code review不可能面面俱到，这么做更加深入了解系统底层结构和代码，更加容易指导员工的技术细节问题 ；
+- 让自己不是光说不练，纸上谈兵的领导，我觉得从我本身而言，可能中高层确实不必要，但我认为这对于一线管理还是很有必要的，能够树立威信，合作沟通更加顺畅。
+
+4.自己的管理风格，关于大棒还是胡萝卜，确实不同的公司、团队应该有不同的管理风格，这里没有对与错，但我认为对于扁平化的互联网公司，各种大牛，严厉的风格是我不提倡的，像老师说的激励帮助下属，团队氛围融洽，大家自驱地做事情我认为更可取。
+
+相关阅读：[10 | 如果你想技术转管理，先来试试管好一个项目](http://time.geekbang.org/column/article/86375)
+
+alva_xu：<br>
+关于技术转管理，先从项目管理开始。这个观点我极其赞同。以下我谈谈自己的想法。
+
+1.老师举的是软件开发项目管理的例子，假定的项目经理是有开发技术的，所以需要克制自己不要有写代码的冲动，这一点我极其赞同。但假如项目经理以前并不是写代码的，这时候怎么办？我倒是觉得，应该学点代码，尝试写点代码，深入理解软件开发框架，培养点软件架构思想，才能充分理解开发人员的境况，更容易和自己团队甚至客户进行交流。
+
+同时无论你过去是开发大牛、还是应用架构师、领域专家、还是基础架构师，除非人员安排如此，否则，千万不要越俎代庖，把这些事情交给负责这些事情的人去做，你可以做的就是帮助指导，而且尽量要从方法上去指导，“授人以鱼不如授人以渔”。特别是一个比较固定的团队，培养一个人的成长比样样事必躬亲要好。
+
+2.管理牵涉到“人”“工具”“流程”三个部分的使用。项目经理首先需要学一些管理学的知识，如何激发”人“的潜力以完成目标是管理的最主要目的，所以一些管理理念，比如MBO，管理方法（沟通技巧）都得学一点。
+
+对于“工具”，好的工具和差的工具效果不同，但更主要的是要用好工具，比如敏捷模式中，像Jira，或者VSTS等都是很好的管理工具，也就是老师讲的ticket工具，但怎么用好它，需要项目经理在团队内外进行培训推广，常抓不懈。还要考虑怎么把“流程”固化到工具中，那么项目管理就如行云流水了，所谓子在川上曰，逝者如斯夫！
+
+3.当“人”“工具”“流程”都发挥了它们的作用的时候，项目经理就需要凭借自己的知识和经验、善于发现风险，管控风险。这时候，我觉得风险管理是项目经理最大的责任。特别是控制好“范围”（防止项目过程中范围扩大或者变小），“成本”和“时间”，以最终达到合理成本下按时交付完整的达到质量要求的项目交付物。
+
+以上几点，也是我从基础架构规划实施、然后做基础架构项目，现在管理软件开发项目好多年来的对于项目管理的一些经验，和大家共享，也请老师点评。
+
+相关阅读：[10 | 如果你想技术转管理，先来试试管好一个项目](http://time.geekbang.org/column/article/86375)
+
+javaadu：   <br>
+1.不同的岗位有不同的职责，基层管理者的职责并不是单纯的管理，要兼具技术深度、技术视野、项目管理、团队管理等技能。
+
+2.关于“写不写代码”的讨论，作者说这句话的意思是，项目管理者要明白，写代码并不是万能药，不能过分得关注细节，要跳出来，看全局，要明白自己的职责——管理项目过程、控制风险，拿到结果。
+
+至于说是不是要写代码，那是另外一个问题，阿里现在已经取消了技术线的纯粹的管理岗位，就是希望技术线的基层领导者都不要把技术丢掉，要能跳出来看全局，同时也能带领团队打硬仗。
+
+3.我有转型管理的计划，我希望自己能够实现从个人的成功到团队的成功，原因是：个人的成功，影响力有限，团队的成功才能完成更大的成就。
+
+我计划按照老师说的，从项目管理入手。遇到的困难就是自己的大局观不够，一冲动就喜欢自己上，这样的情况很不好：自己累的要死，还没什么成就感，然后团队其他成员也得不到充分的的锻炼。希望在后面的工作中，如果有项目管理的机会，自己能够改善自己的大局观。
+
+相关阅读：[10 | 如果你想技术转管理，先来试试管好一个项目](http://time.geekbang.org/column/article/86375)
+
+纯洁的憎恶 ：<br>
+进步的关键是角色转换，级别越高离具体工作越远，对人和资源的驾驭能力越强。项目管理就是要管好人和事。管好人就是正确引导客户的期待，用流程和规范管理团队。管好事就是选择适当的模式，制定计划，防控风险。持续成长是勇于跳出舒适区进入学习区。
+
+相关阅读：[10 | 如果你想技术转管理，先来试试管好一个项目](http://time.geekbang.org/column/article/86375)
+
+MiracleWong： <br>
+根据自己的经验写一下。
+
+1.很多的时候，我们不愿意制定计划的原因，简单地说是“懒”，深层次的原因是不愿意“思考”，因为这需要做很多准备工作，并消耗很脑细胞，是对自己认知上的一个考验。再往深处挖则是“不愿意承担责任”（工作中尤其会遇到类似的同事，我拿多少钱就做多少工作，偶尔自己也会成为这种人)，因为要介入制定计划、以及后续的调整，就觉得这不应该是自己的工作量。
+
+2.就是制定计划的颗粒度粗细的问题。自己经常会遇到类似的困扰，就是一次计划，分解的太过详细，导致行动的时候因为繁琐反而拖延或直接不做。（也明白这是一种心理上的自我欺骗，认为做了计划就等于行动了，类似于买个课程就等于学习了，收藏了就等于看了。）
+
+这就会导致下一次的计划遭到“反噬”——上一次那么详细也没什么用，还不是不做或者稍微写一下呢。等到自己没有什么目标或者虚耗摸鱼时，又记起“详细计划”的好，一次次的循环。
+
+3.对于宝玉老师说的是否有制定计划的习惯，我经常是每个月的最后两天，制定下周的目标（类似工作计划）。将目标和自己的工作生活学习联系起来并进行分解，分散到每个月的四周里。每周做个小结，月底再做月总结和下月目标。目前还是在尝试练习中，在逐步形成自己做目标和总结的固定模板，省去部分重复性的工作。
+
+相关阅读：[11 | 项目计划：代码未动，计划先行](http://time.geekbang.org/column/article/86817)
+
+alva_xu：<br>
+计划就是为了把项目的各种资源（人力资源，软件资源，硬件资源等）有序组织起来，以便及时识别变化、应对变化。所以做计划的时候，一要考虑如何使计划更加精准，二要考虑一旦有变化、计划如何能更加容易调准。
+
+方法可能就是：<br>
+1.尽量把任务拆解，和任务执行者一起确定故事点（scrum里的说法，这里借用一下）。这样的话即使计划变化，并不是每个任务都变化，计划调整就快；
+
+2.对任务进行合理排序，找出关键路径和关键节点，项目的风险就比较容易识别。计划调整就能更加及时有效；
+
+3.通过设立指标和看板，利用项目管理工具及各种形式的会议、报告，及时收集监控项目情况，适时发现问题，及时调整计划。
+
+相关阅读：[11 | 项目计划：代码未动，计划先行](http://time.geekbang.org/column/article/86817)
+
+alva_xu： <br>
+我来谈谈对老师讲的几个点的个人看法和实践。
+
+1.方法和流程规范的区别
+
+老师讲的很对，流程规范是在很多经验总结后形成的。从ITIL流程来说，这里的方法实际上可以理解为事件管理的范畴，就是发现了一个incident ，想办法去解决，甚至用work around 的方法去解决。当相同的incident发现次数多了，在review的时候，事件就上升成为问题。问题管理就是用来彻底避免相同事件重复发生的。
+
+而规范流程是问题管理的一种手段。问题管理会带来变更管理，规范流程的制定和修改，是可以纳入到变更管理中的，只要纳入到变更管理，就自然会考虑到沟通机制、回退计划等事情。
+
+我们也碰到过类似老师提到的改数据库的问题。刚开始数据库改出问题了，我们就处理数据库问题，后来，总结下来，需要严格改数据库的流程，比如增加业务运维和基础运维的经理审批才允许修改数据库，改数据库的流程我们也花了很多时间进行优化才真正固定下来。
+
+2.流程规范工具化
+
+我觉得，除了工具化，还要尽量自动化。举个例子，我们这边最早采用checkstyle和findbug嵌入到IDE的方式进行代码检查，然后规定每个项目必须用这两个工具。但后来发现，这个规定执行的很不好，许多项目组没有自觉执行，增加了QA团队的检查工作量。后来我们采用sonarqube,并把它集成到ci里，就不怕项目组不执行了。
+
+3.推广执行的问题
+
+除了前面两个方法，纳入变更管理和纳入自动化流水线之外，还有一个特别重要，那就是考核问题。但这个有很大的难度。有些规范的执行力度很难量化考核 。举个简单的例子，测试用例和需求文档的匹配问题，还有比如压力测试的性能指标问题，如果没有工具和环境，这简直会把QA愁死。所以，流程执行的好坏，还是与人和工具技术有关，三者互相关联，缺一不可。
+
+相关阅读：[12 | 流程和规范：红绿灯不是约束，而是用来提高效率](http://time.geekbang.org/column/article/87129)
+
+青石： <br>
+组织会议，一定要有会议时间、地点、人员、主题，会前要有准备、会中讨论要有结果（指定干系人）、会后要跟踪。没有主题、没有讨论结果、没有跟踪的会议，都属于无效会议。
+
+相关阅读：[13 | 白天开会，加班写代码的节奏怎么破？](http://time.geekbang.org/column/article/87399)
+
+kirogiyi：<br>
+完全手工方式管理的优点在于自由空间大、项目结构松散，比如临时添加需求、临时添加人员、临时改变策略等。一旦管理者没有足够的能力去驾驭项目的整体架构，随着项目时间的推移，项目不是越做越简单，而是越做越难，可能到处都是窟窿，根本没法持续下去，并且责任和义务大部分集中于项目管理者。
+
+尽量采用软件工具管理的优点在于对需求、人员、进度、里程碑等可以进行事无巨细的分解或者组合，明确每个人的职责，明确每件事完成的要求，既可以让参与人员看到长期目标，也可以让他们看到短期目标，而不是遥遥无期。可以这样讲，没有路标的100公里总是比有路标的100公里来得费劲得多，还有就是很容易让参与者失去信心，丧失斗志。
+
+相关阅读：[14 | 项目管理工具：一切管理问题，都应思考能否通过工具解决](http://time.geekbang.org/column/article/87787)
+
+刘晓林：  <br>
+我觉得辅助计划工具是从项目规划和任务分解出发，以任务之间内在逻辑关系为依据组织任务，优点是能够清晰地看到整个项目的蓝图，缺点是结构化程度太高，不够灵活，不能适应项目执行期间遇到的变化。
+
+基于tickt的管理跟踪系统是从项目执行的角度出发，以执行周期为依据组织任务(如一个sprint)，注重任务的状态跟踪，优点是灵活；缺点是缺乏结构化，各任务之间的关系不明确，容易只见树木不见森林，因此不适合做项目规划和任务分解。
+
+因此，需要将二者结合起来用，在规划和任务分解阶段，用项目规划工具，生成蓝图，最后把分解后的任务做成一个个tickt，做项目跟踪。
+
+相关阅读：[14 | 项目管理工具：一切管理问题，都应思考能否通过工具解决](http://time.geekbang.org/column/article/87787)
+
+alva_xu ：<br>
+ms-project这样的计划工具，适合于项目整体计划的把控，人财物的协调。ticket系统适合于每个阶段任务的安排、变更和任务跟踪。
+
+两者一个全局一个局部，在敏捷项目里应该结合起来使用会比较好。项目整体计划抓大的WBS ，不做过度深入的WBS，而ticket系统可以跟踪管理局部的变更，是计划管理的子集。
+
+所以我的经验往往是先做一个全面的迭代计划（用甘特图）,基于此做人员安排和工作安排，并拿此作为汇报的依据向领导汇报。当然，这种模式适用于项目整体目标清晰，时间节点容易规划、每一阶段工作都容易估算的项目。
+
+相关阅读：[14 | 项目管理工具：一切管理问题，都应思考能否通过工具解决](http://time.geekbang.org/column/article/87787)
+
+青石 ：<br>
+领导常说“大脑是用来计算的，并不是用来记忆的。”工作年头越多，越习惯将平时操作的过程整理成文档，分享给内部成员。
+
+学的东西越多，记住的内容往往越少，将重复或可整理的内容写成文字，保存起来，使用的时候知道去哪里找就好。这也正是索引/缓存的妙处，利用大脑有限的Cache资源缓存常用的内容索引，将不常用的内容存盘，需要的时候再次加载。
+
+相关阅读：[16 | 为什么你不爱写项目文档？](http://time.geekbang.org/column/article/88606)
+
+一路向北：<br>
+我们的项目文档基本上是以协议和流程为主，写这类文档的时候，实际上已经把项目的每一个细节都考虑清楚了，经过几次的review之后，后面的项目实现就是根据文档的内容再继续细化，一旦遇到不太清楚的地方，再回头翻阅文档，也很容易知道当初设计的时候是怎么一回事。
+
+套用格式确实是一个比较好的方式，填空总是比直接写作文要简单的多，而一旦整个空都填满之后，再继续润色，细化那又会比一开始简单些。写文档，记笔记等，用对工具还是很重要的。
+
+相关阅读：[16 | 为什么你不爱写项目文档？](http://time.geekbang.org/column/article/88606)
+
+青石： <br>
+赞同老师的“价值体现在产品之上”。技术能力越强，增长曲线越缓慢。实际开发过程过程又大多是满足需求，而不关注质量。企业雇佣关系也更倾向于成本低、增长曲线高的程序员（大不了用你的薪水雇佣两个），所以就出现老程序员的无奈。那么技术在达到一定程度后（增长曲线减慢，收益比下降），同时横向扩展，丰富自己的知识体系结构，不失为一种保值方式。
+
+技术通过努力都可以达到差不多的水平，不同的是思维方式和所处的高度。不断学习的过程，其实就是让自己了解的更多思考的越多，思考的越多站的高度自然更高。
+
+入门时写代码是为了实现功能，深入下去会想了解它的实现方式，接着尝试举一反三将思想运用到其他地方。培养产品意识也是从全局看问题，站的越高，望的越远。
+
+相关阅读：[19 | 作为程序员，你应该有产品意识](http://time.geekbang.org/column/article/89480)
+
+kirogiyi ：<br>
+程序员的焦虑是自己吓着了自己，一些负面词汇听多了，潜意识里难以平息内心的恐慌（码农、大龄程序猿、996、ICU等等），只想着能赚钱的时候赶紧赚一笔，至于技术进步和长远打算，都只是锦上添花而已，愿意做出一些无价值的付出。越临近这些负面词汇的边缘越是心急如焚，要么逃命去吧，要么留在原地观望，要么综合培养自身硬实力和软实力，前两种会逐渐淘汰，后一种会有顽强的生命力。
+
+宝玉老师这里讲到产品意识，我认为这是一种软实力的培养，它能辅助你的硬实力做出更好的项目，也能拓展自身在技术以外的视野。其实，有时观察下来，技术能力强的人一直忙个不停，可以解决很多问题，问题却好像没玩没了似的；技术能力一般，喜欢沟通，具有一定产品意识的人，上午一杯咖啡，下午一杯茶，安安心心按时下班，轻轻松松交出项目成果。我认为，程序员在一定的阶段，不能只关注自身技术实力的成长，忽略了其他方面的成长。这就像一个偏科的人，永远拿不到第一名，而那些各科成绩均衡，没有一科成绩第一的人却成为了第一的道理是一样的。
+
+有句话，一直记得很清楚：吾生有崖，而知无崖。学新技术也是一样的，不一定死搬硬套要去学会，这样学习成本会很高，但一定要去关注，知道什么时候、什么地方可以用得上，一般有经验的技术人都能在短时间内学会，尤其对大龄技术人员。一旦时间久了，关注的点就不一样了。思维开始转换，然后从更高、更深的层次去考虑问题，才能真正体会到“技术是工具”这句话的深刻含义：工具可以换，思维可以变，灵活多变最重要。
+
+相关阅读：[19 | 作为程序员，你应该有产品意识](http://time.geekbang.org/column/article/89480)
+
+alva_xu： <br>
+InfoQ上有篇文章供参考： 35岁的程序员是“都挺好”还是“都挺惨”？<br>
+[https://mp.weixin.qq.com/s/1q82RO4gRAXtuFeDGV4qRw](https://mp.weixin.qq.com/s/1q82RO4gRAXtuFeDGV4qRw)
+
+实际上，和年轻人相比，在学习能力上，总会有瓶颈。不拼体力、不拼脑力，我们拼经验，拼沉淀，拼吃的盐比你多。所以，我们在成长过程中，一定要注重学习、消化和沉淀，从表层易变部分向底层基础部分转移，从程序员向架构师产品经理转型。持续学习、多学方法论，不断扬弃，顺势而为！
+
+相关阅读：[19 | 作为程序员，你应该有产品意识](http://time.geekbang.org/column/article/89480)
+
+果然如此 ：  <br>
+1.提升需求确定性：设计高保真的原型，如用axure，不仅仅是画框图，还要加各种响应事件等；<br>
+2.提高需求变更的成本：提前约定变更制度，签字画押；<br>
+3.降低响应需求变更的成本：提高技术框架水平。
+
+以上是通过产品、流程、技术三个方面解决需求变更问题。
+
+相关阅读：[20 | 如何应对让人头疼的需求变更问题？](http://time.geekbang.org/column/article/89848)
+
+## 思辨时刻
+
+dancer ：<br>
+管人和管事，言简意赅，受教了! 但是对是否写代码，我个人的看法是，对于一个一线技术管理，比如不到十人技术团队的leader，我觉得时刻保持学习新技术，写写代码还是有必要的。好处一是做技术选型或者评审设计的时候，不会把团队带跑；好处二是做技术决策的时候，更有说服力。总儿言之，就是要有一定的技术领导力。
+
+宝玉：<br>
+你这个补充很好，我在文中说的有点绝对了，客观一点说法应该是尽可能保持一个合适的比例！但管理的团队越大，职责越多，那么要写的代码比例就要越少。
+
+相关阅读：[10 | 如果你想技术转管理，先来试试管好一个项目](http://time.geekbang.org/column/article/86375)
+
+好，今天的加餐就到这里，非常感谢同学们用心的留言，也希望我们专栏的同学都能每日精进，学有所成！
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。