本文共 2162 字，大约阅读时间需要 7 分钟。

我不是专业的项目经理，这里不讨论大型项目管理的事情。

我们比较常遇到的可能是小型的长周期项目，比如2-4个人，做半年甚至一年的项目。这种项目通常不会有专职的项目经理，更多是由技术负责人兼任项目经理的职责，这时候掌握一些小型项目的管理经验就特别有意义了。

这篇文章的内容，能够给已经在做这类工作的同学带来些参考，对于还没有接触到的同学，看看也好，说不准，下个月，你老大就委你重任了！ 

以下是我的一些经验：

大块切小块

大型项目，我们基本都会这么做，大块切小块，设置一个又一个的里程碑，但对于小型的项目，因为觉得人员不是很多，往往容易忽略这个事情。

其实小型的长周期项目也是需要认真设置好里程碑的。

因为项目的时间长，如果只在最后时间才对项目进行验收，那是极度冒险的事情。

有可能半年甚至一年的时间，都没有人知道你们团队在干什么，你老板也不知道你们最后能不能完成任务，这是一件可怕的事情。

我接受过项目管理培训，一开始的时候也不以为然，但当自己真正对项目负责的时候，才真实地感受到，里程碑带来的真正价值。

它给你的团队带来了一个目标，使得项目不会像一个没有尽头的长跑；它给关心项目结果的人带来了一个又一个的安慰，虽然项目还没有完成，但大家知道它还正常活着；它给团队成员带来了阶段性的正反馈，告诉了团队成员，大家完成的很好，继续努力，我们可以成功！

我记得自己有一段时间负责存储项目，开始也是小团队，一开始的时候没有在意这块，也没有认真仔细的去划分里程碑，结果有一段时间的项目进展特别混乱。

内部成员对下阶段要做的事情不清晰，自己向上汇报的时候，也没有条理性，搞到很疲惫。

后来听从了高人的建议，开始设置里程碑，后面的过程就顺畅了很多。

所以大块切小块，设置合理的里程碑是个很重要的事情。

小团队例会

我估计大部分开发人员最讨厌的就是开会了。

产品讨论会，需求会，项目会，技术方案评审会，白天一堆的会，只有晚上时间可以用来写代码，会议简直就是时间杀手。

但小型团队的会议还是需要的，特别是两三个人合作的时候，很容易忽略这个问题。

因为坐的近，大家经常沟通，就觉得没必要再开这种会议了，其实这么想是不对的。

日常的讨论是比较随意的，正式的例会是为了帮助大家梳理，梳理自己的进展，抛出遇到的困难。

写过代码的都知道，写着，写着，就很容易陷入到代码细节里面去。

有时候跟一个bug 杠上了，可能会花几天时间去解决，殊不知，捡了芝麻丢了西瓜。

可能这个bug 根本不重要，优先级不高，却偏偏花了很多时间在上面，导致主线任务反而不够时间了。

所以这种定期的例会是很有价值的，一是为了同步进展和遇到的问题，二是让其他人及时帮自己纠正方向，不要走偏了。

开例会是有真正目的和价值的，不是为了走过场。

我们有一种站立例会，2至3天开一次。

中午饭前10分钟，大家言简意赅，分享各自事情的进展，遇到的困难和需要的资源，轮流说完就散会，吃饭去。

会议中，不讨论具体的方案细节，也不讨论具体的资源分配，这些具体的问题，由相关的负责人去讨论和解决，无关人员不参与，只是知会有这么一件事情。

这样极大节省了大家的时间，但又让大家对项目整体有了完整的了解，执行上不会出现偏差。

项目周报

作为项目负责人，定期地输出项目进展是必要的职责。

这个东西不是给你自己看的，是给团队成员和项目相关人看的，最关键的是给你的老大看。

项目周报的梳理本身就要花费时间。

要列出完整的可执行的计划，是要自己思考，也要拉上项目成员一起思考的。

这个思考的过程，就逼迫大家去想清楚很多的执行细节，执行节奏和各部分的负责人。

一开始就梳理清楚，后面执行起来，就可以各司其职，不会乱糟糟。

评价一个项目是否成功有两个维度：一个是结果的成功；一个是过程的成功。

结果受很多因素的影响，受产品，也受市场的影响。

比如你是技术系统的负责人，最后你们的系统如期上线了，各方面的指标也达到了标准，但因为产品或市场的原因，最后没有成功，技术人员也是很无奈的。

但如果你整个执行过程都很透明，大家就可以感知到你们在项目执行上的成功，那也是一个不错的业绩输出了。

规律作息

这是我个人很独特的一个经验。

我做存储系统的时候，给予的项目周期是半年，一开始的时候大家特别拼命，加班加得很晚。

但人不是机器，你头一天晚上加班到很晚，第二天自然就没有那么好的精神了，一两天还好，但一周下来，就受不了了。

后来觉得这么做不是办法，就跟leader 讨论，我们要的是项目的产出，不是要大家都加班到很晚，那没有实际的意义，还不如改变作息，让大家早点回去，上午早点过来。

时长还是差不多，但时间段改变了之后，人的睡眠质量高了很多，精神状态也好多了，一个月执行下来，明显感觉到精力，身体都不错，人也更有信心可以把这个项目做好。

最后

以上是我自己以前在做小型长周期项目时候的一些经验。

在项目的初期，需要大块切小块，跟团队成员一起，讨论出合理的里程碑，为后续的执行定制好目标。

小团队例会还是需要的，但要明确例会的目标，要简洁高效，不要陷入具体细节的讨论。

项目周报其实也是一个团队的产出，是一个过程产出，执行过程的好坏，也是会被列入业绩的。

最后一个是规律的作息，这是很个人化的经验，但亲测，真的相当好，谁试谁知道！

转载地址：https://blog.csdn.net/zl1zl2zl3/article/details/91042774 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！