反思自己

做自己的手机应用并销售，到现在，大概有 3 个月的时间了，特别是新版本出来的 20 多天，用户反馈好用，感到很欣慰。

在这个过程中，有很多体会，可以写很多东西，但是，无论写什么，似乎都不如写教训更能让自己得到思考。

教训一，产品策划经验为零

从产品策划开始，发现，作为一个执着于技术、自认为对各种软件应用都有广泛了解的自己而言，竟然没有一个可行的何种产品的想法，而第一想法却是，自己能想到的，似乎别人都做过了，而且有的还做的特别好，而自己能想到别人没有做的，看似好炫目，好自豪，平静下来仔细想想，其实都行不通。

结果是，在从事某一个行业的朋友那里得到了合理的建议。

教训是，某种产品和某种业务是紧密相关的，不懂业务，只知道编码，无法写出这类业务的好应用的。

教训二，自认为技术就是设计

当朋友提出可以做一个类似的应用的时候，我开始衡量对方的应用，衡量的标准完全是基于技术上能不能实现，如何实现，以及技术上能不能做的更好，得到的结论是，这样的应用技术自己也能实现，甚至于可以用更快的技术实现，还能技术上做的更好，等等等等，所有的结论都是围绕着，自己技术如何如何，别人技术如何如何的小圈子里面思考。

结果是，用自己的技术很快的写好了应用，加上了自己自以为合理的设计，各种丰富的特性，天马行空的样式，等等，然后拿出来给朋友试用，百分之 70 的模块都需要重构，几乎所有的界面都需要按照用户的习惯做不同的设计，自以为特有的特性，必须要删除，而天马行空的样式，因为各种杂乱，最后完全放弃。

结论是，懂得编码，其实圈子很小，懂得编码，还需要了解基本的平面设计方法，懂得编码，还需要懂得了解用户的习惯，懂得编码，还需要懂得如何设计好的用户体验。

教训三，沟通水平为 C

很多人说搞技术的不喜欢多说话，我个人看到的是，其实我的沟通水平很差，在开发中，为了让应用被用户所理解，需要用户的测试，所以，需要经常和朋友沟通，这个时候，在诸多的问题上，就会有许多的诸如，这个地方我认为应该这样这样修改，那个地方我认为你做的不好，等等的意见。

作为技术，当看到一大堆修改意见，看完后，我的第一反应，竟然是，其实你不懂技术，哈哈，真是这样的，还没有开始了解用户的需求，就已经开始自以为是了。

因此，未了解情况，就开始马上回复一封信给用户，详细的解释自己那个地方是如何想的，为什么这么做，那个地方是如何思考的，为什么比较好，等等。

然后，接下来，就是用户发来第二封信，开始对某个地方为什么好，为什么不好，开始争论。

一直到来回发了好多封信之后，自己才开始反思，到底那个地方出了问题，回头一看。

教训四，不考虑对方的理解范围

用户不是写代码的人，对于代码编写的方式以及成本并没有了解，用户的意见是围绕着自己的经验和认识范围形成的，所以，所看到的，所用到的直观体验等，都会反映出来。

作为技术，我所考虑的不是对方是如何想的，对方能否理解我说的，如何让对方理解我说的等等，而是，随意的用简单的几句话，觉得自己解释清楚了，就发邮件过去了，而在回顾的时候，就发现，自己看自己的回复，好象是一下子就明白了，可是呢，对于不了解编码啊，技术啊，开发啊的人而言，这些说法背后都有太多的背景知识，他们是不知道的，他们所看到的问题，是直观存在的问题，就是需要解决的问题，但是他们提出的解决方法，也许并不是最佳的方法，作为技术，需要在解决方法上做权衡，再提出更合理的方法，而不是，极力的说明对方的方法不可行，如何如何的，还不停的解释，如何如何不可行，直接导致了，用户会认为，做技术的是不想解决问题本身，而不是因为没有找到合适的方式。

特别是，当用户开始询问，为什么那个地方代码不能做呢，为什么这个地方代码不能修改的时候，就遇到了难题，因为很难给用户解释代码的实现细节，代码的质量，代码的维护成本等等的技术问题，看似，一个极为微小的改动，由于涉及到开发成本的问题，作为技术可能不想做，但是，这个极小的改动，对于用户而言，觉得简直是轻而易举的，为什么不做呢？

这就是，教训五。

教训五，不按照用户的思路解释

当用户提出很多修改意见的时候，往往有着自己的理由和独特的见解，但是这些理由并不反映在其文字里面，所以，了解用户的理由和见解，是解决问题的关键所在。

当讨论 A 还是 B 的时候，开始的讨论，都是你建议 A ，我觉得 A 不行，我就建议 B ，我还用自己的技术的理解解释一大堆为什么 A 不行 ，B 可以，而结果想当然的是不能解决问题的冲突。

后来我发现，在用户说明要 A 的时候，是有很多想法的，在探讨的过程中，需要按照对方的想法来告诉他，自己对于他的想法的认可，以及开发中所面对的问题，以及过程中权衡出来的方法，并建议探讨更好的方法。

其用意，不是为了表达我对，你不对，其实都有自己的理由，在那个范围内，都是可行的，而真正要实现的，可能面临开发成本的问题，用户体验的问题，等等这些问题综合权衡之后，才能得到一个都能接受的方式。

虽然，如此，问题并没有解决，因为：

最后的教训，自以为是，首先考虑自己，而不是对方

在回顾整个开发过程中发现，根本的问题和冲突是，自以为是，首先考虑自己，而不是对方。

开始，只要别人说自己那个地方的设计需要改动，心里还是觉得是别人不懂自己的设计，其实仔细想想，自己除了懂得编码，相关的设计，用户体验，产品策划等等的知识和经验就是零。

过程中，当别人提出某个地方要做一个修改的时候，不是仔细的了解背景，以及考虑对方能否接受自己的说法，直接把自己认为的解释就发过去，造成很多次的误解。

最后，产品要出来了，觉得自己做到还不错，把前面这些问题全都忘掉了。

结束语

在做自己产品的时候，感到需要学习的知识很多。

最重要的是做人的道德修养的部分，无论是何种错误，最终都会看到是自己在道德修养上不完善导致的，看似无关，其实相关，为什么不能够从对方角度考虑？为什么老是自以为是？为什么觉得技术棒就了不起？为什么，看不到别人的优点呢？为什么，不接受别人想法的优点呢？为什么不能接受别人的批评呢？所有的为什么，归结到底，是道德修养的问题，讲求什么方法，什么形式上的原则，如果没有较好的道德理念，就没有平静的心态，也无法真正提升自己，其实工作就是一个过程，提升自己的技术和修养才是好处所在。

有时候看看社会媒体新闻，当用方法取代了修养的时候，往往就会出现很多骗子，当骗子想要骗人的时候，也会表现的极其善良，极有修养，而实质上，根本没有道德原则。

沟通中，如何探讨方案

在开发中，体会到，应用开发会涉及到这样几个沟通中容易产生冲突的问题：

• 开发成本
• 用户的学习成本
• 用户的操作成本
• 平面设计

往往我们经常说，用户体验的问题，这是一个大的概念，在具体的开发中，用户会产生很多的想法，包括，软件看起来怎么样，如何操作，以及应该容易使用等等，往往用户的想法是交织在一起的，因为这几个问题都是相互联系、相互影响的，例如，从平面设计角度看，有一个叫做亲密性的原则，就是，表达内容相似的设计，尽可能的靠近，虽然如此，这在某些时候，也带来了操作上的便利，所以，在用户表达中，会把这些作为一种想法表达出来。

而作为 App 设计而言，需要分开考虑不同的方面，这样的原因，把问题化解为，平面设计问题，操作问题，学习成本问题，最后还要和开发成本做比较，平衡以上问题之后，得出解决方案，因为每一个问题的解决会涉及到代码的变化，出于开发成本的考虑，哪一个问题可以优先实现，决定了最后的解决方案。

作为沟通而言，通过分解各个问题的不同方面，不同的优先级，能够较好的说明，选择方案的原因，否则，所提供的解决方案，会给用户带来，解决了某个问题，但是忽略了另一个问题的印象。

特别是，当不加思考，直接提供的解决方案不好的时候，会带来直观的用户误会。

例如，在设计添加订单页面的时候，我认为需要优先考虑优化操作，使得在键盘打开的时候，能够尽可能的一次输入数据，降低操作成本。

但是，我给出的第一个方案，严重的影响了学习成本，各个元素所在的位置不符合用户习惯，导致学习成本增加，导致了用户的极力反对。

在沟通了数十次之后，我发现了我沟通的问题所在，并给出了现有的解决方案，才算完成。