看见的力量 – (I) 解题的思维

本文转自台湾李智桦老师的博客，原文地址

这篇文章；已经梗了我三个多星期了。这期间飞了二次大陆做演讲、往返几个大城市做教授敏捷开发运用在精实创业的课程。教材内容都是简体的，它们始终没有机会在国内用上，心理常想着；无论如何我都要把它们翻成繁体中文，虽然国内没有人找我讲这个课程，没关系。就把它登在大众媒体，跟大家分享。(哈哈! 写了几回草稿，但旅行中杭州的云雾缭绕还有茶香美景并没有帮上忙，文章架构依然凌乱，倒不是没有头绪而是头绪太多。最后我决定改用分段的方式来跟大家分享，希望你能接受。)

【 看见的利器 】

※「看板方法」Kanban Method

可以让我们看到工作流程，然后依据半成品的理论来持续改善、管理流程。

※「用户故事地图」User Story Mapping

可以帮助我们阶层化使用者故事并整理出需求的全貌，让我们知道该从哪里开始来解题、动手实做项目。

※「影响地图」Impact Mapping

可以把业务目标跟产品功能串接起来，然后让客户、分析师及开发团队都能看见撰写的产品功能对业务的影响在哪里。

好了；这一系列文章就是在谈上面这三个东西，三个可以协助我们看清楚需求的工具(方法)。标题似乎可以改写成:如何运用这些方法来看见需求的本质。而想谈的问题是；藉助可视化 Visualize的力量来解决项目开发时需求变来变去的困扰。用一张图示，来说明这几个工具的运用时机。(一下子；轻轻松松便可以画完的图，但改用文字来描述起来还真是有一点麻烦。我想用如何思维解题，到过程的描述分析，然后在对应到想要完成的目标，最后是拿来辅助的工具来探索它。顺序就是依照下图最左侧的那一行【思维
– 过程 – 对象 – 工具】)作为一系列文章的起头。

第一排；思维的方式

由「极度抽象」到「抽象」再到「明确」最后写成程序代码，达到「极度明确」的解题方式。

这是我惯用的一种解题方法。解题；一开始；要先后退个几步，让自己跟问题对象的距离先拉远一点，减少一些讯息数量的干扰，让自己的视野再加大一些，能看得更全面一点。目的是；设法看见全貌。这可是自己花了好多年的时间才纠正过来的习惯，避免患了一看到问题就急着思考如何解题的习惯，就是俗称的「工程师的视野」。

在抽象与明确之间徘徊解题 –持续优化

想办法先看到。当你经常受到需求改来改去的残害时，最好的解决方法便是让它提前优化，运用paper prototype 或其他成本较低的方式先行对问题的解答进行验证，针对产品功能是否解决了真正的业务需求进行模拟或假设式的确认。我习惯在这里来回穿梭，宁可多花一些时间在抽象与明确之间徘徊，也不愿意太快进入程序的撰写阶段(你可以先做未来展示时会用的PPT，或就手头的需求先整理一些Spec，不要急着收敛)，这倒不是在逃避写程序，而是担心一旦开始写了些程序代码，要回过头修正假设错误的地方，就要多花一些功夫在修正程序逻辑上头，这要赔上许多时间，有些划不来。而且程序一旦改来改去，总让人觉得好像有一种坏味道油然而生(有些不卫生，不干净的感觉)，还是慢慢来，一次做对比较干净舒服些。

倒推的方式是最常用的手法。也就是所谓的从最后开始(Start at the End)。先想象你已经完成文件上所陈述的功能了，然后回过头来看看问题是否真的被解决了吗? 试着问自己；用户因此就可以如同用户故事上所描述的「因为获得了他想要的功能，从此以后便能获得这样的利益了」。(当然，用影响地图在这里最为受用，请容我下次再补做说明)

针对较头痛的问题，我通常会采用寄信给自己的方式，用email藉由时空的延迟隔离，来和自己交谈(一种自己给自己的回馈方式)，用说交谈的方式来进行自我回馈，用这种稍稍客观的形式来提醒自己，让时间带来多一点的信息获得，也就是依靠延迟决策的方式(Decide as Late as Possible)，让思维更为成熟一些(哈哈!很难说这种方式会有用，但一经养成习惯，心态便会稳定需多)。

明确到极度明确

第一步；先确认文件规格是正确的。我习惯先整理足够用来做coding用的文件规格(可以用测试案例(Testcase)或是单元测试来当作文件)，先把测试的方案开起来做好命名，最后才是建立主程序项目，这里才是接下来的战场，这种方式有人就认为是TDD了，但我实际上只是要透过预做准备的动作，来多思考一次也就是击发二次思维(2nd thought)的动作而已。接着才是兴高采烈的进入coding 阶段。期许自己能够一次做对，让coding
变得更有趣，让code变得越简单越好(侦错)。

小结

针对上图所示，我们先谈第一排、所谓的「解题的思维」。解题；它没有标准，上面是我长期以来一直依据的Mary shaw 抽象解题法的使用心得。提供大家做参考，下一篇就会开始描述处理需求的「影响地图 impact Mapping」。会这么做，是害怕自己没有足够的时间做长篇大论，就以这种分段描述的方式，尽量抽空来做作功课了。

---

请关注微信公众号 【devopshub】，获取更多关于DevOps研发运维一体化的信息

​