前言 如果遇到问题，无法解决，应该怎么处理？其实，这个问题要从两个不同的视角来探讨：一个是项目成员的角度，另一个是项目负责人的角度。假设项目成员是李四、王五，项目负责人是张三。 及时反馈 比如项目成员李四，有一条功能开发的任务，工期为5天。在开发过程中，他遇到一个无法解决的问题，一个人琢磨了一两天，但始终无法突破，就这样卡在了这个点上。他的心路历程可能是这样的：一方面，他担心自己的技术能力不足，觉得这个问题在别人看来可能很简单，自己居然解决不了；另一方面，他想死磕到底，觉得遇到这样的技术难题，如果不解决就太不甘心了。这些想法本身没有问题，毕竟谁都不想被别人说技术菜，而死磕难题正是极客精神的体现，值得鼓励。 但问题在于，这种心态放在项目团队中可能会带来隐患。项目最终看的是产出和结果，而不是个人的技术表现。只要项目能够完成，其他因素都是次要的。从这个角度看，担心被人说技术菜、死磕技术难点，都变得毫无意义。因为解决问题的方式并不唯一，不一定非要从技术入手。比如，李四可以把问题及时反馈给项目负责人张三，由张三组织项目团队讨论，甚至与客户沟通，看看是否可以通过微调需求来解决问题。也许客户的需求，用另一种呈现方式同样可以满足，而无需纠结于技术实现本身。 有人可能会问，如果讨论后发现确实只能通过技术手段解决呢？如果项目负责人张三已经召集项目团队进行讨论，仍然没有解决方案，那又有什么可害怕的？大家绞尽脑汁都没能解决，怎么能说明李四技术很菜呢？如果有人质疑，他完全可以回怼：“你那么厉害，那你来试试看。” 所以，项目成员遇到问题，如果已经使出浑身解数，还是没能解决，要及时反馈给项目负责人，要从项目全局角度考虑问题，而不只是个人的维度。你及时反馈，虽然是别人给你的解决思路，但最终执行的是你，这条任务还是你来完成的，而你如期完成了这条任务。 小心“猴子” 上面是项目成员李四的角度，那么从项目负责人张三的角度来看呢？ 如果项目成员不是像李四那样闷头死磕问题，而是遇到问题就立即反馈，比如王五，张三应该如何应对？ 有些项目负责人可能会及时介入，觉得自己项目同事遇到了问题，自己当仁不让，当然要身先士卒，冲到最前面了。这个本来是很好的行为，出发点也是好的，但这样做的结果是，原本属于王五的开发任务可能完全变成了张三的工作。这就是我们常说的**“小心下属的猴子跳到上级身上”**的问题。王五可能因此变得依赖，而张三则疲于奔命，吃力不讨好。这种情况本质上取决于项目成员的性格和工作态度。如果是这种倾向明显的同事，张三首先要做的不是直接介入，而是反问王五“有好好研究过了吗？”，如果王五支支吾吾，那就先让他自己研究一下，不要遇到点小问题就退缩，如果王五说已经研究过了，那张三就需要及时调整王五任务的优先级，让王五先做其他事情，避免他无所事事，自己再介入。 意思就是说，对于项目成员反馈的问题，张三可以介入协助，但最好只提供解决问题的思路和建议，比如分享自己调研到的可行方案，然后交给王五去验证。张三的角色主要是引导作用，而不是直接接手去解决问题。他需要激发项目成员的主动性，让他们在遇到问题时真正动脑思考，而不是轻易放弃。如果最终仍然没有解决方案，张三可以召集相关同事讨论，甚至向上级反馈，让更高层来做决策。 所以，项目负责人在处理项目成员反馈的问题时，应避免替团队成员承担过多责任，而是通过引导和协调，激发他们的主观能动性。一来项目成员可以得到锻炼，二来项目负责人可以投入精力在更重要的事情上，这对于项目团队而言，是大有裨益的。

读后感 《流星之绊》是东野圭吾在2008年发表的长篇小说，主要讲述兄妹三人夜出观看流星，回家发现父母双亡，此后在孤儿院长大。接着因为矢崎静奈被骗，他们兄妹三人气不过，开始了合伙设计诈骗他人。在这之后，因为一个偶然的事情，在父母被杀案件追诉期将近的日子，有明泰辅发现了曾在凶案现场碰到的那个男人，于是通过连环设计嫁祸凶手，企图用伪证迫使对方自行认罪。 这本书在看的过程中，看到矢崎静奈的所作所为，就不得不感叹，东野圭吾的书里好像就没有过好女人。《白夜行》的唐泽雪穗、《幻夜》里的新海美冬，都让人觉得后背发凉、毛骨悚然，像是无情的“杀人机器”，而这次静奈也通过伪装和演技，把很多男人玩得晕头转向。我本来以为又是熟悉的套路，但在最后一次行骗面对户神行成时，她却因为情愫萌生，变得犹犹豫豫，导致计划最终落败，但恰好是这一点，反而让人物变得更为立体了。 在阅读过程中，早就知道户神行成不会是凶手——因为推理小说的情节设计来说，明面上的答案都不会是真正的答案（除了《恶意》）。实不相瞒，看《恶意》这本书的时候我还想着，有没有可能以后写个小说让凶手就是主角“我”，没想到《恶意》直接实现了我的这个想法，真的太巧了。当然，后来知道阿加莎的《罗杰疑案》用过类似手法，不过那是后话了。 说回《流星之绊》，快结尾时还没有任何凶手的提示。因为凶手必须是早就出现的人，不可能凭空冒出来，这样才能情节反转。但我把出场人物想了一圈，好像没谁有强烈的动机，完全猜不出来。索性抱着看热闹的心态继续读下去，想看看东野圭吾怎么编下去。当有明功一回忆起似曾相识的画面时，我脑袋里突然冒出一个念头：难道凶手是有明泰辅？自己都不知道这想法怎么来的，接着又想会不会是矢崎静奈？毕竟没有血缘关系，谁知道是真的没血缘关系，还是假的，如果有其他隐情呢？再来次《白夜行》？不过他们当时都是小孩，还一起去看流星雨了，显然不太可能。 真正看到最后知道凶手是谁时，有点意外。倒不是说动机不行，就是感觉有点俗套，可能因为之前看过《新参者》，觉得类似的动机不够新颖，说服力也不够强。不过总体还行，至少比《梦幻花》好太多了。 摘抄 这个世界只有骗人和被骗。你们看看政治家、官僚，不都是在欺骗国民，中饱私囊？可明知是这样，国民就起来暴动了？没有吧，都死心了不是？所以，只要干得巧妙就是赢家。被骗了就去骗回来，同样，被我们骗了的人，如果不甘心吃亏，也可以再去骗别人。 钱财乃天下流转之物，那就让它流到我们这儿来吧。 我们要骗人，再也不受窝囊气了。 根据泰辅的经验，和女人比较疏远的男人有两种：一种是不讨女人喜欢，很卖力但对方不予理睬，还有一种是并非不受欢迎，但心思全被别的事情占了去，与女人无缘。 你善于合乎理性地做好工作，但却不知道，要打动人心光靠理性并不够。 花力气得到的答案比轻易就弄明白的更显珍贵。 人类的行为并非都能用理性来解释。或者应该说，不合情理的地方居多。盗窃杀人犯将罪证藏到天花板上，搬家时竟然忘了，这确实不太自然，有些鲁莽。但人就是这样，会犯这样那样的错误。还有，对于警察来说，那种事无关紧要。 外表越出众的人，越有可能深藏着一张人们无法想象的面孔。 为了生存。我们无依无靠，没有任何资本，要想活在这个世上，根本就没有选择手段的余地。如果允许我找一条理由，那就是我想履行责任，作为兄长的责任。当然，现在我已经知道这是个天大的错误。不管出于什么理由，也不该让他们成为罪犯。作为兄长，我应该阻止他们，我犯了严重的错误。

最近一直在思考阅读的意义。每次看完一本书，总觉得应该留下点什么，因为如果不及时记录，时间一久，连当时对这本书的感受都会变得模糊。更糟糕的是，有些书的内容甚至完全记不清了。比如东野圭吾的《盛夏的方程式》和《祈祷落幕时》，明明是读过的，现在却连故事主线都讲不出来，甚至可能记岔了细节。 所以，打算新开一个读后感系列，把看完一本书后的感受都写一写，不需要强求自己提炼出什么深刻见解。感受毕竟是主观之物，只要是真实的，那就可以，比如随手写下对某个情节的吐槽，或者对某句话的感触，甚至只是简单复述一下故事内容。关键是，把这些零散的想法及时记下来，哪怕只是片段式的笔记，也能在未来某个时刻重新唤起当时的自己。 阅读本身是私人的体验，思考的深浅因人而异。与其纠结于有没有价值，不如专注于有没有动过脑。只要读了、想了，哪怕只是片刻的触动，也是一种收获。而记录的意义，不是为了证明自己读了多少本书，而是为了对抗遗忘，让那些稍纵即逝的感受有机会被保留下来。

我们部门在开发一些项目时，确实需要借用设备，但每次开发新需求时都要从硬件部门借设备，开发完成后又要归还。这种频繁的借还流程不仅增加了沟通成本，还导致项目负责人和开发人员对设备的功能和应用场景缺乏直观的了解。有时甚至连设备长什么样都不知道，这显然不利于我们真正理解业务需求，甚至可能导致开发方向与实际业务脱节。 有人提议是否可以申请一些设备常驻我们部门，让项目相关人员在开发过程中能够随时试用设备，真实感受应用场景，同时遇到问题时可以立即用设备重现和排查。这个想法确实有一定道理，但仔细想想，设备本身也在不断迭代，如果设备长期放在我们部门，可能只能停留在某个版本，后续更新无法跟上，反而会限制我们的开发思路。此外，设备的使用频率主要集中在开发阶段，项目上线后很少再被关注，长期占用硬件资源可能造成浪费。 其实，我们的核心问题并不是设备是否常驻，而是如何让开发人员在开发阶段有机会试用设备，从而增强对业务的理解和对设备功能的熟悉。与其申请设备常驻，不如在开发阶段短期借用设备，确保开发人员在关键阶段能够充分接触和使用设备，同时避免资源的长期占用。这样既能满足开发需求，又能兼顾资源的合理利用。

虽然在项目开发前期，我们已经做好准备工作，一个环节到一个环节有条不紊地执行，但不可否认，在这个过程中，难免会出现需求变更的情况。作为项目负责人，应该怎么去处理这件事呢？ 项目遇到需求变更，通常都是新增需求，很少是减少需求的变更。简而言之，就是增加了工作量。而项目负责人面临的难题在于：如何在不影响整体计划的前提下，高效应对这种变化。需求变更的规模有大有小，不可一概而论。如果是小的变更，那无伤大雅，适当微调即可。但倘若是很大的变更，比如新增的功能开发需要一两周甚至更长时间，那么整个项目计划可能就需要推倒重做，这无可厚非。 我们要探讨的是介于这大小之间的需求变更——那些有机会在当前计划里解决掉的需求，比如增加了一周的工作量。你有信心能按当前制定的计划如期交付吗？现在的情况是，我们可能只是将需求变更分为大小两个情况：小的微调，大的立刻调整项目计划，然后项目上线时间就会变更。久而久之，这种处理方式可能会让人觉得理所当然。 事实上，大部分项目开发工作是有协商空间的，并未被完全限定死。遇到突发情况，比如客户需求变更，但交付时间没有任何商量余地时，项目负责人该怎么办？有人可能会说加班，但有时加班未必能解决问题。 也许现在我们可以慢慢培养这方面的意识和能力，在平时多积累这方面的经验，避免真正遇到事情时手忙脚乱、无从下手。也就是说，我们可以将需求变更分为三种情况：小的变更，微调即可；大的变更，比如需要增加两周工作量，那就变更项目计划；中等变更，比如需要增加一周工作量，我们先不急于调整计划 ，而是先想一想：有没有什么办法可以在不变更计划的情况下解决这个问题？然后将各种可能的解决方案列出来（1、2、3……），召集项目其他成员一起讨论。也许经过多轮讨论，我们就能找到解决方案。如果讨论后仍无法解决，再根据实际情况变更项目计划。