年底了，今天站在一个 leader 的角度去看下面几个问题，和大家交流分享下软技能，如果你只是一线开发人员，千人千面，虽然不一定准确，但希望也可以做个参考：
- 为什么我干的活比别人多？
- 我的付出会获得回报吗？
- 开会真的有意义吗？
- 分组的好处在哪里？有缺点吗？
站会
规则
两个月前，由于某个项目需要快速迭代，成立了两个小组专门处理，先放两张两张站会规则「电子版找不到了我拍了张打印版」：
看起来还是很清晰的，大家凑合看吧，正如我上文所说，我们这套「站会小组」已经试用了两个多月了，优缺点各有下面给大家介绍一下。
小组分配
与以往的开发模式不同，以往只可能是：
- 1、与产品碰需求，预估时间，确认纯开发时间
- 2、N 个前端人员 + N 个后端人员进行协作开发
- 3、待测试 测试 完成
其实上面的 1 没什么问题，关键就是 2、3，比较浪费沟通成本，甚至有的事情花在了「找人」「找问题」上面了，测试、前端、等不知道这个 api 是谁开发的，测试有问题抛给前端，前端不知道具体找哪个后端，抛给后端不知道具体找哪个前端。谁做到什么进度也未可知，那么这个小组的成立就是解决这几个根本问题。
每个组：前端 + 后端 + 测试 + 产品
所以我们为项目X 成立了两个组：A组 + B组
每个组：两名前端 + 两名后端 + 一名测试 + 一名产品
注意：每个组之间没有竞争关系，更多的是互相帮助的合作关系。
每个组各自协商定好各自组内的最合适的时间，比如 A组 每天12点开站会，B 组 每天下午2点休息后开站会，「站会」比一定非要站着，每次最好不要超过15分钟，所有的规则细节你都可以在上图看到。
分组收获了什么？
我们这样分组，项目 X 的快速迭代变得更加高效，我们不需要为共同发愁，每天碰15分钟不管是组员还是「分配者」都轻易掌控项目在组内的进展
对于组员「开发」来说
前后端找接口，对接口，不再是头痛的问题，前端可以更好地规划每天的任务，今天我「画UI」 明天上午 「对接口」，每天预留几个小时时间应突发状况比如：临时需求、临时开会、以及紧急的BUG等
对于组员 「测试」来说
一般我会让测试人员做每天站会最后的总结，开发梳理完昨天的内容，今天要做的内容，测试最后会说昨天测试了哪些功能，有何问题，是否需要开发今天进行调整，是否紧急，根据开发昨天说的内容来通知大家今天测试哪些，出了问题也好直接找直接负责人免得打扰其他人
对于组员「产品」来说
产品每天跟会，组员有问题及时解答，当时的疑问当时就为他们解惑，若有些产品都没考虑到的大问题，也给了他们时间进行调整修改，免得项目接近尾才暴露问题导致项目延期。每周五进行下一个周的任务讲解。
对于 leader 来说
真真正正做到了，项目的进度一览无余，没个人干什么做什么都一清二楚，每个人的工作量、工作能力在此时也完全暴露出来。此小组的任务以 「看板」的形式展示了每个人的任务难度 + 工作量，对于年底结算、kpi 有所帮助。每周三还有每周总结会，可以修改调整每个组的问题。
总结
成立小组让每个人的时间都接近饱和，以往浑水摸鱼的人不在了，不管是有能力不干活的，还是没能力的，都在此时不敢懈怠，我们不加班「泡班」，但是希望大家在上班的8个小时全心投入，赢得属于我们自己的自由时间。
缺点
看到这里其实大家心里都有数，缺点就是：「时间饱和」 大家比以前忙了，有压力了，明天站会说什么需要花点时间准备了，不能再上班摸鱼了。
打分，需要知道每个人心中不管是前端后端测试，对于某个任务的心里分数，期望是好的，但是由于大家举着卡片一起打分这种方式，大家觉得过于：形式主义，效果不太理想：
打分经常打出超出预期太多的分数，大多是开发打的，相比之下测试、产品打得分反倒符合我的预期，设身处地去想想也能理解，所以「打分」不了了之了，有时间的时候我会自己去「看板」上打一打分，不在征求大家的意见。
我认为比较成功，在我看来，没人有丝毫负面情绪，大家每天有说有笑的开完每一天的站会，做好每一天分内的事情。
组内成员的观察
组内合作，工作量全靠自觉自己领取，可能都是老员工大家也算给力，也都比较给我「面子」，每个人领取的任务上量 * 工作难度 全都符合我对每个人的预期。个别成员甚至有所超出我的预期（有个意外下文说）。
还有我对「研发」工作的开发者能力、效率、定位等经验心得总结也在下文一起说。
实习生的考验
上文说的意外，我们组内其实有个试用期的加入，职能是前端。
初来两周，站会基本不说太多话，问他的领导被告知是新来的，刚入职一个月，给点时间（怀疑脸，并没有什么值得花半月去了解）
第三周，基本能开口说话昨天做了什么，今天做了什么，比如昨天对了 xxx，今天做xxx优化，“什么优化” ：“光标xxx input 事件的调整。” “。。。”
站会就是这样，你每天没产出什么，是编不出来，经不起推敲的。看板上任务很多，全凭自觉，且他所做的与业务无关无需了解太多时间，对此我已经对他有了个初步的 “懒惰印象”
我找了小组后端进行确认，委托前端的 leader 找他谈了谈。
懒惰这种东西就像是瘟疫，他会快速的在小组内流行起来，让其他拿着相同薪水的同事心里非常的不痛快，我不想让这种负能量的事情发生。
往后两周其实依旧没有起色，临近年底了，我也不想做恶人，我只能如实写出评价，祝君好运。
组员的一点心得
这么多年工作我发现两种类型的人：
- 面试一般，入职远大于期望
- 面试极佳，入职平平常常
有些人就是面试答得一般，但是试用期发现：态度很好，很积极，做事效率快，甚至交予的任务回家也干，上班基本做完了，让我有点感动，回想起我以前也是这样的，我虽然知道可能是「试用期」的因素，但是也非常难得了，态度是很重要的，我一般 关心一下, 看看代码质量、逻辑。适当增加一点任务，提前转正，也在我心里留下了一个好印象，日后有些独立的大块需求，我愿意放心交给他们去做。年终自然也会按公司制度多劳多得申请涨薪。
至于入职平常的一类人，其实是无奈的，如果他不经意间过了试用期那就更加无奈，完成一些我期望的工作即可，没有过多要求，一起开心共事就好，主要看其态度，如果态度极好主动要求加料、或参与某个产品的设计等，也会让人刮目相看。
切记：消极、负能量、懒惰、不与他人沟通。
另外有问题与同事多问，多聊。如果你也是工作积极，leader 会分配多点一点的任务给你，说明可能是：
1、你贵 2、他想提拔你
鉴于各个ledear心思不一样，自己斟酌吧。
不管怎么样，注意态度！注意态度！注意态度！莫要消极对待。
试用期的抉择
我和公司另外一个leader看法不同，我倒是觉得他更有道理，不过我更想为长远考虑。
他的做法： 给试用期的同事多分配一些工作！让其饱和，观察能力和效率，差不多了就转正，不行就换掉。
我的做法： 告知需求，一起听需求，告知他我对这个需求的看法，注意点，技术栈，刨去熟悉的时间，我给一个我期望的他绝对能完成的时间。全凭他自觉，
- 若超了
我仔细看看代码，考虑考虑是否再给机会
- 若一天不差完成了
看看代码已计提交历史是否游刃有余，判断下潜力，我也一天不差的三个月转正。
- 若是提前了很多天
我真的遇到过，有个同事我 9.30 号给的任务，预计10天，一块需求，也差不多了，结果可倒好，10 月放完国庆，上班就告诉我写完了，我看了看代码基本没啥大的问题，调整下，一个多月就给转正了。
每个 leader 都有自己的「眼睛」盯着你，并不是要大家多努力，而是奔着自己的目的去干活，若你就想混混就行，注意别踩红线，混着就行。
如何巧妙和同事沟通
todo 单抽下章
如何向同事提问
todo 单抽下章
如何与 leader、cto 沟通
todo 单抽下章