前一段时间才看了躺在书单上挺久的《刻意练习》，书中提到的练习方法其实跟以前读书时老师教的也差不多、另外讨论“基因差异的真正作用”的角度也挺好。但自己印象最深刻的是书中讲怎么 “保持动机” 以解决 “新年决心效应” 和相应地 “意志力根本不存在” 这个事情。
虽然书上道理没错，但其实所有技巧、努力和机遇等都是取得成就的必要条件、但大多不是充分条件。所以大概每个行业里知名和成功人士可能都只是该行业人数的百分之一左右…其他绝大多数是普通人、虽然也学习和付出了很多，但籍籍无名、没做出响当当的成就。
另外，最近公司内外有一些热议的关键词：996、拧螺丝、非我莫属… 目的都是在鼓励员工要拼命、要担当。大家其实都能理解其中意思，但也发出了很多不同的声音、没有内在动力做出这样的表现。
以上提到的“保持动机”、“反对 996” 引出这里想说的第一个问题，当然也是最根本的问题，就是经常被提到的“初心/源动力”。
初心
十九大把“不忘初心，牢记使命”作为中国共产党的时代主题，这个国家层面的意思还是很容易理解的。不过联系到个人、那句经典语录”不忘初心、方得始终“可能更实在！
在白纸一张的年纪时对“不忘初心”除了觉得很有道理外基本是没有实质感受的。直到遇到些大大小小的当时觉得也是发愿自初心的行动(这里指工作)，慢慢的走了样、逐渐地坚持不下去、甚至有不少拿不到结果而无奈结束，就会反思、当初想做这个事的初心是假的？这个事情本来就不适合做？甚至怀疑选这个职业是错的？能否笃定的把这个职业变成愿意为之终生奋斗的事业？就像从开始的 “初生牛犊不怕虎” 变成了 “拔剑四顾心茫然” 的状态。但最终是需要从茫然中走出去、这要反思回顾下自己过去的一些关键节点。
- 怎么喜欢上编程的，真的喜欢吗？
- 校园里打鸡血创业做团购网站时、学编程实现了当时觉得很神奇的效果，于是喜欢了。不能说不是真的喜欢，只是这跟初心不一定是一致的。那么初心可能是什么？
- 是编程本身、是实现出的神奇效果、还是做出来的产品、还是能借此达到的能赚钱的目的？这些当时并没有想清楚，原因可能是当时除了编程、没有其他觉得更靠谱的选择。
- 热情与初心
- 公司雇你来编程目的是解决问题的、这个过程里当然顺便学到了很多东西，但当长时间都是在解决一个类型领域的问题、难以有显著提升的成就感、遇到明显的天花板、又看到前人在这条路上尸横累累，热情也就难以持续了。
- 工作久了一般要基于过往做过事情的积累寻找新的突破、但历史积累同时也可能是历史包袱，也会有更多来自内心或外界客观限制难以突破。保持热情、会遇到重重困难，甚至需要非常大的破釜沉舟的勇气。
- 机遇与初心
- 你幸运的遇到或抓住了天时地利人和的机会、做出了一些成果，但你回头仔细想想、这是很难得很可贵的。接着很可能会遇到瓶颈、甚至会走上死路，该怎么办？
- 可能被安排了新的工作内容，但很可能不太喜欢，或者你只是配角、做的再好也拿不到期望的结果；
- 可能在可选择的机会中很难发现有特别喜欢的、也更加没条件自己创造机会；
- 可能无奈要换个大方向，但又没把握在新的方向上取得更大的成功，而且要付出前几年的学习试错成本。是不是初心难在？
- 前途与初心
- 可能在初入职场时、雄心壮志地给人生做了规划，但渐渐地发现由于各种现实原因实际经历跟当初规划跑偏了很多，甚至当初的规划本身就是错的、没有可操作的条件和机会。
- 不管是刻意努力还是机缘巧合，你可能有机会做 PM、做 TL、写 PPT 在大会上神侃，可能从中收获了超出预期的进步，但这离实现初心是不是越来越近了？或者你只是沉醉在超越和能管理周围人的自我陶醉之中而已？
大到终极的人生梦想、算是初心；小到一件短期的工作事项、也能有初心。你的终极梦想是什么？这个梦想是怎么产生的？在走向她的过程中有没有变化过？有没有怀疑过是否正确？实在难以实现怎么办？也许很容易把短期的想法当长期的梦想，也许这一切问题都没有标准答案。也许反过来想想、如果在“错误”的道路上坚持走了一生，那或许这不是错误、而这就是你正确的理想吧。
日常工作
动机和初心更多是听从内心、自己把握，而日常工作事务的方方面面基本都是一项项技能、就可以通过”刻意练习“而获得。在大篇幅讨论了”初心“之后、最终落到实际的日常工作中来。
这里不讨论具体的某些技术、技术学习方法，而是讨论一些都会遇到的问题。
团队阵型
我们经常说到的”以人成事 以事聚人“应该是互为因果的关系、但最终还是要围绕“事”出发。日常工作的事、就是一块块业务、一个个产品，能牢牢把握住事、把事做好，结果肯定也就好。
公司团队阵型也是基于此的体现，除了少数的“基础设施/支撑型”横向团队外、大多都是垂直的业务型团队。团队老板就是“业务架构师”，也是团队里业务和产品真正的 owner。
个人觉得：某产品创始人(或pd) 是 80% 的 owner；主开发、运营是 60% 的 owner；其他角色不是 owner。
但因为奖罚机制的存在，团队里各个角色都会想法设法做好分内/外之事，总结一些做法参考：
- 先认清自己的位置、清楚自己需要做什么。
- 做出一些好的行动，对分内事做到让团队多数人认为的优秀“极致”(毕竟没有绝对的极致)、并对分外事产生一些实际的影响 (比如通过技术手段洞察业务或产品的可改进之处，注意不一定是越俎代庖做责任外的事情)。
- 再通过做分享等方式、让团队的其他人认可你做的好。如果能帮到团队其他人、那除了收获点赞外还能收获尊重和喜欢。
我们经常会碰到很多会做事的同事、除了专业能力外也有更好的为人处事软能力，往往不用太费力、也能把他负责环节的事情做好。
需求管理
我们可能不是专业 PM，但都要面对“需求管理”这个问题。工作中各种事情都可以看做是需求，常见的比如：
- 长期的产品维护、业务支持。
- 中短期的项目开发、产品功能、运营需求。
- 定期的技术架构升级。
长期业务支持，最好有计划、比如月度计划，主要方便 review、对焦主要目标或最终目标。这不是为了“每月/每周”一定完成什么，因为实际会经常遇到项目延期中止、穿插进其他需求等变化。
中短期的项目/产品开发，是我们日常工作的主旋律。而项目类型和要求的多样、也带来了不一样的问题，这类似普遍都说到的“效能”(时间和质量)问题，有没有好的规划是解决问题的关键。
-
有规划：比如部门“财年计划”列的事、都会画出各个里程碑的详细时间点和相应完成度，问题拆解的好、结果也可预期，也就几乎没有效能问题。
-
无规划：业务线里很多事情不是在财年初就能明确规划好的，这就很容易引起不同程度的效能问题。
-
问题“少”的：比如半年内有规划；产品发布日期相对宽松或可变，每个阶段时间都还算充裕、各个环节有时间打磨好，总体可以按部就班的展开，真正完善好了再发布。
-
问题“多”的：比如意外的运营需求、重大 bug 等；可能一会儿来一个，但发布日期是确定的、开发周期是倒排的，由于压榨了各个环节的时间、几乎肯定会导致完成质量不好。
-
还有一些“优先级突然拔高”的需求插进来，结果是打乱计划、容易导致整体目标难完成。
-
通常项目研发流程中，PD 管理需求和串业务流程，PM (一般项目后端开发同学兼任) 协调各方确定各个环节的时间点。比如关键时间点有：产品 PRD 定稿；设计定稿；完成开发、设计和产品验收通过、自测完成(提测)。项目的“时间风险”是最常见的问题，原因无外乎 “需求变更”、“评估不准确”、“实际投入度/熟练度”，具体来说：
- 需求变更，比如有没有穿插增加小需求、过程中需求实现的方案是不是比预期更难。
- 过程中投入度减少、难以全部完成，最好的办法是跟 pd 梳理各个功能点的优先级、优先保障重点功能，或者加人。
- 测试的质量，开发“自测”的质量越高越好，而专业测试、要对异常操作的 case 保持敏感，不然最终还是导致返工问题。
- 靠谱的测试同学能把开发自测发现不了的问题给测出来，甚至和开发同学一起 review 理解代码，从代码里结合自己的测试用例寻找 bug。
- 预发和发布，预发布时会有不少复杂三方依赖问题要处理、流程要审批，经验多的老人能高效完成、而新人来操作可能要多花两天踩坑时间、才能发到预发环境。
关于“评估不准确”、“实际投入度/熟练度” 这是相关联的重要问题，也举一些实例：
- 作为开发主 owner 要评估工作量、比如 20人日 完成，如果 2 个人投入，肯定不是 20/2 = 10 天就能做完，协作成本必须要预留出来。要考虑合作伙伴的技术能力、相关经验，确保底线。
- 要求合作伙伴做到负责的功能模块，高质量自测通过、专业测试通过，甚至继续要跟进到预发、发布。
- 要考虑到合作伙伴工作 “并发” 问题，比如他在这个项目里只能投入自己 30% 时间，但落到实际去准确估算这时间是很难的，一般会需要加班、需要超出预期的投入才能完成任务。这时候也要将心比心地帮伙伴解决这些问题。
- 最后，各方都需要注意：确认东西要慎重、不要轻易答应，而一旦确认、要无理由地如期完成，不能最后在汇报进度时、说自己这个点有风险，让人对你的信赖打折扣。
总结
回到标题和前半部门说的“初心”，大多人可能就是通过“刻意练习”对某个事情达到很擅长的程度、再有持续正向反馈的加成，那么这个事就变成了他的“初心”，慢慢变成了明确的人生目标。
但其实人生也可以有多个不相关的大目标，有时候不能一条道走到黑，而且精彩之处也是体现在变化中。这个过程中需要把握住什么机会，可能要经过很纠结的深思熟虑、也可能是一念之差，最终就改变了人生的航道。
最后活在当下，每一段正在走的人生旅程、大概都会遇到上边说的日常工作的问题和解法，这些观察、总结、记录，就是对这段旅程的热爱的体现吧。