我不是专业的项目经理,这里不讨论大型项目管理的事情。
我们比较常遇到的可能是小型的长周期项目,比如2-4个人,做半年甚至一年的项目。这种项目通常不会有专职的项目经理,更多是由技术负责人兼任项目经理的职责,这时候掌握一些小型项目的管理经验就特别有意义了。
这篇文章的内容,能够给已经在做这类工作的同学带来些参考,对于还没有接触到的同学,看看也好,说不准,下个月,你老大就委你重任了!
以下是我的一些经验:
大型项目,我们基本都会这么做,大块切小块,设置一个又一个的里程碑,但对于小型的项目,因为觉得人员不是很多,往往容易忽略这个事情。
其实小型的长周期项目也是需要认真设置好里程碑的。
因为项目的时间长,如果只在最后时间才对项目进行验收,那是极度冒险的事情。
有可能半年甚至一年的时间,都没有人知道你们团队在干什么,你老板也不知道你们最后能不能完成任务,这是一件可怕的事情。
我接受过项目管理培训,一开始的时候也不以为然,但当自己真正对项目负责的时候,才真实地感受到,里程碑带来的真正价值。
它给你的团队带来了一个目标,使得项目不会像一个没有尽头的长跑;它给关心项目结果的人带来了一个又一个的安慰,虽然项目还没有完成,但大家知道它还正常活着;它给团队成员带来了阶段性的正反馈,告诉了团队成员,大家完成的很好,继续努力,我们可以成功!
我记得自己有一段时间负责存储项目,开始也是小团队,一开始的时候没有在意这块,也没有认真仔细的去划分里程碑,结果有一段时间的项目进展特别混乱。
内部成员对下阶段要做的事情不清晰,自己向上汇报的时候,也没有条理性,搞到很疲惫。
后来听从了高人的建议,开始设置里程碑,后面的过程就顺畅了很多。
所以大块切小块,设置合理的里程碑是个很重要的事情。
我估计大部分开发人员最讨厌的就是开会了。
产品讨论会,需求会,项目会,技术方案评审会,白天一堆的会,只有晚上时间可以用来写代码,会议简直就是时间杀手。
但小型团队的会议还是需要的,特别是两三个人合作的时候,很容易忽略这个问题。
因为坐的近,大家经常沟通,就觉得没必要再开这种会议了,其实这么想是不对的。
日常的讨论是比较随意的,正式的例会是为了帮助大家梳理,梳理自己的进展,抛出遇到的困难。
写过代码的都知道,写着,写着,就很容易陷入到代码细节里面去。
有时候跟一个bug 杠上了,可能会花几天时间去解决,殊不知,捡了芝麻丢了西瓜。
可能这个bug 根本不重要,优先级不高,却偏偏花了很多时间在上面,导致主线任务反而不够时间了。
所以这种定期的例会是很有价值的,一是为了同步进展和遇到的问题,二是让其他人及时帮自己纠正方向,不要走偏了。
开例会是有真正目的和价值的,不是为了走过场。
我们有一种站立例会,2至3天开一次。
中午饭前10分钟,大家言简意赅,分享各自事情的进展,遇到的困难和需要的资源,轮流说完就散会,吃饭去。
会议中,不讨论具体的方案细节,也不讨论具体的资源分配,这些具体的问题,由相关的负责人去讨论和解决,无关人员不参与,只是知会有这么一件事情。
这样极大节省了大家的时间,但又让大家对项目整体有了完整的了解,执行上不会出现偏差。
作为项目负责人,定期地输出项目进展是必要的职责。
这个东西不是给你自己看的,是给团队成员和项目相关人看的,最关键的是给你的老大看。
项目周报的梳理本身就要花费时间。
要列出完整的可执行的计划,是要自己思考,也要拉上项目成员一起思考的。
这个思考的过程,就逼迫大家去想清楚很多的执行细节,执行节奏和各部分的负责人。
一开始就梳理清楚,后面执行起来,就可以各司其职,不会乱糟糟。
评价一个项目是否成功有两个维度:一个是结果的成功;一个是过程的成功。
结果受很多因素的影响,受产品,也受市场的影响。
比如你是技术系统的负责人,最后你们的系统如期上线了,各方面的指标也达到了标准,但因为产品或市场的原因,最后没有成功,技术人员也是很无奈的。
但如果你整个执行过程都很透明,大家就可以感知到你们在项目执行上的成功,那也是一个不错的业绩输出了。
这是我个人很独特的一个经验。
我做存储系统的时候,给予的项目周期是半年,一开始的时候大家特别拼命,加班加得很晚。
但人不是机器,你头一天晚上加班到很晚,第二天自然就没有那么好的精神了,一两天还好,但一周下来,就受不了了。
后来觉得这么做不是办法,就跟leader 讨论,我们要的是项目的产出,不是要大家都加班到很晚,那没有实际的意义,还不如改变作息,让大家早点回去,上午早点过来。
时长还是差不多,但时间段改变了之后,人的睡眠质量高了很多,精神状态也好多了,一个月执行下来,明显感觉到精力,身体都不错,人也更有信心可以把这个项目做好。
以上是我自己以前在做小型长周期项目时候的一些经验。
在项目的初期,需要大块切小块,跟团队成员一起,讨论出合理的里程碑,为后续的执行定制好目标。
小团队例会还是需要的,但要明确例会的目标,要简洁高效,不要陷入具体细节的讨论。
项目周报其实也是一个团队的产出,是一个过程产出,执行过程的好坏,也是会被列入业绩的。
最后一个是规律的作息,这是很个人化的经验,但亲测,真的相当好,谁试谁知道!
来自:大飞码字
在当今的专业环境中,项目经理需要戴上各种帽子,在管理团队的日常功能和理解大局策略之间切换。正因为如此,项目经理对组织变得更有价值,并且他们对技能和战略角色的需求在全球范围内不断增长。但这也提出了一个问题:如何在如此高压的环境中成为更好的项目经理?
随机产生规定范围内的整数,然后再产生相同范围内的整数,两者相同时,则暂停。所用知识:Math.random() * num: 产生从0到num的随机数,Math.floor(): 向下取整,简单的DOM操作等
我马上就要毕业了没有开发经验怎么办?我投递了 N 多公司全部没有给工作机会,有的给了面试机会也是没有下文了怎么办?我简历上什么东西都没有,要不要伪造一个工作经历呢?
项目经理这个神奇的职位,改变了我很多工作处事的方式,从前性情纯真的耿直boy,现在变成了人鬼皆爱的老油条, 以下是我当了项目经理之后明白的10件事, 如有雷同,真是太巧。
pm2 大家应该都知道,主要是用来管理 node 进程,但是同样可以用来部署前端代码。也可以手动添加 public key 到服务器上的 ~/.ssh/authorized_keys,
通过 attachShadow 这个方法生成一个shadow root 即shadow的根节点,然后在这个根节点下面通过循环语句添加水印,利用position为absolute进行排版,使其铺满容器
我相信每个接受过老项目的程序员可能都吐槽过“前人的代码都是屎”。一个已经有些年头的项目,几乎肯定可以看到——到处拷贝来拷贝去的代码,随处可见的拼写错误,头重脚轻的函数……
近几年随着微服务化项目的崛起,逐渐成为许多公司中大型分布式系统架构的主流方式,而今天所说的 RPC 在这其中扮演着至关重要的角色。随着这段日子公司项目微服务化的演进,发现在日常开发中都在隐式或显式的使用 RPC
首先搭建vue项目,lint选择ESLint + Prettier,配置方式选择In dedicated config files。具体搭建过程这里就不赘述了,如果不熟悉的同学可以点击这里。配置 Stylelint,目前还没有stylelint选项,需要我们自己安装相关的 npm 包
created : 中请求数据,ajax是异步的,这个时候可能mounted已经执行完了,也就是dom挂载完了,但数据还没请求回来,无法获取到内部元素(数据渲染出来的dom)高度. 无法渲染内部元素,无法滚动
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!