在这篇文章中，本文作者介绍了自己的产品开发经验和使用的工具。他们的做法是以周为单位，不断与利益攸关者进行沟通，进行一次次的“冲刺”（sprint）。当然，我们也可以比较一下项目管理软件公司Basecamp 的做法。
之前我们讨论了定义产品的艺术，这是把产品推向市场之旅（或者说实现梦想）迈出的第一步。在你定义了MVP（最小可行产品）之后，你就得开发这个东西了，否则的话它不过就是被扔到四维空间的又一个想法而已。
我们的团队一共开发了数百款产品。以下就是我们的开发做法。
首先，你需要记住一个很简单但非常重要的概念：产品会演变。不，我说的不是上市产品第一版和第二版之间的区别；我说的是你开始开发产品前所定义的东西与你想要发布的东西之间的区别。
我们就拿房子来举例：
要造房子你首先得制图，包括立面图、平面图以及水电图等。既然房屋房间这些都是司空见惯的东西，所以准确定义你想要什么应该不难。我们往往会这么描述需求：
我去过Claire的家，我想要其中的一张餐桌，但是我想放到餐厅去。
很简单对不对？都不需要测试。如果某张桌子可以放到厨房的话，大概放到餐厅也没什么问题。但是如果你要创建的是此前从来没见过的东西并且想把你见过的东西放到里面去改怎么办？
我看了CNN的网站，我希望把其中一个好看的新闻消息框放到我卖水果的网站。
等一等……把一个新闻消息框放到卖水果的地方？
也许可以吧，但有些事情需要先确认一下：
想要它是因为必要还是好看？
它跟设计和信息结构适配吗？
它可以给网站增加价值吗？
这么做对于用户来说有没有意义？
这听起来有鸡蛋里面挑骨头的味道，但是已有研究表明，用户对你的网站产生第一印象只需要不到1秒钟的时间，而且仅仅是从美学的角度来进行评判。你需要让他们享受到美感，而网站需要专注于完成目标。幼稚的产品业主认为自己可以让他们的产品“好看”，然后用户就会自动爱上它，却无视了体验之糟糕几乎并不可能使用的事实。
为了汇总所有的产品需求，我们首先用Trello把主要信息收集起来：
这些被称为是史诗（epics）。基本上属于非常宽泛简短的独立功能描述。是对我们最后产品所需的所有功能的高级视图。史诗使得跟产品主管的对话更容易些，双方的交流可以涉及更多的细节，比如：
“你希望保存哪一个产品字段？”
“用户应该怎样编辑页面外观？”
“搜索功能应该查找哪些字段？”
……
只要我们做完了这些，我们就会通过客户来加以验证。并且开始编写用户故事，也就是每一个动作的特定步骤。许多用户故事都由一个史诗组成。这一阶段至关重要。用户故事让我们可以讲述故事，这往往能让我们捕捉到之前仅仅列举高层功能（又叫史诗）时未曾想过的问题。最重要的是，它让我们可以从用户的角度审视产品。这帮助我们识别用户可能遭遇的问题或者一开始未必明显的边缘情况。然后我们就可以跟产品主管和客户一道评审用户故事，确保我们已经准确理解了这一愿景。作为一个初创企业的孵化器，在产品和软件方面我们是专家，但客户带来了他们的专业知识，他们知道哪些东西是产品上市需要的。
现在，我们对所有的需求都进行过验证了，我们添加了让这事儿发生的必要之物：有用的库，数据结构，API接口，部署策略，服务器配置等等。等我们把所有任务都组织好了之后，再在预先确定好的时间内（通常是每周一次迭代）把它们分拆到一次次的迭代里面——或者称之为sprint。
下面这个是Kanban工作流软件的Trello看板：
然而，估计时间永远都是困难的。这需要一定的科学与艺术的结合：
1）甲：啊啊啊啊！我实在是太不擅长估算项目要花多久时间了。
2）乙：别慌——有个简单的做法可以帮你算，就是做出最现实的估计，然后乘以2。甲：好的，可是——；
3）乙：接下来再乘以2，加5分钟，然后再乘以2。甲：好的……
4）乙：30秒钟过去了你除了把想象的数字翻番以外什么都没做！你一点进展都没有也永远完不成！甲：啊啊啊啊！啊啊啊啊！
每一位开发者都有自己估算开发时间的办法。我们也尝试不过不同的办法，各自都取得过不同程度的成功，不过这些是后面要讨论的事情了。
估算会变更MVP的功能，因为某个功能就会花费很大一部分比例的资源，所以需要小心处置。
在计算机科学里面，是很难解释容易与几乎不可能之间的区别的。
产品：用户拍照的时候，app应该可以知道自己是否在国家公园内；
开发：当然，简单的GIS查找就行。给我几小时。
产品：然后还应该可以知道拍的是不是鸟的照片。
开发：这我需要一支研究团队和5年的时间。
现在一切都已经组织就绪了，我们需要开始实施了。
正如我之前提到过一样，我们的sprint持续一周。在这段时间内，我们打算开发包含在本次冲刺内的所有功能，但有时候并不能如愿。为什么？其实答案很简单：我们无法预测未来。任何一位软件工程师都不能。我们唯一可与预测的就是未来的不可预测性。功能的实现也许会比预期要长，设计/内容/项目经理那边也许给你制造了难题。有一次我们必须用网关来实现支付系统，但在实现的过程中我们发现他们改变了API的工作机制，却没有更新一些依赖。结果：我们需要中断开发到一半的进程，重新跟另一套支付系统进行集成。
在创新领域做往往意味着在未知水域航行。挫折应该是可想而知的。计划就是用来打破的，很少会有项目是最后按照原来计划和“规范”进行的。历史上变化来自各个方向，无论是内部的还是外部的。对我们来说关键点是尽快调整自己来适应这些情况，并且对这个过程保持透明。
然而这并不意味着永远都不应该给遭遇的潜在挫折预留估算时间。当我们的确遇到意料之外的问题时，我们会马上跟团队沟通，试图识别出对时间表的影像。调整时间表并不意味着我们就不能满足最后期限要求，而是意味着我们要不断维持这现实期望。
另一个变化来源很有可能就是客户本身。客户，尤其是牵涉其中的那些，回想看到自己的产品愿景是如何推进的。这意味着他们会经常提出不造原来项目范围内的变更请求或者新功能要求。说出“是的，我们可以做到这个”是很容易的，尤其是如果“那个”东西很小的话。但是小的东西很容易就会累积起来。
这绝不意味着我们就对所有的客户请求说“是”了。我们给这个领域带来的价值之一正是我们的经验和专业知识。如果我们的确推掉了某个请求，那一定是因为我们已经研究过了，找到了它的一些例子，并且能够给出专业的客观理性的反对理由。当客户往往是出于个人喜好而提出变更请求时这一点尤其重要。
跟客户的良好沟通可以让这一过程有效。每一周我们都会打一次电话，解释以下事情：
完成的有哪些事情，未完成的又有哪些
我们面临的问题
下周预计要完成的事情
如果我们遇到任何障碍的话新的时间表如何
这样的话我们就不需要给我们的时间表增加任何“缓冲”了。
这个每周进行的系统对于验证一些可视化功能、流等来说也是非常重要的。还记得我说过产品正在开发中的变更吗？这往往就是变更发挥作用的地方了。一旦你看到自己想法成形时，你可能就会发现有更好的办法去做某事，或者发现一开始看似很绝妙的点子其实并没有那么好。这一路上进行短的冲刺和验证可以有巨大的好处，因为有了不断的验证和输入，让产品主管、客户、工程师最后都会产品感到满意。
我们在 Codelitt 就是这样来处理产品开发的。当然，要处理的还有很多东西，比如QA流程，与客户验证，把产品发给产品部门等，将来我们还会在新的文章中讨论这些东西。
