作为工程师或者开发人员，你可能会认为除了写代码以外的一切都是没有生产力的。但是往往却会遇到各种影响生产力的事情。Alejandro Wainzinger就是这样，他以为自己遇到的这些问题也许是进的公司不对，结果大中小型公司都换了一遍之后，发现到头来工作总是会变糟。为此,下文在计划、所有权、技术债务、设计、编码、会议、流程、沟通、评估、宣传、面试等方面的常见问题，并给出了自己的解决方案，供各位参考。

无论我去过多少家公司，工作到最后都会变糟。在我工作过的技术公司里面，早晚都会出现一些问题，这些问题要么需要做出管理方面的改变，要么需要对现有的管理风格迅速做出极端改变。但通常这些需要的改变都不会发生，然后我开始换地方，希望能遇到更好的管理。

   作为独立贡献者，我已经在大中小规模都有的好几家技术公司当过web后端软件工程师。我想通过本文卑微的努力把我所见到的事情、问题出在哪里、以及可能的解决方案是什么说清楚。我写这个是为了梳理自己的思路，同时也希望有人能从这些故事当中找到熟悉的东西，并且了解到并不是只有他自己才体会到这些。在某些情况下，这些看起来似乎是开发者的问题，但是开发者是在管理层创造的环境下工作的，所以我也把它们列进来了。

   如果你很忙的话，我已经把要点标出来了。不过，知道这些要点是什么意思会更好一些。

1、计划

　没有路线图，或者路线图很虚

  对成功应该是什么样没有想法或者想法很少的话，你是永远也无法实现的。项目的想法模糊会导致写出来的代码也含糊，运行“晚”（没有路线图的话你怎么知道呢？），以及各种沮丧。

  解决方案：制订路线图。

   路线图不以现实为基础（没有找工程师/利益攸关者进行估计，过程中没有检查点）

  管理层决定了一系列他们想要的事情，并且决定这个季度就要完成。但如果没有来自执行那些工作的人提供输入的话，那些设想可能就是空中楼阁。没有检查点去了解事情的进展情况的话，项目就会完成得很迟，往往太迟了以至于要重新确定范围，希望能完成点有意义的事情。

  解决方案：强迫那些负责做事的分解时间表，并且要合理化。让他们暂停写代码（很多开发者认为只有写代码才算生产力），先做完这个。对于好的、周密的估计要激励。

  路线图制订得太迟（在开发期间）

  先做项目，上路后才制订路线图。突然才意识到正在做的项目毫无意义。时间和精力还有士气都没了。

  解决方案：在开始工作前花时间制订路线图。你不需要预测每一种可能的未来，但是当你了解形势时就更容易把握好方向不至于撞车。

  路线图的极端改变不是因为环境变化，而是因为短视或者原先的计划缺乏周密性。

  某一天商业团队一觉醒来决定另一个项目的优先级应该更高，因为这样才可能有高速发展的走势，只是他们一开始没有事先花时间确定好事情的优先级。几个月的努力变成白费功夫，而这其实是完全可以避免的。

解决方案：认真对待路线图。好好确定优先级。除非商业方面发生了极端的变化，路线制订好就要坚定走下去。犹豫不决造成的损失比坏决定还要糟糕。致力于你说自己要做的项目。那是可以衡量的生产力。如果你对上一个优先级感到后悔的话，下个季度别再犯同样的错误了。

2、所有权

项目缺乏直接负责人

  项目是建立了，也分配给团队了。也许某人下达跟踪要完成工作的工单。一些人想起来的时候就去处理这些工单。经理偶尔会在邮件里面问问进展情况。开发者都是各自回答问题。结果表明该项目严重滞后，而且很多工作都没做好。

  解决方案：选定1个人，其工作是确保项目取得进展。这个人有权力跟经理去谈，如果必要的话可以申请更多的资源，但到头来回答关于进展情况并且推动事情发展的都是这个人。

  某个大项目只有一位工程师孤军作战

  每个人都忙着做项目。一个人有点空闲，然后被分配去做一个重要的项目。并行主义万岁对吧？错。这位工程师试图知道事情是怎么做的，但是得到的帮助寥寥，因为别人都很忙。没人审核她的工作。他们问什么地方耽误了她也回答了，但是没人对答案感到满意。她请求帮助但是被告知没有人有空。

  解决方案：除非你是在初创企业，已经快没钱，再过几周就要死掉，否则的话一个项目至少要分配2个人，理想的话3个最好。他们会提出问题的可能性要高得多，因为相互之间可以讨论工作，一起推进事情前进。而引入第三个人可以在设计决策和代码审核方面打破僵局。

  代码评审缺乏责任担当，不够彻底，指责代码作者

  来了一个pull请求。你很忙，这个人可能知道他们在做什么，只需要同意就可以继续你的事情了。轻而易举的同意谁不喜欢呢，对吧？再想想。看都没看只能说明你是个懒人。而且你还给别人开了先例，行啊，我以后也可以不审核代码了。当别人写的代码出问题时人家会说你不是看过了吗？代码是你批准的，负责也有你一份。

  解决方案：认真对待代码评审。如果你没有时间，把它分配给别人，或者问问pull的请求者是不是能够等久一点因为自己还没时间。我向你保证，你会对自己的所谓感到高兴的。

技术债务

  没有采取合适行动让旧系统退役，重写及/或撤除现有遗留系统

  到了一定时候，某个遗留的单一程序规模达到了像利维坦巨兽那样的地步，而且给web带来的灾难之严重已经到了妨碍开发的地步。现有的资深开发者处理相关事情的时候都有困难，新的开发者更是骂骂咧咧了好几个月才稍微提高了一点效率，奇怪的崩溃潜伏着，导致你的客户时不时会出现莫名的问题。但管理层总是优先考虑产品，并没有意识到技术债务拖累了他们非常渴望的产品功能研发。

  解决方案：企业必须赋予技术债务足够的优先级。遗留系统中最臭名远扬的问题必须优先处理。重写的工作必须按照规模大小依次处理。这会给将后的功能开发带来时间红利，连开发者的幸福感和寿命都会增加。大家常说开发者离开的不是自己的工作，而是他们的老板，但我认为很多时候，开发者离开的也是他们的代码库。

　开发没有必要写的系统

  “你有没有听说过那门很酷的新语言？我用周末的时间学了，现在想看看用到生产过程里面会怎么样。我听说挺棒的。”然后，一个用新语言开发的新系统做出来了，结果发现它做的东西跟某个现成的开源库非常类似，只是针对了比较特殊的用例，而且支持的开发者比较少。这个项目迟早都会延误，开发者离开了那家公司，可是在这个系统上已经浪费了很多大可不必的时间，但其实这些本来可以用在对业务很关键的工作上的。

  解决方案：这个问题比较棘手。需要有一位老练的经理知道什么对这种项目亮红灯，转而采用现成的解决方案，以及什么时候开绿灯。你当然不希望打压好的开发者，但是你也不想浪费时间精力。最好是让那位开发者写一份详细的建议书说清楚实现细节，然后进行详细的审查。也就是说，这是招到经验欠缺的经理可能会遇到的陷阱之一。

  把错全都归咎到遗留系统上面

  差点忘记，遗留系统。人人都喜欢喷原有代码，指责往往已经不在那里的开发者，因为对方无法还击。情况变得这么糟糕一定是因为那帮人太烂了，但我们比他们好。当然我们不会去修改原来的东西，我们的额外修改是必要，但我们比他们好，真的，我们保证。在别人的东西基础上增加修改要容易多了，它会让你琢磨为什么要有原来的东西。这会创造出一种抱怨没完没了的有毒环境，最终受害的将是代码质量和团队和谐。

  解决方案：尽管对原有的确质量不高的系统没完没了的抱怨可能会很有吸引力，但是请记住，正是因为原先的代码才让公司走到了现在，而那些有疑问的涉及决定也许是几次变更、商业决策以及紧急灾难共同造成的结果，这在任何快速成长的企业里面都是很常见的事情。某个东西很糟糕？做出具体计划改进它。要行动而不是抱怨，哪怕你的举措是慢慢削弱旧系统。你后面的人（可能也是你自己）会对此感激不尽的。

3、设计

  如果你在绕开系统弱点上面用的代码量多过利用其优点的代码量的话，就是坏设计

  有人有一个很棒的新设计，他们想实现这个设计，因为它比原来的那个好多了，原来的设计太糟糕。只是这么做会需要到处修补一下，但这完全是可以接受的，因为整体上新设计更好。直到后来才发现需要的修补的地方太多了，但是你已经全力以赴，没法走回头路了。

  解决方案：重新开始。沉没成本谬论是真的。你已经犯了一个错误，没关系，你可以吸取教训然后做出更好的。不要无奈地接受混乱。

  如果致力于这一代码库的大多数人都遇到了同样的问题，并且这些问题采用不同的架构时可以避免的话，就属于糟糕设计

  你会注意到同一段代码被拷贝粘贴到系统的每一个被牵涉到的地方。你问某人为什么，他们解释说“哦，那是因为这个系统因为某个原因预计要做这个，其实这不是真的，但听起来不错，所以大家只好跟着做。”你不知道为什么他们要这么做，但你很忙，所以就把这段代码粘贴进去然后继续自己的事情了。

  解决方案：我说的话听起来会很痛苦，但是，还是重构吧。重构整个东西，把那些拷贝粘贴都去掉。付出会有回报的。

4、编码

  随意编码。没有测试，或者测试糟糕。没有处理极端情况，而主要是编写基本逻辑（happy-path）代码

  “这里是初创企业，我们没有时间做这个，晚点再处理。这是可以接受的，”这些年来很多开发者都这么说，每个人都为最后的混乱局面贡献了自己的力量。未经测试就上线代码，产品出问题晚点再修复，哪怕写测试也只是测基本逻辑，或者甚至连这个都不做。

  解决方案：管理层可以强制要求测试的覆盖面，不过其实这并不是代码库测试是否到位的好的衡量手段。有效的办法是让周密的人对这些代码进行评审，让那些代码评审只是做表面文章的走人。不幸的是，不幸的是，当你招进来的工程师缺乏经验或者不够尽责的时候就会出现这种情况，所以招人的时候要擦亮眼睛。

　5、会议

  没有日程，或者日程不明确，没有可衡量的输出

  你查看日程发现自己有个叫做“系统讨论会”要参加，但是要干什么并没有描述，只知道邀请了10个人，要进行1个小时。身为好员工的你出席了，但是绝大部分时间内都是默不作声，只有其中的2个人在那里漫谈，到会议最后的时候，组织者拍拍那两个人的后背中断了同名的谈话，并且威胁着要再举行一次会议。大家的时间被白白浪费掉了，一点收获都没有。

  解决方案：在全公司范围强制执行一项政策，要求所有会议都要有日程，有可衡量的输出，只让必须参加的人出席，而且要有备忘录，看看会议的结果是否达到预期。一旦目标达成或者时间到马上结束会议。任何违背这些原则的会议，要么允许大家走人，要么允许将来不再出席。这样就会迫使大家做出改变。

  可以邮件或者私聊解决的会议

  你参加了一个会议，会议有可衡量的输出（耶！），但这只是一个只需简单回答是与否的问题，通过邮件或者私聊完全就可以解决。

  解决方案：是的，就用邮件或者私聊。用好你的常识，以及合适的媒介。

  该参加的人不参加不该参加的人却参加的会议

  你参加了一个有10个人出席但是主要设计师缺席的会议。大家都举手说了点东西，但到最后，所有的东西都被负责的人拒绝了。那天晚些时候，因为某些原因你出息了一个有工程负责人参加的会议，为的是审查了一下底层代码决策的事情，可是他在不了解背景的情况下对东西吹毛求疵，浪费了大家的时间（也包括他自己的）。

  解决方案：邀请每一个人参加会议都要有个好的理由。如果你想不出好理由，那就别邀请那个人。如果某件事情的主要决策者应该参与，那就邀请他。最重要的是，不要把可来可不来的人加进来。如果某个人是可选的话，那就不要邀请。就这么简单。这是一场公司会议，不是技术研讨会。

  为了开会而开会（站立会议，你究竟想从中得到什么？）

  你在参加每天的站立会议？大家讨论的都是你没有想法或者不在意的事情。你分享的东西可能跟他们也毫无关系。跟你有关系少数人你早就在会下交流过了，然后你报告说你们已经在私下交流过了，而且还会继续在会下跟他们讲。等一下，为什么我们还要站在这里呢？

  解决方案：如果你绝对必须知道其他人在做什么，把它写成文字以聊天或者邮件形式进行。但你会说：“哦，但是没人会看。”对。那是因为没人在意。可是你以为大声说出来他们就会在意了吗？作为这种日常仪式的结果你现在就会做得更好了吗？未必。不要再浪费别人的时间了，把焦点放在结果上面。要消灭一切无用的会议，尤其是那些重复性的、主要是出于惯例进行的会议。

  开会太早或者太晚。注意力广度很低，愤怒情绪高涨。你不会从这些会议中收获好结果的。

  现在是下午6点，有人还在开会。你的手紧紧握住了当天的第三杯咖啡并且祈祷这次会议要么有个好结果要么很快就会结束。很可惜，一件事情都没有通过。第二天早上你意识到有人已经安排了早上8:30的会议。你握住手里当天的第一杯还没喝完一半的咖啡希望有个好结果。有人问了你一个yes/no的问题，然后会议结束了。没开玩笑吧？

  解决方案：认真点。很多时候我们考虑事情都忽略了人的因素了。不要把会议安排得太早或者太晚，要安排在核心时间段。如果会议很重要，就需要马上进行。否则的话，没有什么事情是不可以等1天或者几个钟头的。那样的话，大家会更愿意出席，更愿意参与，你也更有可能得到想要的结果。

　6、流程

不评估当前情况就盲目遵守流程

  冲刺！谁不喜欢冲刺呢？我们行动敏捷。你什么意思敏捷可不是名词。我给它大写，必须这样。不管怎样，让我们大概一周左右都要冲刺一下，让大家弄清楚自己都在做什么。我怎么知道这么做有效？因为我们每周都要开始新的冲刺啊。什么？结果怎么衡量？我们创建并完成了很多工单。你还想要什么？

  解决方案：流程是个好东西。流程指导工作，引导得到路线图（你当然要有！）上想要的结果。然而，无法衡量你是否离目标更近或者是否实现了目标的流程要么是不必要的、要么是错误的、浪费时间的，或者以上都是。永远都要评估你的流程，看看它能给你带来什么，又会让你失去什么，并且确保前者永远比后者更多。

  民主过度导致优柔寡断

  每个人的意见都很重要。因为我们不是专制的，对吧？我们听听工程部门所有人的意见。等一下，有两个人不同意，这可不好。其中一位工程师虽然跟项目没有关系，但是他很有经验啊！我们还是搞定他再继续吧。别管期限了，我们需要把事情做对！正确才是最重要的。

  解决方案：企业不是政府，这里不应该民主。又快又好的决定可以拯救公司，决策慢的话无论好坏都会毁掉一家公司。如果你让某人负责这个项目，他们就有最后的话语权，他们会迅速做出决定。争端可以在更加私下的场合解决，不用把整个工程部门都牵扯进来。关注你的人，这样可以让结果最大化。让他们每个人都有话语权的话，你就会毫无理由地陷入僵局。

  过分微观管理，经理不去关心更大的局面，IC沮丧，糟糕的工作出现

经理是管人的人，他跟你在一个战壕上。在不知道是什么原因导致你做出这个决定的情况下，他问你这行代码为什么不换种写法。你用了一个小时的时间才跟他解释清楚，最后他就说了一句“哦”然后同意你了。与此同时，路线图已经延误而且跑偏了，工程师愤怒了，但是该解决这些真正的问题的时候经理却不见了。

  解决方案：要相信人。如果你无法信任他们，那就开除对方。微观管理是任何组织的丧钟，会阻止任何团队扩大。如果经理不去处理真正高层的决策，一行代码是起不到作用的，因为当房子都已经着火的时候你却在跟木匠争吵新椅子的问题。要站得高一点，用鸟瞰的视角来做出好的决策，即便底层会出现一些低效的事情，但大船仍然朝着正确的方向航行。

越级管理

   你在做某件事情，你的老板问你情况怎样，于是你提供了一个更新。然后你的老板的老板又问，你给出同样的回答只是没说那么详细。然后他的老板问，你就说“不错。”然后一位跟你的团队毫无关系的经历又来问，你开始猜测发生了什么事。你决定写一封全公司范围的报告，说清楚进展情况，这浪费了你的时间，因为你要向那些不应该有其他考虑的经理解释清楚事情。

  解决方案：就像过去说的那样，企业不是一般社会。层级的存在不是为了压制下级，而是为了保持秩序和效率。如果3级经理定期询问非直接下属项目的进展情况，这就是微观管理或者管理层级太多的迹象。这些问题的解决方案也很明显。

缺乏有用的检查点

  项目结束时我们会知道。我们以工单完结数来汇报项目状态。当然，尚未完结的工单数是会随时间转移而变化，但那只是粗略的估计，对吧？直到根据安排需要2周的事情最后拖到了6个月完成。

  解决方案：增加检查点。“这些那些应该要在第二周结束时完成。”如果检查点任务未达标，必须进行重新评估， 可能还要给项目多分配资源如果其优先级比较高的话。否则的话，你的项目范围和时间就会不断膨胀，超出你的控制。

  工程师陷入困境的时候不去拉他们一把

  每个人都知道Jacike在做住这个长期项目，而且已经做了一段时间了。你经常会想了解他的进展情况。管理层似乎并不关心他是否延误，因为嘿，你知道的，这个项目很困难。时间过去了，没人介入进去。他时不时会请求帮忙，但被告知大家都很忙。项目就这么一直搁置下去了。

  解决方案：管理层应该对项目状态有一定的了解。如果某件事情明显拖得太久了的话，那么到了一定时候，管理层介入找出缺失了什么信息，或者是否需要加人等是完全适合的。这不是微观管理，这是管理的核心部分，但害怕微观管理的经理往往赋予的自由度太高了，根本就没有起到管理的责任。是，当然这种权衡是有点像走钢丝线，但这是好的管理的标志。

   注：从下面内容开始我就只列表了，因为实在抽不出时间展开讲了，但希望列出的东西能够不言自明。如果确实很重要并且时间允许的话，我会展开说一下。

　7、沟通

   过度沟通。出于所谓的透明性，事无巨细都邮件给一大群人。收件箱堆满了信，大家就会有意识地过滤掉，导致对此漠不关心。

   沟通不足。你要进行大改很可能会有影响到其他团队，但是却没有通知对方。

　8、评估

  经理没有让直接下属来评估

  对如何改进的描述很含糊，经常说那个人从来都没有超过期待这样的话来打压别人工资，但是又从来没有明确这是什么意思

  奖励所谓的“灭火队员”，也就是那些对糟糕的代码部署做出迅速响应的人，而不是那些设计和编码都很仔细，设法避免问题出现的人

  没有清晰的发展路径

　9、宣传

  “公司是个大家庭。”不，不是，如果是的话，很多公司都像虐待孩子的父母，只有孩子不断付出，而父母却一直都只有期望和惩罚。

  “利用社交媒体来传播公司的文章。”这往好里说顶多算是不够诚实。希望利用大家的个人关系来推销公司就是不拿工作和个人生活当两回事了。这是手伸过头的表现。如果员工喜欢公司所为的话，他们自己会传播的。

　10、面试

  流程与目标不一致：面试的目标是要找到那份工作跟公司和团队都很搭的合适人选。

  工程师负担过重，经常要进行面试，跟工作一样频繁。

  强调雇佣更多的人，而没有把焦点放在留住现有人才上（如果你的工程师感觉没有被公司好好对待的话，他们又会如何介绍你的公司给别人呢？）。

11、酒精

  常规活动也提供酒精饮料。喝酒带来的纯粹是压力，不好的健康习惯，不良的工作环境。

  宣扬喝酒文化，把它正常化

　12、歧视

  种族主义、性别歧视、LGBT歧视、年龄歧视。虽然这方面的培训很多，但是出现了一些微妙的歧视形式。

  多元化水平很低

13、员工福祉

  工作过度、紧张过度或者忽视劳累的明显迹象，美其名曰“勤奋的员工”。

  忽略了员工也是人。无视人际关系问题、健康问题等。

转载：http://www.51testing.com/html/62/n-3725162.html