在组织团队开发，负责项目进度过程中，自认为有思考有原则有行动，意识中没有为了圆场或奉承或推责任而做了违心的言行，但与同事协作调度安排工作时，被调侃言行不一；他的表述是诚恳的，我也感觉到上一刻的言语与此时的行动确实有些出入，所以需要反省下。
原子操作原则，就是某件事一旦开始，就一直做完，不是时间上的坚持而是工作流；工作中有忙不完的事项，更有实现不完的好奇想法，但着手行动了内心就会无意识坚持这个原则，而这个原子可大可小，当然原则是可以被外力打破的。
举例，升级 API 接口工作量需要两天，我就会在内心里想着一口气坚持下来把它搞定，但这是不现实的，各种会议、各种协作、各种电话，可能忙了一周才完成，其间还完成了其他项目的相关环节；我知道应该继续处理接口的事项，只是在坚持原子操作原则时总被外力打断。
这个原则是需要内在驱动力的，为什么 API 接口要升级，不升级会怎么样？其实不需要全部升级，只需要调整某几个接口即可满足工作的需要，但想让接口更规范、更健壮、更统一；而别人需要我协助、联调、会议的事项则有时间节点，与人协作，有种被动因素，相互尊重，做完是本份、做好是素质、做极致了是能耐；想做好与能做好是两个层次，在能做好并在做的过程中，这个原则一直在坚挺。
功能要迭代，不要追求 0 到 100 分的跳跃，在团队中不时会表述这样的言论，其实我是不赞同的，能追求到 100 分时为什么还要 99 分；若我只得到了 60 分，请相信我付出了 100% 的汗水，只是能力有限而已；
是的，得分能力是前提，在现实中这是每个人/团队的能力属性值，不是谁标榜的；与团队相处这么久，得分能力也能感知到是什么样的级别，去追求超出自己能力的极限，请在与客户约定好的时间内完成；与其说功能迭代不如何说技能迭代，与其说追 100 分的高度不如练就得 100 分的能力。
这句话只是个安慰，我只是想在项目进程中的节点上看到应有的功能实现，而不是仅仅追求更好的状态；违约过，被留宿过，我知道 100 分不是很遥远，但 60 - 80 分很靠谱。
言行不一，服务器端升级了接口，移动端可升可不升，但团队未经安排就动工对接升级后的接口了，这是值得表扬鼓励的；但三天后就要升级整个应用，升级接口需要耗多少工时、是否会影响其他功能的开发进度等应用升级的节奏？
团队成员工作经验相对都很少，上述说的得分能力自然有限，为了保证升级应用的时间节点不受影响，团队复盘时建议应用发布后再升级接口，但同事拒绝了：已经完成 90%，为什么有更好的实现方式还要用旧的？；不同功能不同代码分支，未完成的 10% 接口可以在应用发布后继续完善，不晓得为何大家那样抵触；有限的时间、不可估的升级接口工时，很想拒绝这样的执行方案，但还是没说出口。
周六复盘时都说完成了 90% 的接口升级，但今天却无意间看到代码中依然在使用许多旧接口，感觉受欺骗了；原子操作原则像一面旗帜插在心中随着气息飘扬，既然坚持了升级接口，为什么不一鼓作气全部搞定呢？而同事在我的调度下半闻不听，没有复盘时坚持升级接口的半分自信，自然而然就会让联想到得分能力；不由得给人错觉，坚持升级接口是因为代码管理不当无法全身而退的切回原功能模块继续推进，此时又半推不就的搁置部分接口的升级是时间/精力/技能的协调不当。
于是同事调侃我，前段时间刚说过功能开发要迭代，而此时我又在追求 100 分，确实自相矛盾；站在整个产品的角度，坚持接口的统一只是很单一的原子操作，做好了不加分，做不好要减分；用户用到的是产品功能，功能稳定了才是用户体验，而升级接口非迫不得已，不应该在应用升级前一周内动工，当然若技能超群，时间不是问题；
关于产品功能开发的进度安排需要好好思考，什么时候需要坚持，什么时候需要讨论，什么时候需要出成果；后悔的是复盘时没有坚持拒绝接口的升级计划，庆幸的是下午坚持了所有接口升级。
与客户约定好的应用升级，由于报表样式问题而未预期发布...
需要继续思考：
- 如何定制计划让团队成员熟悉了解项目中与自己职位相关的每个功能模板及接口
- 如何改善自己/团队的工作事项交流能力
- 技术人员能力的判断，及如何给出合理的建议
日后回头看时，会不会认为大动作前随意升级接口，各版本接口随意共存？
客观的自我技术评价：在能力范围内时有技术洁癖，能力范围之外时能搞定就不错了；对技术的追逐而又能力有限时，时常感到绝望。
