职场思考二三事

职场思考二三事（持续更新中）

背景

软件工程师的工作不仅仅只有写代码，还有很多事情在工作同样很重要，甚至在某些程度上比代码写的好还重要。本文来自我的一些自我总结，和从一些前辈那边学到的经验。整理如下

核心观点

• 确定价值
• 不要沦为他人的工具
• 重视过程，更重视结果
• 协作能力大于个人能力
• 不拘泥于眼前
• 没有对错只有成本选择

确定价值

商业公司的本质是为了获取收益，创造价值。而软件从业人员的工作便是开发能为公司创造价值的软件产品。但是并不是所有的软件都能如愿创造价值，所以在开始软件开发之前，要先思考它的价值，是否真的值得去做。

成本选择

在了解软件价值的时候，不要因为价值大就立即去做，也不要因为价值低就选择不做。我们做出决定的标准不仅有他的价值，还要考虑进去他的成本。而这些成本包括

• 时间成本
• 人力成本，
• 环境成本

时间成本

这个比较好理解，包括前期会议讨论的成本，涉及新技术的学习时间成本，开发人员开发成本，中间加入的开发人员的培训成本。后期测试的成本。

人力成本

这个很简单，不赘述

环境成本

当前所处的环境，是否合适你做这样的事情。举个比较极端的例子。

比如我们现在在做一款直播软件（或者其它什么软件），这个领域目前处于野蛮生长的状态，大家都投入进去做开发，每次发版都要做大量的功能，竞争激烈。这个时候你们发现竞争对手做出了一个新的功能A，获得了极大的领先优势，但这个时候由于软件快速地追求功能，你们项目有些地方已经开始出现各种性能问题，这个时候你们是应该停下来重构代码，还是应该继续跟进呢！很多程序员站在技术的角度，觉得项目已经充满坏味道了，所以要立马去重构，去做优化。

而这个时候我倾向于。站在用户和产品的角度思考.

    假设性能问题带来的损为a，新功能带来的益为b
    a > b ? do a : do b

当我们置于商业公司的时候，我们写的代码，就不能完全只考虑技术层面的东西，老板找我们来干活，是来做产品的，有时候我们需要为了实现产品的目标来妥协技术。更何况，如果我们的产品因为没有新功能a，而导致从此被竞争对手一骑绝尘，可能产品立马就死掉了，那这个时候再来谈论技术，其实也就显得没有价值了。

拿到结果

没有过程的结果，一般不是什么好结果，而没有结果的过程，什么也不是。写java的人，大部分都应该知道一个东西叫tdd（测试驱动开发）。抛开技术层面的具体实现细节，tdd的本质思想是 - 聚焦结果。在工作规划的时候，我们一定要事先思考，当前的工作，对于我来说，是要拿到什么结果的。并且把它置于醒目的地方，这样当我们在做事情的时候，可以思考，当前做的事情，是否有所偏离，如果有偏离，那么就要及时修正。

结果设计要可量化

虽然做事前要做规划这个事情人人都知道，但是做的人却很少，根据我的个人经验，很多时候是因为规划的事情不可量化。举个例子，很多人在假期的时候时候给自己列这样的学习计划。

1. 阅读《代码大全》
2. 学习groovy语言
3. 复习java的gc原理

这样的计划其实效果很差。因为你的结果没有量化，当你看代码大全的时候，你仅仅是看一个个片段，很容易看完就忘了。你学习groovy，可是你学习groovy的目的是什么，学到什么程度算符合预期了，如果没有实现设计，很容易发现看了好几天的groovy，看起来好像学了不少东西，可是也不知道到底学了什么，这样做事情成就感很低，会大大降低学习积极性。所以这个计划可以改为如下。

1. 阅读《代码大全》前二章，产出一篇关于「创造高质量代码」的摘记或者分享。
2. 学习groovy语言，学习groovy的基本用法，学习在maven如何配合groovy工作。
3. 复习java的gc原理，主要的目的是找出之前理解有误的点，记录理解更为深入的点。

每个计划点，都有明确要产出的东西，这样的计划才更为可执行性，一般来说计划越详细，可操作性越强。

里程碑

我们的项目，往往需要持续很长的时间，在中途出现意外情况，几乎是一定的，一般来说最大的意外是没有意外。为了让我们的项目最终能尽可能达成目标，我们不仅需要确立好目标，还需要确立项目过程中的里程碑 - 过程中的结果。举个例子我们要在月底上线一个功能。这个涉及到服务端提供接口，客户端开发相关功能。为了项目可以持续性的交付，我们将任务分解为不同的模块，划在不同的时间段，每一个时间聚焦完成一个功能点，并且每个时间节点对工作内容做review，确定没有跑偏。在我目前所处的公司，我们习惯称在各个时间节点要产出的目标为一个个 『里程碑』。

协作能力

当今这个时代，个人英雄主义已经在项目中无数次被证明是不可行的，但是还是有很多程序员憧憬自己可以像软件「原始社会」时代那样，成为可以力挽狂澜的英雄，但是现实是，以当前软件开发的复杂程度来说，一个人的战斗力往往是不够的。一个人开发比起多人开发最重要的优势在于：不需要沟通成本，因为项目只有一个人，省去了项目成员之间互相交流的时间成本。但是一个人的缺点很明显，人的脑容量是有限的，当事情复杂到一定程度之后，是无法和一个可以顺畅交流的团队比肩。

学会妥协

在项目进行中，肯定会涉及大量的讨论，或者说争论。但是一定要记住，我们讨论的目的是为了产出结果，而不是为了证明谁对谁错。

    不要企图证明自己是对的。开会是来产出结果的。对于技术细节要立即验证，而不是继续讨论。

建议而不是指责

当我们与人合作的时候，很多时候会发现项目合作者做的不好的地方。这个时候如果我们立马说：”你这里做错了”,或者”你这里做的不够好”之类的，很容易触发对方的抵触的条件反射，而这样的感情不利于讨论的顺畅性。我倾向于说。

    "xxx(人名），你这里写了写了一段代码，我有点不是很理解，
    你看看",然后指出错误的地方，引导对方发现错误。

或者说

    "xxx,我看你在这里用了一个这样的方法，我知道一个方法，
    这个方法是zzz，你看我们把这里改为zzz，是不是更好一些。"

以这样的方式，一般来说可以消除对面自然产出的抵触感情，使得交流趋于正常的讨论。

跨专业的意见

在我刚刚提到的建议而不是指责，是针对大家都是程序员的情况。但是如果你要给一个运营或者交互设计师提这样的意见的时候，就不能这样了。有一句很容易激恼程序员的话叫做：

    不就是加个这样的功能，有这么难吗。

相信大家都讨厌这样的话，这话的讨厌之处在于，说这样话的人不是程序员，不了解写代码的难度，只是单纯的提出不满，这样的话除了把事情搞得更糟之外，毫无好处。同样当我们对我们的设计师的设计稿，或者运营提出的需求有意见的时候，我们第一要想到的是：相信你同事的专业性。如果实在想反驳，一定要提前做好功课。比如说设计师要做一个A的设计，你觉得应该应该是B的设计，你要说出你的观点，但请记得一定要说出你的理由，理由最好是有数据的量化，比如说『根据我们用户研究员同事tom的报告指出，喜欢B设计的用户是40%，高于A设计的30%和其它的30%，所以我认为应该用B。』如果你是这样说出来的，这样才是有建设性的。

努力去理解你的设计师同事

我在上文提到，当需要跨工种提出意见的时候，最好的方式是给出可以量化的数据证明，但是这样有两个缺点。
* 搜集证据的成本很高，况且很多东西你是在会议中才知道的，你很难在会议中途搜索到证据，证明你的说法。
* 你直接拿出证据指出设计师的不对，其实隐含着对设计师的否定，没人喜欢被否定。这不利于你们的长期合作，当然如果你的设计师同事是个有野心有追求的人，他是不会介意这种事情的。

所以一个更好的方式是努力去理解你的合作伙伴。你直接问询设计师同事，问询他为什么要这么设计，设计的理由是什么。很多时候我们意见不一致，来自于我们收集到的信息不一致，如果我们主动问询，了解设计师了解的信息，这才有利于我们求同。