Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: 添加出差北京项目编程小故事 #7

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 71 additions & 0 deletions docs/coding-story/beijing-business-trip.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
# 谋事在人

## 前言
本文记录 2019年8月 北京国网项目期间三两事。成事有三,天时地利人和,下面分享几个关于「人」的故事

## 不作无谓的争吵
> 作者寄语:坚定自己的方向,去**的闲人闲语
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

把口语化的内容转化成更正式的书面语。

去**的闲人闲语


产品经理 vs 开发,互联网行业内经久不衰的话题。

一个紧急需求的上线前夕,产品经理突然在工作群内指出开发没有按照原型和 PRD 实现需求。然而需求功能当晚需要上线已经是不争的事实。面对产品经理的职责,我给出两个方案:

1. 不满足需求的地方留到下次迭代完善
2. 本次上线,将不上线这个不完善的功能需求

然而产品经理并没有理会,仍然在责骂我,面对一顿冷嘲热讽,终于上演了一出工作群内「骂街」的闹戏。虽然理性告诉我,不管如何,项目交付都需要继续进行,但愤怒的情绪还是突破了理性的防线。

事后回想过来,如果项目不能按时交付,这场争吵谁都不是赢家。出现问题不应该先想到找谁「背锅」,而是思考,如何「解决」问题,让事情能继续下去。

而我停下脚步加入骂战,耽搁了原本的事务。有这个心情在工作上作无谓的争吵,不如赶紧把工作完成,继续追寻自己内心的「小九九」。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

「小九九」


## 走出舒适区
> 作者寄语:做好变化的准备,并扩展自己的舒适区

三年工作经验,新入职的前端开发小T。入职后的第一个任务,我在旁边看着他在自己的 win7 上打开了 cmd。原本以为是一个对自己电脑了如指掌的极客,所以才不愿意使用新系统。

然而一个本该 1h 完成的任务,硬是花了一整天。时间都浪费在折腾如何使用工具上,而不是如何完成任务。原本以为他带着自己的电脑(舒适区)会得心应手。结果这天下午,我手把手把代码塞到他的「嘴里」。

我:现在要获取 cookies,你去装个依赖吧。

小T:`npm install js-cookie --save`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

过多的技术细节,不写js的人,看不懂。

实在不舍得细节,可以放在最后面,作为附录


我:我们项目要用 `yarn`

小T:`yarn install js-cookie --save`

我:😅

小T:怎么报错了 `Cookies is not defined`

我:你没有 `import` 依赖啊

小T:`import Cookies from '../../node_modules/js-cookie/index.js'`

我:😅😅

后来我问他以前是写什么的(我对他的工作背景一无所知),他说 `typescript`。以前代码基本都是 copy 就可以了,不用记这些东西,编辑器都有提示。

于是我明白了,他这三年都在别人铺好的路上过来的。一旦离开了别人设定的道路,便不知接下来何去何从。基于 `typescript` 的自动 `import` 和智能提示都不是他连基本 api 都记不住的借口。他在别人建好的舒适区待太久了,根本没有做好迎接变化的准备。

所以不能被工作内容,限制了自己。要有意识的往外走,拥抱未知。如果现在的工作不能提升自己某方面的能力,那么就要争取有挑战的任务。工作不能满足于混口饭,否则你将很快被社会淘汰。

## 番外篇
为什么会与上面两个故事的主人公相遇?

主要原因:招聘 —— 招到不合适的人

此出差之行,我也接触了一下前端招聘。也对招聘加深了一些理解。在不同的环境、背景、团队成熟度下,招聘的策略也会有稍许变化。

团队初建时,核心更加倾向于提高团队的效率。所以就有一个很简单的基准,候选人的生产力能不能超过团队中 50% 的成员。如果是,那么这是一个值得聘用的候选人。

随着团队逐渐壮大,会形成团队独特的工作风格和习惯。这个时候的招聘,就不能单单考察候选人的技术能力,能否提升团队的生产力。还有另外一点非常重要也容易被忽视的,那就是,候选人能否融入现在团队习惯的工作模式中。通俗一点说就是「三观」匹不匹配。可以用一个比较主观的方式来判断这一点,和候选人沟通起来费不费劲,配合工作的时候恼不恼火。如果答案都是否定的话,那确实是招到一个不错的候选人。

单单考虑技术能力,这是高效率的招聘策略。而想要找到合适团队的人,则要花更多心思在人的品性上。当然,技术能力仍然是第一考察要素。

最后其实还有一点,就是制度的问题。人力的分配与招聘更多的是指派式的,也就是面试流程中没有项目中团队成员的参与,直到人力资源被分配到项目,直接用人的项目才知道有这么一个人,但是对他背景经历的了解几乎等于零。让前线的团队承担重新培训但是最后也不合适的风险。这样的流程正正就是只看重所谓的「面试时」的技术能力,忽略了「人」的品性。

如果以后我需要给项目招聘,我会把决定权交给直接用人的团队。他们觉得 ok 才是真的 ok。

## 结语
这次出差,也算是我走出舒适区的一步。第一次出差,第一次以管理者的角色融入完全陌生的团队。将来我也会从舒适区再向前迈进,下次我要做到 `1 + 1 > 2` 的效果。我希望能提高原本团队的上限,而不是用人数来堆凑团队的上限。