软件工程之美
宝玉
Groupon 资深工程师,微软最有价值专家
43658 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 55 讲
软件工程之美
15
15
1.0x
00:00/00:00
登录|注册

11 | 项目计划:代码未动,计划先行

你好,我是宝玉,我今天想与你聊一聊“项目计划”的问题。
若干年前,我接手一个陷入困境的项目,当时的项目经理刚从技术高手转型项目管理,还是没有摆脱技术思维,项目没有什么计划。
他把关键模块分给了自己开发,同时还要兼顾项目管理,导致自己的工作遇到瓶颈,其他人的进度也受影响,大家加班加点也没什么进展,士气低落。
我接手后,第一件事是重新制定项目计划,在排任务时,避免了对某个人的过度依赖,设置了几个关键里程碑。我还特地把第一个里程碑设置的相对容易一点,只需要运行核心功能。
这样大家重整旗鼓,很快就完成了第一个里程碑。达到第一个里程碑的目标后,团队成员很受鼓舞,士气很快就上来了,后面按照新的计划,并没有太多加班加点,就完成了一个个的里程碑,最后顺利完成项目。
你看,如果没有计划,你的项目可能会陷入一种无序和混乱中。
计划,就像我们出行用的导航,你可以清楚地看到项目整体的安排,同时它还时刻提醒我们目标是什么,不要偏离方向。
执行计划的项目成员,就像使用导航的司机,可以知道什么时间做什么事情,保证任务得以执行。执行计划的过程,就像我们沿着导航前进,可以了解是不是项目过程中出现了偏差,及时的调整。

做技术的就不用关心计划吗?

确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件工程之美》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(44)

  • 最新
  • 精选
  • Winder
    宝哥,能讲一下你在极客上开这个课题的计划吗?如何以面向工程的思想完成这个课题😁

    作者回复: 其实你知道吗?在这个项目中,我不是项目经理,我其实是程序员,项目经理是编辑,她定的计划,而且不同意我放出来😄 而且她还活学活用,基于敏捷的写作模式,一个Sprint一个Sprint反复迭代,你看到的每一个发布版本可能已经迭代修改过好多版了!

    2
    45
  • MiracleWong
    # 根据自己的经验写一下: 1. 很多的时候,我们不愿意指定计划的原因,简单的说是“懒”,深层次的是不愿意“思考”,因为这需要做很多准备工作,并消耗很脑细胞,是对自己认知上的一个考验。再往深处挖则是“不愿意承担责任”(工作中由其会遇到类似的同事,我拿多少钱就做多少工作,偶尔自己也会成为这种人),因为要介入制定计划、以及后续的调整,就觉得这不是应该是自己的工作量。 2. 就是制定计划的颗粒度粗细的问题。自己经常会遇到类似的困扰,就是一次计划,分解的太过详细,导致行动的时候因为繁琐反而拖延或直接不做。(也明白这是一种心理上的自我欺骗,认为做了计划就等于行动了,类似于买个课程就等于学习了,收藏了就等于看了)这就会导致下一次的计划时遭到“反噬”——上一次那么详细也没什么用,还不是不做或者稍微写一下呢。等到自己没有什么目标或者虚耗摸鱼时,有记起“详细计划”的好,一次次的循环。 3. 对于宝玉老师说的是否有指定计划的习惯,我经常是每个月的最后两天,指定下周的目标(类似工作计划)。将目标和自己的工作生活学习联系起来并进行分解,分散到每个月的四4周里。每周做个小结,月底再做月总结和下月目标。目前还是在尝试练习中,在逐步的形成自己做目标和总结的固定模板,省去部分重复性的工作。 一点自己的经验,第一次写评论,希望得到宝玉老师的指正。

    作者回复: 谢谢分享和补充,讲的特别好,尤其是那句心理欺骗的,说到心坎里面了,我也常犯这样的错误! 建议计划一开始不要太细,先粗一点,定好里程碑,然后进入下一个阶段前细化,细化时拉上参与计划的人一起。这部分建议你看一下我给一路向北的留言回复。 另外个人计划我觉得你已经做的很好了👍 我建议你也可以多考虑一些长远的规划,例如五年十年的,然后针对这些大目标设置几个大的里程碑,这样再定细节的计划会更有方向感。

    23
  • hua168
    很感谢老师,很负责,每个问题都认真回答,目前是我购买这么多专栏最负责的一位没有之一,敬业呀👍,遇到负责的大牛老师就相当遇到贵人了!

    作者回复: 不用客气,有些问题也只是一家之言,你自己的情况我其实了解不多,建议你还是自己多想想,多问问你的朋友和领导们,他们可能能给出更具体的意见。

    14
  • 舒偌一
    没计划,怎么知道变化。 没计划,怎么知道进度要求。 没计划,怎么知道范围要求。 没计划,怎么知道质量要求。 没计划,怎么知道资源要求。

    作者回复: 这一段总结的太好了👍

    12
  • hua168
    我是做运维的,17年底开始计划学java开发,没有做过项目,以往习惯每年年底订明年目标计划。 订好计划之后再分月-->周(上班及周末),周末看视频学习,周1-5有时间学练习视频讲的内容。 因为自学有些不懂,当过一段时间突然有想感悟又跑到从头看,虽然慢,但觉得还是在前进着... 订的长期计划就是几前年订目标10k/月,执行步骤: 1. 网管:3k-3.5k,再订收入5k,发现网络工程师可以 2. 网络工程师:培训CCNA,让人指导自学CCNP,面试达5k,因CCIE说网络没落转运维 3. win运维:6k,主要是运维公司官网用的是asp.net,再订目标10k,听说linux运维可以,转学linux,辞职学3个月,每天10小时 4. linux运维:达到目标10k,主要是运维公司官网 5.目前:17年底开始学java开发,打算1-1.5年,边运维学python,打算升运维开发 出现了中年危机,学习中带迷茫...好像自己什么都不精,中年失业还能找到工作吗?中年的出路在哪?

    作者回复: 能理解,迷茫在于对于方向的不明确,以及未来的不确定。 建议在方向上先选准了,想想5年后做什么10年后做什么,而不仅仅是一年后做什么。 如果是5年后还想继续运维,那么想做到什么高度?是不是要去大公司锻炼一下? 如果5年后是想做管理,那么是不是得准备学习一些专业知识,是不是让自己尽早有机会管人? 想清楚未来做什么,给自己设一些里程碑,一步一个脚印,应该就没那么迷茫了。 一点建议,仅供参考:)

    11
  • tcny
    如果因为开发不紧不慢耽误了时间,如何处理呢。应该设置什么样的奖惩制度呢?

    作者回复: 这是个好问题! 计划恰恰就是为了预防类似于开发不紧不慢耽误了时间的问题。 具体例子,一个模块,正常估算(开发和PM都认可)需要5天,但是如果你的计划粒度是5天,那么你到最后一天才能知道是不是会延迟,这时候补救已经晚了。 如果你能把粒度设置到半天一天,那么第二或第三天你大概就能知道进度是不是有问题,然后马上作出调整,要么加班,要么找人帮忙,要么换人,要么改计划。这样才可以做到防患未然! 至于奖惩制度,只是手段,而不是目的!

    9
  • 小伟
    计划确实很重要,即使变化了,但是有个基准,也能帮助在项目复盘的时候知道问题出在哪儿,下次可以做的更好。 另外,项目排期一定要和其他人达成共识,并有专人去确认进度,有文档记录。 目前项目中遇到了技术性问题,导致里程碑delay一个月,但是老大也不太着急,自己感觉阻塞在这儿了。。。。

    作者回复: 遇到阻塞了要让老板知道,让老板提供帮助,不要一个人耗着,不然难有进展。 另外也可以尝试项目之外寻求帮助,例如搜索引擎、技术论坛、stackoverflow,还有像github上找找同类项目。

    6
  • 纯洁的憎恶
    因为水平实在有限,且应变能力太差,我做事前一定要做周密的计划。这反而使得我在大多数重要事情上表现不算太糟。我理解计划的意义是把事情的完整过程详细推演几遍,做到进展阶段、关键难点、资源分配、潜在风险、先期准备了然于胸。即使计划赶不上变化,也能应对自如,不会惊慌失措。凡事欲则立不预则废。 任务分解——WBS; 估算时间——广泛参与消除偏差+留出余量; 安排任务路径——甘特图捋关系+里程碑控制进度; 跟踪调整——信息共享充分沟通掌握计划进展+出现变化及时调整; 制定计划最好能让项目相关各方充分参与,这样计划更可行,偏差低,结果更可控、可预期。但我的经历却是需求、开发、运营、用户等角色几乎不参与制定计划,就连需求分析、功能设计、测试、验收也以工作忙为借口很少介入。项目管理人员主动拉他们,也遭到厌恶与不配合。在观念与体制不支持的环境里,如何能更好的调动各方充分参与、支持项目呢?

    作者回复: 你这种性质的单位我确实没经历过,缺少经验。 不过我可以帮你从另一个角度分析下,就是如果我不愿意参与计划可能有这些方面原因: 1. 跟我利益不相关,做了没好处,不做没损失 2. 你已经做的够好够细了,没什么好发挥的 3. 就算参与了提了想法和意见也没用,最后还是项目经理说的算,那我还掺和个啥劲 所以你可以看看能不能让这事变成一个跟大家利益相关的事,跟绩效考评啥的扯上关系,必要的话拉上领导狐假虎威一番,然后拉他们参与时不用太细,让他们有机会参与制定,制定时能平衡好他们利益关系。 尤其是里程碑的确定,我觉得应该是和大部分人利益相关的,至少这个点得让他们参与进去。 一点浅见,供参考

    6
  • LiYanbin
    宝玉老师, 你好!我最近从一名专职的开发人员慢慢在带人了。最近有一个功能,由我还有另外两个人一起开发,我是项目负责人。首先,我们先对功能内容进行划分,并使划分的开发内容独立,然后把开发内容分发下去。 然后为了保持整体开发计划的准确性,为了把握两个人的开发进度偏差,我去和另外两个人一起做好子功能的需求分析和软件设计,然后和他们一起做好开发内容和开发时间。 我想我的这种做法是OK的。(不知道有没有哪些点还需要注意,宝玉老师可以根据自己过来人的经验来提提) 但是我反想了,如果后面带领的是十个人,那这种方式就不太合适,如果是参与开发的人比较多,如何管理,如何控制项目整体进度偏差是比较有效的呢。我自己的想法,可以把这个十个人再分成两三个人为一个小组,然后我去管理小组组长,但是我去管理小组组长,就会导致粒度比较粗,粒度比较粗显然没办法更准去的把握这个项目的开发偏差。 宝玉老师关于这个问题能否提供一些看法。 此致 谢谢!

    作者回复: 我想你已经做的很好了,我在这里分享一点个人经验。 我在带人时会更注意发挥其主观能动性,比如说任务,我一般在开始前只是帮助指导一下方向,会让其独立去分析需求,做系统设计。当然如果是新手,会指导一下基本方法和参考案例。 在分析需求或者系统设计时,要求写简单的文档,对格式不做要求,但要求说清楚问题,要求做评审。 评审会分多次进行,一开始只讨论方向性的,逐步细化,最终才是细节。这里特别忌讳一开始就写很细节的文档,如果万一方向错了,改动成本很高,抵触心理会很强,相反如果一开始只是粗的方向性的讨论,很容易调整,也不会有太多抵触心理。 在开发的过程中,通过PR的方式,在合并master之前要对代码进行代码审查,在代码审查及时发现问题,并提出改进建议。 通过评审的方式,可以帮助其独立完成需求分析和设计,帮助其提高代码质量,通过评审的方式分享经验,让其更有参与感和收获感,降低其依赖心理,最终能独当一面。 整个过程都要注意发挥成员的主动性、独立性,多沟通,多肯定和鼓励,引导其走到正确的方向,设置合理的期望值,双方都要避免“surprise”。 人多了以后分组是很有必要的,小的设计评审可以小组长负责,但是大的设计评审还是要参与,避免大的方向上的偏差。对于代码也要抽时间进行代码审查,及时发现问题。

    2
    5
  • 小学一年级
    宝玉老师 ,在做里程碑的时候需要花时间整合做集成测试吗?就比如向您说的,服务端开发完成后需要与pc客户端联调,那这就涉及到发布,环境搭建,部署。。。 做WBS时要把这些时间也算进去吗?

    作者回复: 做里程碑要不要整合做集成测试,取决于里程碑的目标,比如说如果目标是具备测试条件可以联调,只要能调就可以;也可以定义目标是要测试验收通过,这就需要做集成测试的。 这种需要人需要时间去做的事情,都应该放到计划里面。文章中的计划表没有放,是考虑不周。

    4
收起评论
显示
设置
留言
44
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部