继续工作，会待着被打断的不满情绪，然后工作效率降低，原本很好解决的一项工作，被做成了垃圾。然后被上司责怪，自己一个人承担了所有责任。你能去怪谁？怪那个打断你工作的人？
也许有人会说，这是你个人心态的不成熟，与别人无关，不要把被打断当做你是失败的原因。好吧，也许会有人说，这是你弱你有理，反正被打断做不好事，不怪别人。OK，那不怪，以后你做事我也来打断你，然后后面也来嘲讽你，OK？
就像小编我，现在在写这篇文的时候，身边一直有人在BB，而且还在感冒生病中，但却还是有人一直打断我的思路。也许有人试过什么番茄工作法，去安静的咖啡店工作，在深夜里忙碌（小编就是，很多时候熬夜工作）。但是打岔的事，总是用不了多久就会攻破防护罩。
和很多人一样，我也是一个工作容易被打断的人。实际上，我们对于打断这件事以及恢复注意力方法的理解，和顺势疗法以及放血水蛭相差不远。但我们能怎样？
打断的代价
研究过办公环境下打断成本的调查员推测，被打断的工作相比没有干扰的工作要花费两倍的时间完成，并且出错量也是两倍。他们还发现，人们不得不在碎片化的状态下工作，因为57% 的工作都会受到干扰。
对于程序员来说，干扰的影响和现状更不明显；通常被打断后重回工作状态至少要15分钟。采访程序员得出的数字大致相同。然而很多软件开发业界的知名人士已经在权衡：Y Combinator 创始人 Paul Graham 强调了员工日程和管理者日程的不同，37signals 创始人 Jason Fried 说，办公室就是要被打扰的地方。
研究程序员的干扰
基于86位程序员使用 Eclipse 和 Visual Studio 记录的 10,000 个程序会话，并且调查了 414 名程序员后我们发现：
工作被打断的程序员恢复工作后要 10-15 分钟才会开始敲代码。
程序员在编写一个方法时被打断，不到一分钟就会恢复工作状态，所用时间仅为上述时间的十分之一。
程序员一天大概只有两个小时的连续时间不受干扰。
我们也了解了一些程序员应对干扰的方法：
多数情况下，程序员会在重新编码前导航到几个不同位置以重新建立上下文。
有意插入编译错误作为“路障”提示。
source diff 被视为是恢复工作状态的最后一个方法，因为 review 起来很麻烦。
打断程序员最糟糕的时间
调查显示打扰一个人最糟糕的时间是他们记忆负载最重的时候。对记忆负载使用神经关联（比如测量瞳孔直径），研究表明在负载高峰期被打断，分散最严重。
在我们的实验中，为了给编程任务期间的记忆负载定级，我们研究了默读方式。人们执行复杂任务时，可以监测到默读方式（舌头、嘴唇或声带的电信号）。这个现象引起了研究者的兴趣，有些甚至将默读信号比作思想管道。近日，研究者已经可以将这些信号解码为文字了。
如果一个被打断的人可以暂停工作状态或是恰好处于“good breakpoint”，那么被打断的影响就会减小。但是程序员从高记忆状态转换到低记忆状态至少需要 7 分钟。一个实验评价出了程序员最不想被打扰的状态，并发现以下状态最成问题：
编码中，特别是多处的并行编码；
导航和搜索时；
理解代码的数据流和控制流时；
IDE窗口离焦时。
创造记忆友好的环境
我们基本上是无法消除干扰的。（某些情况下，干扰也是有益的；被打断的任务中有 40% 没有继续下去，这可能是因为我们意识到这些任务并没有那么重要，或是干扰让我们有机会重新审视问题。）但是我们可以降低因打断而造成的记忆中断的影响。下一节会介绍几种编程时被中断或高负荷的记忆类型，并讨论支持它们的辅助工具概念。
前瞻记忆
前瞻记忆会在某些特定环境下提示下一步的动作——例如，提醒你在下班路上买牛奶。
各种各样的研究已经阐述了程序员是如何尝试应对前瞻记忆中断的。例如，他们经常在代码中保留 TODO 注释。这种方法的缺点是没什么动力去看这些提示。为了强制性促进前瞻性，程序员可能会故意留下编译错误来确保记得继续某项工作。但是，引入编译错误又会产生新的问题，因为无法在同一代码库上切换到另一个任务。最终，程序员和其他上班族一样，选择用便利贴或是邮件提醒自己。
“智能提示”可以在特定情况下触发，比如当同事 check in 代码时，或是接近提示时，它基本可以看做是代码界的便利贴。
专注记忆
专注记忆可以有意识的保持注意力。程序员跨代码库做相似修改时可能会产生专注记忆——比如，如果需要为了移动组件位置重构代码，或是为了使用新版本的 API 更新代码，这时程序员需要小心系统地编辑所有需要更改的地方。即使是一个小的改动也可能会造成许多问题，所以这需要程序员监测代码中许多位置的状态。更糟糕的是被打断后，专注记忆中的监测状态很快消失不见，之前查看和修改过的许多地方都需要重来。
接触点可以让程序员监测多个位置的代码状态。研究发现使用工具重构有缺陷，其中之一就是缺少跟踪多处代码的能力。因此，程序员抛弃了重构工具而依靠重构时引入的编译错误。可是使用编译错误来跟踪变化不是常规方法，并且依然会产生错误。接触点从程序员使用编译错误的方式获得启发。通过提取所有最近访问、编辑、查找过的代码，接触点可以自动恢复。
联想记忆
联想记忆维持了一系列同时产生刺激的表象间的潜意识关联。
程序员导航到不熟悉的代码时常会感到迷惑。当必须回想所看代码的位置信息或是接下来要看什么时，联想记忆会中断，这就是造成迷惑的原因。研究者相信界面元素中缺少丰富、稳定的环境提示，比如文档标签，会阻碍开发者回忆联想记忆。
刺激中多种形式的存在可以增强塑造联想记忆的能力。从这个意义上讲，形式指一种由大脑的特定区域处理的特定知觉，比如听觉或视觉通路。不同形式和相应的刺激包括：视觉（错误条、高亮代码）、词汇（文件名）、空间（滚动条或标签的位置）、 *** 作（文件的编辑/搜索/调试步骤）和结构（层级文件的逻辑位置）。
当同一刺激中存在多种形式时，更多的通路被激活，因此增加了形成联想记忆的机会。相反，仅有一种形式的单一刺激不易形成联想记忆。
联想关联通过程序元素中多种形式信息帮助程序员；观察程序员可以发现，他们导航时经常依赖环境提示间的联系，比如 tab 和 scrollbar，来保持上下文。但是，这些提示还不够：导航行为经常会扰乱提示的状态，界面元素不足，比如tab通常只包含文件名，急需关联性。导航文档标签的默认配置尤其简朴，通常只显示文档的名称，经过优化，可以增强关联记忆的回想。
两个应用了不同形式提示的标签：如error lines（视觉）和edit icons（ *** 作）
情景记忆
情景记忆是对过去事件的回忆。软件开发者不断地学习新的技巧。保持和使用这类学到的知识需要程序员能够从情景记忆中回想起那些学习经历。
程序员回忆情景记忆时，回想其必要细节或关键事件的能力受到限制，所以一般不会成功。例如，可能会忘记编程任务做出的修改，或记不住为实现部分任务而借鉴的博客等之类的细节。
叙事编码是一款情景记忆的辅助工具，可以帮助程序员回忆上下文细节和编码历史。它支持不同类型的叙事；比如，高度还原事件的 review 模式和给别人发布编码任务的 share 模式。
编码时间轴可以帮助你和你的同事记得各自是如何工作以及使用的资源。
概念记忆
概念记忆是感知和抽象的一种连续。大脑是如何记得锤子之类的物体和“工具”等概念的？它首先会学习所遇刺激的基本特点，比如锤子的木质纹理和金属弧，之后将这些特点组织成为更高级的抽象。
程序员在职业生涯中应该保持专业技能。但是成为专家的路并不好走：对初学者来说，这可能需要 10 年。此外，对于那些尝试成为新领域专家的专家来说，就像桌面开发者转为web开发者，很多概念需要先放在一边，而去学习新的知识。
研究专家和菜鸟间的不同发现，表现不同是因为大脑活动的不同。与菜鸟相比，专家不仅需要更少的大脑活动，而且使用的大脑部位也不同：专家使用概念记忆而菜鸟使用专注记忆。也就是说专家能够利用概念记忆中的抽象，而菜鸟只知道专注记忆中的原始表现。
Sketchlet (alpha)是一款为帮助程序员形成和掌握概念而设计的软件工具，通过支持抽象和检查需更新的概念实现目的。可在 sketchlet.sourceforge.net上进行体验。
互联网行业中，众人热衷于讨论「程序员砍产品经理」。虽然，「砍」更多是调侃的意思，一种消遣工作的方式；但是，这不是一个饭后笑话，侧面反应了产品经理和程序员间的对立关系。很多时候，产品经理和程序员间就像对手，产品研发过程就像打仗，总要争个你死我亡。「砍」的本质，是程序员表达对产品经理的不满，也是一种情绪的宣泄。
在产品研发的过程中，产品经理与程序员对立关系，会严重影响项目的推进。一旦产品经理和程序员对立关系公开化，很容易导致团队人心涣散。这种对立关系，经常滋生出一些极端的事情，骂娘、打架已屡见不鲜。
下文就列举一些程序员想砍产品经理的场景。这些场景都是我过去和很多程序员朋友交流时，他们遇到的对产品不满的场景。这些场景，都会以产品经理的沟通话语表现出来。通过这些场景，去解析这种对立关系产生的原因。以及，作为对照，产品经理应该如何规避和处理这种对立关系。
这样说法是程序员们最不喜欢的，最容易惹毛程序员的。这句话，在程序员们看来就是削减工时、加班的代名词，他们当然不喜欢。而且他们也非常讨厌，一个非技术人员为技术人员做技术难度的定论。简不简单，都需要技术人员做了技术评估，才能下结论。
这种言语，会让程序员们觉得产品经理不靠谱。大家通常都是比较排斥借鉴。借鉴你也得有合理明确的理由。以我某程序员朋友的话来说：微信怎么做的，你就怎么做，那你不如去微信做产品算了。
每个产品，在表面的UI下，都有其背后的复杂的业务逻辑。如果产品经理只是叫程序员照着某个产品做，很多时候技术们是很难实现的，因为他们也需要弄懂背后的逻辑和流程。当然，这应该是产品经理的工作。
这就是抬杠。产品经理虽然名字里面有「经理」二字，但并没有经理的权利，当然不能命令合作的技术们。这句话，言下之意也是拒绝了商量和讨论。而程序员也需要参与感和团队感。
这就是质疑他人能力，是人都不会喜欢。如果产品经理提出的方案，程序员们没有理解。那就说明产品经理的解释说明和文档，做的不够优秀，不够简洁易懂。让程序员们理解需求，是产品经理的基本工作内容。
在互联网产品开发中，修改需求和插入新需求都是挺常见的。对于程序员们来说，这是非常不爽的事情。这种 *** 作通常会打断程序员的思路，思路被打断是非常痛苦的。当然，这样也会影响他们的开发效率。更可怕的是，反复的修改需求，会使他们有种劳动成果不被尊重的感受，同时也会对项目的未来抱有怀疑的态度。反复的更改方案，也说明产品经理设计是未经过严密的论证，或对细节的把控是不够。
程序员都比较讨厌反复的催促。当项目的节点确定后，技术们会严格遵守节点，产品应该信任他们。当然，时间比较紧凑时，反复催促也会加大程序员们的压力，使他们变得非常烦躁。在这种时候，催促就是添麻烦。
甩锅会导致团队分崩离析，人心不齐。不管任何问题，都是团队的责任，不要将责任指定给某人。特别是在项目复盘时，如果心态不好同事，这是非常难堪的。所以，我们要尽量以原因和结果为导向，而不是责任为导向。
程序员也是也是团队的一份子，有权利知道知道需求的背景。同时，了解需求背景也利于程序员们更好的开发程序。
产品经理给程序员们画饼是最不切实际的，只会引起大家的反感。程序员都是喜欢偏实际的东西，虚的东西只会招致白眼。
任何传递给程序员的需求，都是需要有计划和规范的。如果口头传达一个需求，很容易导致开发出的功能与需求不匹配。同时，因为缺乏相关的记录和文档，可能会造成需求流失。这对于程序员们来说，可能就是延迟、加班、返工、担责等等风险。这是团队合作的大忌，也是项目管理不专业的体现。
以上的这些场景，可能出现一次，程序员们都会顺着我们的想法做。但是，这会渐渐改变程序员们的心态，最终会使产品经理与程序员间产生隔阂和矛盾。如果出现这些场景，作为产品经理都需要小心的处理好，以免影响项目的正常推进。当然，最好是不要出现这些场景。作为产品经理，我们的最终目标，都是要保证我们的产品，准时、保质、保量的落地。
产品经理在与程序员们合作时，产品经理需要讲究合作共赢、互相体谅。在产品经理的相关工作中，最要避免的就是抬杠。抬杠是一切矛盾的根源。很多时候，产品经理要站在程序员的角度考虑问题。比如，对于产品来说可能就是改改需求，但对于程序员，他们更在意的可能是因为改需求而导致的加班。
产品经理在工作中，经常会追求产品上的极致。追求极致本身是好事，但是切忌过分偏执。我们也需要考虑团队的现状和资源，在极致和现实间寻找均衡。毕竟，如果没有乔布斯的团队，要像乔布斯一样做产品，只会拖垮团队。
在产品开发的过程，改需求、改方案等项目异常，都是不可避免的。这是项目管理的第一部分。如何进行项目异常的处理，考验的是产品经理的沟通能力和项目管理能力。产品经理需要在保持技术们高效工作的情况下，完成项目异常的处理。
当然，在产品经理工作中，矛盾的根源也并不总是产品经理。有时候，也可能是某些程序员的性格或者对该工作的态度导致的。这时候，产品经理要明确，作为团队的润滑剂，有责任推动和协调大家的工作。如果，矛盾不可调和，我们需要尽早提出问题、控制风险，避免「勉强」行事。
有时候，程序员在私下评价一起工作的产品经理时，总是会补加一句「我感觉我也能做产品经理」。这句话的背后，是产品经理没有让程序员们感受到产品工作的价值。在这种背景下，产品经理是很难获取程序员们的注重，也会为很多争论埋下诱因。那如何感受到我们工作的价值那？其实很简单，就是保持工作信息的透明。将我们针对需求和产品做的相关工作，体现在我们的沟通或者文档中。
导致程序员想「砍」产品经理，本质是产品经理工作方式的问题，也有情商的问题。在我的产品经理工作经验中，我总结下了以下四点，我们需要注意和避免的。这四点，都可以和上文的场景相对应，是最容易慢慢改变程序员的心态的。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）