很多错误可以归结为缺乏信任——但是比起开发人员,管理人员更难意识到这一点。
管理软件开发团队是一项艰巨的任务。这在直线管理包括组织结构图职责(职业发展、人力资源文案等)和需要为团队的发布表现负责时,任务就更加艰巨了。在这种情况下,你会被要求彻底了解他们的日常表现,以评估他们的表现和推动改善,尽管事实上,他们做的事情是完全不透明的。这就像是被要求同时执教一支球队和裁判一场你不知道规则的运动比赛。正如我所说,这是一项艰巨的任务。
我同意这一点,如果你是一名经理,那么在某些时候甚至是近期,你可能也是技术人员。或者,你并非技术人员,但由于你长时间地淫浸于这一行,所以耳濡目染知道了很多概念,至少在理论上能够夸夸而谈。除了这两种情况,如果有人问你,例如Alice昨日编码了什么东西,那么你能回答吗。原因或许是由于缺乏经验,或许是因为多年没有编程而“生锈”了,或许是无法跟上其他8个人的脚步,因为他们的工作对你而言是不透明的。
正如辅导/裁判你不懂的游戏,你可以学习他们的身体语言和手势。如果团队中的所有成员表示出对其中一个同事的反感,那么很有可能这个人做了“十恶不赦”的坏事。你不需要所有的上下文的线索,也不需要推动杠杆,因为这些事情一点都不难,自然而然地你就会掌握,要是它们是如此明显的话。你正在导航一个非常艰难的障碍训练。
但是同时很容易犯错误。这也是可以理解的。下面我会带大家去认识一些比较常见的错误,并提供一些建议和想法。
开发团队劳动创造的不透明性,很容易让你觉得自己无法掌控它。而对这种情况的自然冲动又非常容易矫枉过正,试图施加尽可能多的控制。绝大多数的微观管理人员并不这么看待自己,“我想成为一个难以忍受的控制狂”,而不是,“我只是现在需要参与进来,因为最后的时间期限快到了,但是当事情安顿下来之后,我会退出。“
麻烦的是,这必然会拖累团队的效率。虽然你作为一个经理,因为完全了解所有的进度而感觉更高效了。但现实的情况是,你成为了瓶颈。你必须放手,接受你无法掌控一切的事实,甚至于你可能无法对团队发生的一切做到心中有数。你需要信任你的团队,如果你不能信任你的团队的话,那么你会遭遇比临近最后期限更大的问题。因此,保持冷静,对你的团队充满信心,放手让他们工作。
迫使开发人员花时间对你详细清楚地解释事情,并不是唯一会影响他们生产力的途径。在错误的时间段宣布开会,也会影响他们的生产力。编程需要参与者进入一定的状态,才能最高效地编码。但是这种状态并不是打个响指就能进入的。这是一个渐变的过程。
很多开发人员都经历过这样的喜悦,如果看到今天没有会议来打搅他们的话,因为他们知道,这将能最大限度地提高效率。如果你开始给他们安排会议,毫无疑问会严重影响他们的情绪和生产力。而且,不同的会议时间所造成的影响也是不一样的。早晨的第一件事,午餐前后,或下班前都是不错的时间段,因为这些时间基本上不会打断他们的思绪流程。但是,随便拍板把会议定在上午10点和下午2点,那么几乎可以保证,他们那一天都没办法真正进入工作的状态。
由于管理和软件开发是我职业生涯中都经历过的角色,所以我深刻知道在开发人员最富有生产效率的时候打断他们是多么容易。Paul Graham关于管理者和决策者的日程安排写了一篇伟大的文章。这是忙碌的经理,甚至是前技术人员,很容易犯的一个常见错误,那就是根据自己的时间安排和对于信息的欲望而制定会议时间。然后让团队为此付出沉重的代价,所以最好的方法是,尽量减少开发团队的会议,然后把那些必须要开的会议安排在边缘时间。
我以前就提到过这一点,关于要如何激励开发组,你应该小心谨慎。对于开发经理所设置的有问题的目标,最典型的例子是自动化单元测试覆盖率。换一个角度思考。你为什么要设置这样的目标呢?是因为你做了一些关于如何提高软件质量减少缺陷的研究,还是因为一些文章,博客,演讲者告诉你,良好的软件组具有较高的测试覆盖率?你(不以编码为生的一类人)是不是正在试图弄清楚开发人员(以编码为生的一类人)如何才能更好地完成工作,然后强迫他们这样做?
这又回到了信任这个话题,你为什么不能让他们自己去弄清楚如何最好地完成他们的工作?如果目标是更少的缺陷或更流畅的版本,那么为什么不直接说出这些目标,让他们去解决呢?我能理解,你既想要提供帮助,又想要履行这个头衔的心情,但是在这条路的终点等你的并非是皆大欢喜。如果你将测试覆盖率定为目标,并采取相应的措施激励他们,是会成功……但是,是在测试覆盖率方面。不过,这对你的实际目标不会有太大的影响。
因此,不要自以为是地想太多。直接告诉这些聪明人你想要什么,并相信他们能够完成你的期望。
各种问题层出不穷,但归根结底可以得出一个结论。你必须相信你的开发团队。这是可以让你扩展并获得成功的唯一途径。
那么如果你不信任他们的话,该怎么做呢?嗯,这是人事问题了,而且这也是为什么组织领导岗位存在的原因——做一些艰难的决定。你需要弄清楚团队中的人员如何在专业方面值得信赖,你需要弄清楚哪里去寻找和聘请值得信赖的人。你的主要职责应该是找到可以信任的人,雇用他们,为他们清理所有的干扰因素,包括你自己,让他们能够一往无前。你做好你的工作,他们就会做好他们的工作。
在当今的专业环境中,项目经理需要戴上各种帽子,在管理团队的日常功能和理解大局策略之间切换。正因为如此,项目经理对组织变得更有价值,并且他们对技能和战略角色的需求在全球范围内不断增长。但这也提出了一个问题:如何在如此高压的环境中成为更好的项目经理?
随机产生规定范围内的整数,然后再产生相同范围内的整数,两者相同时,则暂停。所用知识:Math.random() * num: 产生从0到num的随机数,Math.floor(): 向下取整,简单的DOM操作等
我马上就要毕业了没有开发经验怎么办?我投递了 N 多公司全部没有给工作机会,有的给了面试机会也是没有下文了怎么办?我简历上什么东西都没有,要不要伪造一个工作经历呢?
项目经理这个神奇的职位,改变了我很多工作处事的方式,从前性情纯真的耿直boy,现在变成了人鬼皆爱的老油条, 以下是我当了项目经理之后明白的10件事, 如有雷同,真是太巧。
pm2 大家应该都知道,主要是用来管理 node 进程,但是同样可以用来部署前端代码。也可以手动添加 public key 到服务器上的 ~/.ssh/authorized_keys,
我不是专业的项目经理,这里不讨论大型项目管理的事情。我们比较常遇到的可能是小型的长周期项目,比如2-4个人,做半年甚至一年的项目。这种项目通常不会有专职的项目经理
通过 attachShadow 这个方法生成一个shadow root 即shadow的根节点,然后在这个根节点下面通过循环语句添加水印,利用position为absolute进行排版,使其铺满容器
我相信每个接受过老项目的程序员可能都吐槽过“前人的代码都是屎”。一个已经有些年头的项目,几乎肯定可以看到——到处拷贝来拷贝去的代码,随处可见的拼写错误,头重脚轻的函数……
近几年随着微服务化项目的崛起,逐渐成为许多公司中大型分布式系统架构的主流方式,而今天所说的 RPC 在这其中扮演着至关重要的角色。随着这段日子公司项目微服务化的演进,发现在日常开发中都在隐式或显式的使用 RPC
首先搭建vue项目,lint选择ESLint + Prettier,配置方式选择In dedicated config files。具体搭建过程这里就不赘述了,如果不熟悉的同学可以点击这里。配置 Stylelint,目前还没有stylelint选项,需要我们自己安装相关的 npm 包
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!