在捷效项目开发的过程中，有过不少的坎坷和问题，来源繁多，有开发的、管理的和理解沟通上的。学贵大成，不贵小用，大成者参与天地，小用者谋利济公。以下观点，纯粹是作为一年来捷效项目的一些个人总结，抛砖引玉，还请指教。
一，问题不可怕，可怕的是产生问题的问题得不到解决
软件系统的问题往往流于表面，头疼医头脚疼医脚，而本质产生这些问题的来源往往得不到最直接的表现，比如是产品调研、规划出了问题，还是开发者的水平问题，又或是工时、工序安排的不合理。总之，问题纷繁杂乱，诱因各有不同，表象问题解决的了一时，但诱因不分析透彻，只会在错误的路上重复类似的问题。复盘很重要，解决真正诱因更重要。
二，需求是业务，但系统设计永远不是业务规划。系统设计偏重技术方案，但技术方案应该完全覆盖业务
产品在早期需求分析阶段，应该彻底的按照已有业务和市场需求以高度还原业务场景为前提进行如实的记录和分析。而后这个过程应该尽量脱离业务场景，以更加抽象和解耦可配的方式实现最终目标的达成。说的简单点，就是先置身其中，充分理解和熟悉，再跳脱出来，以航拍视角俯瞰全局，不识庐山真面目，因为你身在其中，除却巫山不是云，因为你看透本质。这个过程其实对产品规划者要求非常高，着重于业务，会让系统规划僵硬，没有变通和灵活性，着重于灵活性，又容易第一时间脱离业务，实现难度和复杂度陡增。所以规划一个可配型、可拓展性强又好用的系统是件很难的事情，但这种规划值得尝试，因为谁也不能保证变化不会发生，变更可能随时随地在发生着，将变化控制在方案范围内，显得尤为重要。
三，工时、方案和质量
做任何项目基本都逃不脱这三个因素，它们之间有着微妙的关系。方案的难易程度，基本能决定工时和质量，方案越难，实现工时越长、质量越难控制，为了让质量少出问题，规划、测试、实验的工时会增强，从而让原本就会长的实现工时额外增加了更多工时。假设方案确定了，工时和质量又是反比的，人天越少质量越差，或者说上线周期越短不可预见甚至已知的问题会越多。那么应该给方案找一个最好工时和质量的平衡点吗，理论上是这样，但实际上很复杂。如第二点提到的，方案可能来自业务需求，可能来自甲方的要求，或者受限于预算、实现难度等等诸多因素，但在所有变量都落实确认后，总的原则还是以最小的代价，尽快实现预期目标，尽快验证设想的商业模式是否靠谱。
四，人是根本
对于软件、互联网这个行业，基本没有额外的生产力，如果说其他行业还有工艺、流水线机器和作业标准，那这个行业可能更多的是看人。人基本是决定性因素，人决定了技术方案的天花板在哪里，人决定了要用的工具、界面样式、品控、功能，甚至结果走向。软件项目管理的本质就是人员管理，术业专攻各司其职，在岗位工作要求的基础上，最大限度发挥每个人的专长，最大限度强调创造性和创新意识，严守实现和控制流程，才能最大限度的发挥个人能动性和得到好的预期效果。因为团队人员有这么重要的决定性作用，所以团队凝聚力，目标认知，每个成员的特性、心理建设、各自的诉求、影响力、执行力就显得尤为重要。
五，严格按照单向的流程开展所有工作
产品规划定稿前可以做需求分析、头脑风暴、评审讨论，但一旦产品规划定稿，而后就严格按照界面设计、研发、测试、验收上线这个过程。整个过程中出现任何异议、变更都回到最初的起始点继续单向流转。这么做的原因是为了控制需求来源分散、开发过程偏离主线，多方向交流造成扯皮和效率低下。
六，原则
低耦合高内聚，Keep it simple and stupid, 充分的异常和失败处理，能实现自动化的都自动化(测试、打包、发布)，这些是已知范围内的一些原则。在项目的推进过程中，还有一些新的体会，比如在整体技术方案敲定的前提下，具体的功能实现，要保证业务第一、体验第二、实现第三的原则，在满足业务刚需和用户体验后再定具体技术实现。依据这个原则又可以衍生出来其他原则，比如为了保证业务和体验，减轻不必要的损耗，同一个界面以不同的目的进来时诉求不同，产品设计和技术实现就不同，在满足诉求的前提下网络请求的体积越小越好，响应和渲染速度越快越好，规划细到懒加载的级别。再举个例子，我们从苹果和高德得到的启发，在客观确实无法满足或体验需要极致时，用社会工程学的思路变通解决诉求，之前在泛华大厦时用了一款路由器，搬家到开发区后所有iPhone手机连接到这个路由器后获取的定位都依然是老的泛华大厦，原因是苹果认为路由器挪动的可能性低，而手机快速获取定位的体验感诉求很高，以高概率诉求博低概率事件。同样的，高德地图在有网络、GPS的情况下获取到了位置，但当关闭网络、GPS后依然还能获取位置，可能也是在分析了时间、步数等传感器参数后得出结论，你离开这个位置的概率低，而你需要快速获取位置的诉求高，以合理的逻辑和阈值获取更高的速度和体验，这是我们在尝试的方向。
七，容灾
互联网的可信度是相对的，不是绝对的。上边提到的异常、失败需要提前规划的原则，除此之外还提到了用一定变通的方式解决类似弱网这类问题。但真的出现灾难级别的事件，比如服务商出了问题，网络环境出了问题，我们实际上无能为力，那么在这种情况有一定概率发生的前提下，能够多大程度接受所带来的影响就变得尤为重要。一旦接受程度极低，或者说不能允许这类崩溃事件存在，那就得做容灾方案，起码要在真的无能为力时有个相对能接受的出路。
以上只是随笔总结一下个人感受，难以概全，目前捷效办公实际上已经发展成了后端接口项目、前端网页项目、Webview移动端项目、Android项目、iOS项目、Electron桌面客户端项目、打印盒子的多项目产品。问题修复，新特性开发，上架的新挑战，我们每天依旧在路上，依旧忙碌，且面带笑容。