背景
本月读书会的书籍是《隐藏的潜能》，作者是亚当.格兰特。
主动寻找不适感
需要通过主动寻找不适感，从而实现快速的成长，对我们来说不舒适的比较抗拒的很多都是我们自己比较薄弱的地方，而主动连续的寻找这种不适感，给我感觉有点心理学的“暴露疗法”的效果，通过克服心理做不好的恐惧，从而 积极努力迈出自己的每一步,我读书后的生活实践:
1.不喜欢主持会议，推动事情有进一步的进展 一点一点循序渐进的逼迫自己，先简单准备一下会议上需要讲解的材料，然后再定一个会议室，再定一个时间，通过一步一步的去逼迫自己迈出心理的那个障碍
2.主动和上级沟通 向上管理和向上沟通事宜是我非常不喜欢的一个事情，主要还是在于自身心理担心让上司觉得我没有能力,同时我的上司本身也是个只喜欢质疑怀疑觉得自己人团队能力有问题，在与外团队沟通时,更不喜欢站在我们自己的一边 但是，这个其实与我无关，从上一本书《被讨厌的勇气》当中我学到了一个“课题分离”,我有现在意识到，外界的困难很多来自我自己的想象，让我恐惧和退缩；本月也完成了一次被骂了好几次的数据的一次向上沟通和平级沟通
主动寻找不适感，尝试不惧怕犯错，让自己快速得到成长；许多事情，可能就是买过一个看就平坦很多
给团队下属建议，从而自己有收获
通过code review 与团队成员沟通，分享经验，同时也分享了一些我自己的思考，其实更多是在锻炼了自己的一些能力
成为不完美主义者
这个其实在软件的项目管理中是比较常见的概念,做事先完成60分，给用户一个最小可完成版本，再根据反馈和情况继续往下，避免思路是错误的，或者想要完美导致开始不了
复盘
1.隐藏的配置，对用户来说没有暴露出来，很多时候配置的不及时更新就会导致用户操作一些配置联动的按钮造成不便的影响 2.在大家后续的讨论中打算落地一个业务的配置中心用于暴露给用户很多通用化配置 3.可基于编号2我们又会引发一个问题，很多业务配置，真的该做成一个配置吗？或者说他合理吗？
Round 2
而再一次过去一段时间后，最近又一次同样的事件，同样的抉择出现在了我的面前，我们的项目中出现了针对开票出现了两种方式，一种是线上正常走供应商接口开票，一种是走导出线下开票，而这样的功能全部希望集成在一个“确认开票”按钮上，针对一系列的判断，来判断其到底为线上开票还是实际该走线下导出；而初期的评估时看起来没有任何的问题，可中期突然意识到对于TO B的业务而言，很多事情是比较灵活的，在我设计将“确认发票”这个按钮和不同票种绑定触发不同行为时，整个事情就变了，向用户隐藏了逻辑的同时造成了后续的很多不灵活性，比如用户突然遇到某些事就是希望通过线下导出开票，此时一切就都变了；由于我们功能的不够灵活，用户的业务就因为软件的限制而受到阻碍。
再次想向“魔抓”伸向apollo？
此时，身为开发的DNA又动了起来；我开始想的如果遇到操作不够灵活，导致我们需要再一次的发版，这样的成本虽然我们承受的起；但是也许我们的灵活度如果可以更高的话所有人的时间都可以更多的节省掉。留个后手，留个可自定义的配置，或许一切都会变得简单不少？但是此时我还是控制住了自己，不能反复在一件事上重蹈覆辙;也许我这样的做法，短期确实可以使得我们的开发一次性节省了成本，但是我们在基于不修改原型的基础的设计，基于前几次的经验，很有可能会实际上也并不那么好用，同时也隐藏了只有开发知道逻辑和留下了忘记关闭开关，就会造成线上功能不正常的风险……
与产品的二次协商讨论
在基于以上的分析后，我将我的顾虑和产品大佬进行了和盘托出了解相应的解决方案，得到了一个我从来没有想过的方式，将原有的按钮拆解为两个，由用户自己决定各类的发票该导出还是走线上系统，我突然发现有时很多问题，换个角度可能会变得非常不一样；我们站在开发的角度来说，用户的需求和产品的方案就是不变的静止的，我们的浑身解数都是为了能够原原本本的呈现;可实际上，有时简单的调整方案，我们的实现难度和代码的逻辑的清晰度，可能大不相同,而改成两个按钮看似平平无奇，可是，实际上我们的代码层面完全可以实现拆解，并且两类逻辑的触发，从写死的if判断也变成了按钮，可以让用户按照自己的想法去决定实际使用哪一个功能
总结
1.有逻辑的配置最好和产品进行沟通，我们是否真的需要这样的配置？ 2.有时我们的很多思路都是站在自己职业的一个立场上，可是实际上我们换个角度或者站在更高的角度去看一些问题时,可能答案就呼之欲出了 3.文中还有一点是没有分享到的，就是虽然为了这个通用化的设计，引发了很多交流的讨论，收获了新的思路和方案，但是项目进展中途改方案真的是大忌，我为此付出了巨大的代价，真的是为自己狠狠的上了一课
