轻量级的报表、文档可以有效地帮助敏捷团队更好的将工作可视化、辅助和客户的沟通、清晰的展示进度并且对风险进行把控，对项目管理有很好的作用。在过去的项目管理经验中，个人认为有五类图表是项目经理需要了解并且可以在日常工作中频繁使用的。

敏捷的价值观强调可工作的软件更加重要，但也不能否认文档的价值。

燃尽图 ( Burndown Chart )

燃尽图是敏捷项目中最频繁使用的一类图表，它是在工作完成前对于进度的一种可视化表示。我们经常会利用迭代燃尽图来监控用户故事是否如期进行，当然也可以利用Feature燃尽图来监控MVP的完成情况。如下图：

该图横轴是时间，纵轴是剩余的用户故事点，灰色线是按照团队平均速率用户故事应该被完成的情况（水平部分是周末），蓝色线是实际情况。通过此图我们可以很清晰地看到该迭代团队的开发速率高于期望并且差距不是很大，项目处于很健康的状况。如果蓝线一直高于灰线或者蓝线偏离灰线太远，项目经理就需要注意了，有可能的原因包括迭代计划不合理、团队开发速率出现了问题等，这会导致团队在迭代后期Backlog不够或者迭代结束不能正常完成计划的点数，所以需要项目管理者和团队一起分析具体的原因并且尽快采取措施。

速率表 ( Velocity Chart )

敏捷开发以迭代为周期开展工作，在每个迭代开始之前都会按照团队的平均Velocity来安排迭代计划，所以持续地关注团队的Velocity便于更准确地了解团队的交付能力，更合理的做迭代计划。项目经理通过Velocity表可以从总体上分析团队的开发速度是否正常、迭代计划是否合理以及对于剩余的Scope是否有交付的风险。如下图：

该图表横轴是迭代，纵轴是完成的用户故事点数，绿色表示实际完成的故事点数，灰色表示按照团队能力应该完成的故事点数。通过该图我们可以看到绿色和灰色虽然有时不同但一直比较接近，团队处于很健康的状况。如果绿色和灰色某一次或者总是差距很大，有可能的原因包括某一段时期的feature复杂度提升、团队内频繁的人员调整或者各类会议增多导致的开发时间减少等，这时候项目经理就要意识到团队可能有交付风险或者需要调整迭代计划了。

甘特图 ( Gantt Chart )

甘特图也叫横道图，是项目管理领域最常用到图表形式，一般用来展示活动或者事件随着时间和费用的变化，通常会包括活动清单、活动日期、进度期限和每天的进展。在敏捷项目管理中，我们可以借助甘特图来可视化某个特定项目（包含一系列的子活动）的进展。如下图：

该图拿数据迁移这一事件为例，横轴是时间，纵轴是完成数据迁移需要的一系列活动，相同颜色代表同样的活动，灰色表示还没有完成的工作。通过该图可以看到数据迁移的大部分工作已经完成，只剩下最后的POC2的数据分析，并且能看到各项子活动的实际耗时，便于之后类似活动的计划和安排。在敏捷项目中我们还可以借助甘特图来管理Epic用户故事的进展、预算的花费情况等，如果发现某些子活动没有进展，或者消费超过预算太多，项目经理就要考虑采取一些措施推进某些子活动或者消减某方面的投入了。

日报 ( Daily Update )

以上三类是通用的一些图表，很多项目管理软件已经支持，比如 Jira, Mingle 可以自动生成燃尽图和速率表，甘特图有专门的绘制软件。而日报是我们在离岸交付项目长期摸索的过程中使用最频繁也最重要的一个图表，对于每日的沟通非常有用。如下图：

该图分为三大块，首先是每天的用户故事进展，然后是已有的Backlog的情况，最后是开放性问题，绿色背景是每天内有变化的故事卡，黄色是由于各种原因被block的故事卡，该报表的目的不是为了汇报工作，而是为了让异地的团队和客户对于每天的进展都能一目了然。虽然我们有项目管理工具比如Jira等，但是对于离岸团队来说，通过这样的图表更能清晰地看到每天的变化，让不和我们坐在一起的客户增加信心，也便于我们把遇到的blocker可视化出来。

红黄绿报告 ( RAG Report )

RAG是Red，Amber，Green的缩写，该报告采用了和交通灯一样的呈现方式，简单易懂，可以用来做项目、人员等的健康度报表，拿项目健康度报表举例，项目经理可以按照自己项目需要关注的维度制定该表，然后定期监控每一项是否健康，对于敏捷团队来说，一周一般就可以了。如下图：

该图横向是项目是否健康需要考虑的几个维度，纵向是时间，每一个单元格里的颜色采用了RAG，红色表示该项出现了严重的问题，如果不尽快采取措施，会有不能接受的影响；黄色表示有一定的影响，团队已经在通过一些方案减小影响；绿色表示该项如期进行。通过该图可以看到该项目在过去的三周没有严重问题，总体来说比较健康，People方面虽然在第一周遇上了一些问题但是通过采取措施已经完全解决，Legal方面目前还在尝试解决。如果发现有红色出现或者某项持续绿色，项目经理就需要马上找相应人员采取措施了。

总结

任何一个报表都只是辅助工具，如果绘制或者更新报表的过程非常繁琐，那么这样的报表读起来也一定不会轻松。本文推荐的五类报表是我在敏捷项目管理过程中认为简单易用并且很有帮助的一些报表，通过使用他们，可以辅助我们管理进度、高效沟通、预知风险。当然，除了本文提到的五类报表，项目经理还需要了解一些其他的报表，比如基本的财务报表等，这部分跟团队开发模式没有太大的关系，所以没有加入到本文的范围。

文章来源于聂子云 ，作者聂子

敏捷项目是为应对变化和不确定性而生，作为项目的管理者（PM或者承担项目管理职责的人），在管理的过程中，需要明确项目的目标，带领团队，选择合适的实践，管理干系人的期望，协调和客户的关系，最终以专业的方式交付客户满意的结果。
简单来讲，需要关注四个维度的工作内容，也称为项目管理的 4P 领域。

People（人）：包括客户、团队和自己，工作目标是灵活的调整和切换自己的角色，来协调这三者的关系，发挥1+1+1>3 的作用；
Purpose（目的）：项目管理的目标是什么，以什么目的为出发点去进行项目管理；
Practice（实践）：选择哪些合适的实践活动来帮助完成上述目标；
Professionalism（专业）：做好干系人管理，专业的完成项目交付。

01 People （人） 的管理领域

包括客户、团队和自己，项目经理在这个领域需要灵活的调整和切换自己的角色，通过协调这三者的关系，带领所有人完成项目目标，这个领域的工作内容，可以通过面向团队/个体，是推的方式还是拉的方式将PM的角色分为四种：

第一个角色是Leader(带头人，领导者)，作为Leader，PM 需要拉着团队一起做计划，完成项目交付目标，影响客户，过程中识别、控制并管理交付风险，管理客户关系和客户期望，加强团队的凝聚力，激励团队发挥高效能。
第二个角色是Facilitator（引导者，促进者），作为Facilitator，PM需要组织会议，跟踪行动，推动团队完成会议的行动事项，需要引导讨论，保证讨论和沟通的效率和良性产出，还需要推动并激励团队分享，在团队内部营造一种学习成长的氛围。
第三个角色是Supervisor（指导和督导者），作为Supervisor，PM需要对个体的行为进行监督和指导，提供反馈，帮助个体提升和成长；需要建立机制强化每个个体的正向行为，总结经验反思教训；还需要和相关的角色（比如TL，BA，QA）合作对流程、质量、目标进行管控。
第四个角色是Mentor（导师），作为Mentor，对团队成员要有细致的观察和了解，激励和培养团队成员；帮助团队成员突破局限获得成长；也要认识到个体差异性，基于差异分配任务设置挑战，指导并提供支持。

02 Purpose （目的） 的管理领域

在这个工作领域，PM 需要分析实施当下项目的目标是什么，不是所有的项目都是为了满足同样的目标，也就是说，项目管理是特定目标导向的。

内环是项目管理要考虑的一些约束，实际项目管理中，PM需要基于现实场景对这些约束下的目标做优先级排序，外环是实施项目可能会带来的整体价值，有时项目真正的价值是外环中的某个目标。
比如，领域经验，有时候我们会遇到一些未涉足领域的项目，这个领域可能是业务长期发展所要拓展的领域，那么组织有可能为了取得这个领域的经验而放低财务目标和成本控制，而投资这样一个项目；
又比如，有时候我们遇到的项目可能会提供很好的机会来培养团队的能力，那我们可能会在团队成长和按时交付上面找到一个平衡点。
总之，上述都是项目管理的目标，PM要做的是对这些目标做优先级排序。

03 Practice （实践） 的管理领域

这个领域有成熟的实践可借用，PM 需要做的是根据项目的实际情况选择合适的实践活动。

推荐每个PM 都了解一下Scrum 项目管理的 3355 核心要点。

3个核心角色

Scrum Master（敏捷教练）：对应敏捷团队的PM（项目经理），职责是促进团队的工作，帮助团队熟悉与掌握 敏捷的价值观与框架，帮助团队排除影响生产力的障碍，保护团队不受打扰。
Product Owner（产品负责人）：对应敏捷团队的BA（需求分析师），职责是定义需求，定义需求的优先级，定义需求的验收标准，定义产品发布内容与日期。

Scrum Team（敏捷团队）：通常来讲是敏捷的全功能团队，对交付负责，协作开发，可能跨职能部门，自组织式的扁平化团队。

3个工件

产品待办事项 (Product Backlog)：即产品视角的需求清单，由 Product Owner 负责维护，包括增删及优先级，用户故事是其中一种最佳实践，每项需求都需要描述其外部价值。
迭代待办事项 (Sprint/Iteration Backlog)：即此次迭代周期内规划要完成的内容，由团队评估和选择产品待办事项中中哪些放入迭代待办事项，团队需要一起定义“完成”的标准。
迭代产出成果（也叫迭代可交付产品增量 ，Increment)：即迭代结束后可对外发布的产品功能增量部分，需要关注其是可工作的软件功能增量，需要在成果展示会议（showcase) 上进行演示。

5个关键事件

迭代 (Sprint/Iteration)：1-4周，固定周期，固定时间开始，固定时间结束。
迭代规划会 (Sprint/Iteration Planning Meeting)：核心议题是下一个迭代要实现的目标和范围，对产品待办事项中的事项进行估算，以作为是否放入下个迭代的参考，输入是产品待办事项 ，输出是迭代待办事项。
每日站会 (Daily Standup)：站会的目标是促进信息在团队内共享与透明，回答3个问题：本次会议之前，我做了哪些事情？本次会议之后，我准备做什么事情？目前我是否碰到障碍，是否需要帮助？
成果展示会议 (Review/Showcase)：在迭代结束开，展示本迭代的产出，团队全体参与，邀请相关干系人参与提供反馈。
回顾会 ( Retrospective）：团队一起复盘本迭代的过程，总结经验与教训，并形成切实可行的改进清单。

5大价值观

承诺 Commitment - 愿意对目标做出承诺；

专注 Focus – 全身心都用到承诺的工作上去；

开放 Openness – 团队内所有信息对所有人开放；

尊重 Respect – 每个人都有他独特的价值和经验；

勇气 Courage – 勇于承诺，履行承诺，敢于说不。

04 Professionalism（专业） 的管理领域

这个领域主要指的是如何通过管理干系人，为客户提供专业的服务。
首先，需要做的是对干系人进行分类，干系人分类的方法有很多，下面介绍的这种是基于干系人的权利和对项目的赞同程度来分的：

针对每一类型的干系人，进行区别管理：

1. 对于位高权重且立场坚定的干系人，需要做的是建立同盟，邀请决策；
2. 对于位高权重但容易动摇的干系人，需要做的是管理争议，帮助其坚定信心；
3. 对于权利较低，左右摇摆的干系人，需要做的频繁沟通，尽量争取；
4. 对于权利较低，死心塌地的干系人，需要做的是并肩作战，打听情报。

其次，需要在深度了解客户的基础上，通过自己的专业经验和服务态度引领客户做出最优的决策，并且帮助客户落地解决问题。
深度了解客户是提供专业服务的第一步，PM 需要带领团队了解客户业务、行业信息、竞争对手信息等等，切实站在客户的角度思考客户的痛点和诉求。
引领客户是在对客户业务了解的基础上，结合我们的能力和所能提供的服务，在客户的诉求和我们的服务之间建立联系，影响并带领客户去思考解决问题的思路和方向，优化决策的过程和结果。
践行我们的方案，帮助客户落地解决问题，也就是项目实施的过程，利用我们的最佳实践和能力，帮助客户把想法变成结果，做到价值交付。

总结

敏捷项目管理既是一门科学，又是一门艺术，它有规范严谨的理论体系，也有广阔的空间和自由度由管理者基于经验来发挥。真正做好敏捷项目管理，需要管理者在以上维度的基础上做更多深入的思考和总结，希望通过这个简单的总结，和大家共同探讨，一起在这条道路上精进。

本文在腾讯内部论坛被浏览达7347次，收藏615次，评论几百条，曾经是讨论最热烈的项目管理文章之一。

作为作者本身，感觉这个话题可以讨论的范围非常大，希望能有更多朋友一起切磋探索技术团队的管理之道。

资深程序员是团队中最强大的生产力，但往往被不合理的工作安排浪费掉。

因此作为一个团队的技术的“头”，必须要有明确清晰的认识，把主要的事务性工作剥离出来。并且放弃大量的管理“权力”，以提高团队开发质量和效率为最主要的目标去安排自己的工作。

一般来说技术总监其实会被要求做事实上是2个职位的工作：主程、项目经理（技术化）。

因此必须明确此两个职位的工作任务分割。然后把项目经理的工作，安排给另外一个人做，当然其职称可能同样也得叫“技术总监”或“主程”，总之听起来越牛X越好。

而真正的主程（技术总监）则应该投身于尽量多的技术工作中。而最重要的工作则是开发——生产代码和文档。

主程的工作：

一、开发

从来没有一个资深的外科医生会放下手术刀，而转到手术室外面指手画脚。一个资深的程序员也不应该离开代码和文档的编写，而只是做做架构图。

作为对一个复杂系统的负责人，必须亲手领导和参与建造，才能有足够的能力去负担起这个责任。

因此需要至少使用60%的时间来参与开发的工作，并且建议从一开始上班就开始，虽然早上的效率很低，但是跟任何艰巨工作都一样：万事开头难。

在你好不容易等待电脑慢吞吞的打开了所有的IDE、需求文档、参考资料、工作计划这堆要命的东西之后，你就迈出了最重要的一步，你会发现你不在需要在网上看微博和聊QQ来提振开始工作的激情，而会被某一个优化代码的灵感而激励，或者被一个复杂而有趣的问题所吸引，从而更快的能投入到开发中。

坚持打开电脑做的第一件事是打开IDE软件，是这一切最重要的一步。

开发的工作内容包括有：

1、提出非功能性需求

一般来说功能需求总是让开发人员焦头烂额的主要原因。但是实际上很多项目死在发布之后，却是因为性能、产品质量、扩展性、二次开发效率等非功能性需求没认真去解决而导致的。

主程作为经验最丰富的成员，必须要利用自己曾经的经验和教训（在这里教训往往比经验重要），提出那些自己折腾自己的“非功能性需求”，来保障整个项目在发布后不会轰然倒塌。

这是个吃力不讨好的工作，因为老板和客户往往只会抱怨技术人员在玩弄把戏，骗取更多的资源或者杞人忧天。如何说服这些家伙也许不是主程的工作，但是主程必须要以高度的责任心把问题放到台面上来。沟通的工作也许让项目经理去做会更好，他们有一整套如何威逼利诱老板和客户的戏法。

2、设计和修正软件架构

软件架构设计至关重要，而且工作繁重。不画图纸就敢开工的技术人员要么是天才要么是笨蛋。

对于团队来说，架构在分工合作、避免风险、提高质量等多个方面有无可替代的作用。架构要避免成为空洞的文档，最重要的一步是有人来掌控和实施。而主程主持设计和修正的架构，并且亲手实施，让团队中的腹诽之徒完全无法避开，否则代码将无法运行！

所谓设计和修正架构，并不意味所有的文档应该一个人写，而是指这个架构的每个环节，都是经过主程决策同意的。当然最好这些文档能尽量由他撰写，对于“菜鸟”团队来说，输出这种文档本身就意味着“权势”，有助于主程建立个人威信——这种看起来有点肮脏的“政治”东西，在避免团队内无止境的扯皮，以及稳定那些随时准备跳槽的成员来说，都是相当实用的。

3、难点代码（关键需求）的开发

主程必须写代码，写那些大家都认为风险大的代码。

有的系统对于性能要求很高，他就必须去完成容易出性能问题的部分，比如IO操作或者设计数据库索引。有些系统的需求非常飘忽，他就要去想办法完成框架代码或者脚本引擎，以便众多小弟可以跟着产品人员疲于奔命。这种工作内容会让主程不必完全的读过所有代码，而能牢牢的“掌握”代码，以免团队成员甩耙子的时候能充当备胎。因为融入团队的代码开发，也是一个让架构设计从日常工作中真正控制系统的工作。而且主程代码通常会被别人接触，能直接教育其他团队成员，同时也能建立——威信。

4、救火和杀虫

这个工作其实和代码开发是一致的，如果没有平日的开发，通常紧急问题的解决也是比较难处理的。但是这个也有一个调试技巧的要求，比如要求会使用各种诊断工具。这些工具一般的开发人员可能会比较少使用。找问题的过程本身也可以提高团队其他人的技术水平。

二、培训

培训的工作应该占用30%左右的工作时间。培训是稳定团队人员最重要的手段。也是提高团队开发效率最有效的手段。工具、过程、制度、奖惩，这些都代替不了程序员一行行的去写代码，最直接的方法是让他们做的更快更好，这些需要经验和知识的积累。

1、代码审查

关于代码审查，有太多的论述。但是代码审查还是一种“强迫”推行某种风格或者技巧的手段，这是最真实的“控制”系统的手段。也是推广知识和经验最直接的手段。

一个人写的代码通常应对的问题不会特别“广泛”，因此只要审查其中一部分代码，就能给大部分别的代码带来好处。

2、技术方案评审

什么事情应该写一个技术方案，然后进行评审，这是一个关键的问题。

一般认为开发时间在2周以上的单项工作应该先做个方案。往往技术方案是系统架构的完善和补充，或者是挑战。所以主程的参与是非常必要的。

但是要注意不需要去做的太琐碎，而是要提炼出“关键”的需求和“关键”的解决方案进行评审，而这些“关键”往往不是功能，而是质量上的需求，如这个系统的扩展性，是否能方便后续开发等等。

也有可能在这些会议上会发生争吵，但是决策人是主程的地位是不容动摇的。君子和而不同，每个程序员都可以拥有自己的看法，但是代码必须能按方案运行起来，主程必须经常申明这点。

3、学习与讲座

如果团队碰到问题，没有新的方法和技术去解决，是不会提高开发效率的。就好像你用牛来耕地，不管用什么管理方法，都不会赶上机械化的速度。

而主程承担着不断突破自己的技术上限，介绍和推动团队使用更新的技术来解决问题的责任。抱残守缺，思想僵化，最后会被团队成员所抛弃，而且也会让团队的效能落后于业界，最后直接影响产品的生死。

每年学一门新语言，这个说法可能有点激进，但是这也是作为程序员应该有的激情。

三、管理

管理等于权势？管理等于沟通？管理等于文山会海？多年专业训练出来的技术人员如何去做管理？

管理的目标是提高绩效，如果和这个目标无关，而只是和“管理者”这个头衔有关的事情，最好丢给别人去做，包括那个头衔。

管理主要手段是创新：想出新的方法去解决问题，而不是繁杂的事务性工作！——一个专业秘书能比主程做的好一百倍。

技术工作的创新，最主要还是在技术工作里面，而不是跳出来说：做这个，做那个。

管理的事情如果超过10%的工作时间，等于说你更像一个项目经理而非主程。

1、绩效评定

以专业的意见来衡量别人的工作，这个负担是无人能够承担的。这个工作往往是利益分配的一种手段。类似奖惩手段。这种管理方法已经不是新事物了。

但是实际上技术人员对于绩效往往持一定保留和暧昧的态度，因为这种事情难以很清晰的界定出来。需要判断而非量度，才是绩效的真正手段。

如果一定要打分，一共两项足够了：进度、质量，5分制即可。

更重要的事情是，告诉每个人主程的看法，告诉别人，怎样做才是更好。或者告诉团队，怎样做才更有利于我们成功（发财、上市、赢得老板和客户……）——把目标清晰告诉团队，发挥他们的主动性，是绩效评定最重要的目标。

2、需求评定

最让技术人员头疼的可能就是和客户谈判。这个事情实际上不应该让技术人员来伤心，有项目经理就可以了。

而需求评定更多的是可行性的讨论。主程如果参加每个需求评定，他要三头六臂也搞不定，正确的做法应该是具体开发的团队人员参加，而主程在开会前给与自己的意见，或者会后听取参与者的总结。——这是了解别人做什么事的一个重要手段，但无需陷入太深，因为还有代码评审和项目经理的帮忙。

3、跨部门沟通

实在没必要参加，能躲就躲，这是扯皮的天堂。让项目经理去吧，他们的专业技巧能让这些事情更加有效。只要回来后让项目经理告诉你发生了什么事情就可以了。

4、进度审核和任务分派

又是一个很有“权势”的工作，实际上团队成员的情况大家都知道，决定谁应该做什么事情并非需要很多时间去想的事情。所以大可以把方向性的意见告诉项目经理，让他去做。很多优秀的开发者玩EXCELPROJECT之类的水平还不如只有一年工作经验的秘书，别折腾自己了。

5、面试

如果真想帮忙，准备一份有区分度的笔试题目吧。不靠谱的人太多，老板可不是花钱请你和他们聊天的。让项目经理去聊，不用担心他们技术不强，再不够，也会比大多数面试者要牛X。他们搞不定的人，就是应该雇佣的家伙。毕业生招聘怎么办？只要看看他们课外活动是不是有搞些专业的事情就可以了，上进心比别的东西都重要，HR会比主程看的更准，相信我。

6、各种会议

饭无好饭，会无好会，超过6个人的会议应该坚决抵制。如果你有一个程序等着你去写，你一定无比痛恨这些会议，顺应你的内心吧！上帝保佑你。

最后说说项目经理的工作：

项目经理就像下水道的清洁工，所有那些主程不愿意去做的事情，他们都弯下腰去认真的把玩，实在是太伟大了。

既然如此，为何不让他们拥有更好一点的头衔呢？如果没有他们去处理这些工作，任何一个主程都会被逼疯掉，或者他们自己变成了项目经理，让团队损失了最强力的一台代码发动机。

一、进度

1、指定工作计划

2、进度检查和告警

3、工作总结和统计

二、资源

1、整合提供各种资源，如找DBA，IT，运维人员，硬件，SVN权限，测试环境，福利，周末的活动……

2、面试：人员是最重要的资源，不是吗？

3、资源谈判：往往是和老板谈判，让别人明白现在的真实情况。又一个吃力不讨好的差事，但是总需要人做。

三、沟通

1、需求评审：和需求方讨价还价，项目经理真是命苦啊……

2、组织会议或者用其他方式通知信息给所有人：小喇叭、大喇叭、全服广播、世界频道……

对于一个小型公司，职权，头衔，收益，往往会更加敏感。但是这些都不是让项目失败的理由。

一颗叫程序员的种子说：长大了我就是叫管理者的树。这个错误的观念只会让这个种子永远无法发芽。

软件开发是类似外科医生的行业，而不是血汗工厂，所以不需要手持皮鞭的经理，而需要仁心仁术的神医。

许多成长中的创业公司，一旦规模扩大到50人左右时，就很容易走向倒闭。

其中，很重要的一个原因是，创业公司大多倡导唯快不破，公司的管理层将大部分的时间花在了打造产品、扩大市场以及满足用户上，很有可能并没有在意公司内部的结构问题。

但员工人数一旦增加后，最初创业的氛围就会发生改变，老员工和新引入的员工之间的融合和配合渐渐会出现问题，这种人际上的问题最终将会影响到公司动作的执行和落地。

很多创始人在这个阶段也会出现困惑——是继续坚持无为而治，还是开始集权管理？是从外部招募中层管理人员还是内部提拔员工加强管理？是继续扩大招聘以满足增长需求还是外包团队？

50人规模，是迈向100人、1000人甚至更大规模的垫脚石。因此，在这个阶段，尽早地解决公司出现的管理问题是至关重要的。今天分享的这篇文章，提供了在这个阶段的公司，可以参考的四种解决方案，希望给你带来一些启发。以下，Enjoy:

许多正在成长的创业公司，一旦规模扩大到50人左右时，就很可能走向倒闭。我把它称作创业的“青少年期”，我自己也经历过几次。其中，有我作为员工的经历，也有作为管理者的经历。

初创公司不断成长的初期到底有什么变化？

1至10人规模：到某个阶段时，元老级员工就不再愿意接纳新的员工。他们有什么事情不会立即说出来，并且他们内心中开始出现一种愤懑感，特别是需要重复为新来的“菜鸟”展示如何简单地完成某项任务时。他们对新人出错的容忍度极其地低，尽管那些错误也是他们曾经犯过的错误。

10至25人规模：第二批员工开始形成自己的小圈子。他们可能有时候会怀念“过去的好日子”，但他们越来越重视像职位头衔以及公司地位等方面的内容。在日常的交流中，带有“高级”二字的职位名称出现得越来越频繁。

26至39人规模：在这个阶段，就会出现“权力的游戏”这类现象。如果“青少年”会形成自己的“群体”，那么“而立之辈”则会对公司内部的“顽固守旧派”充满了愤懑和不满情绪。

40至49人规模：天哪！现在到底是什么状况？

虽然前述各阶段的变化情况并不是适用于所有的创业公司，但当创业公司达到50人规模时，总会有遇到类似经历的时候。我之前说过，我经历过上述各个阶段，并且对每个阶段可能发生的变化进行了归纳描述，因此，我不再做任何评价。

或者，我可能需要评价一两句。在创业公司快出现倒闭征兆之前，至少应该采取一些补救措施。我们需要把处于“青少年期”的创业公司“赶出家门”，让它自己去亲身经历和体会“成年人的世界”，并且像“成年人”一样地发展下去。

公司规模达到50人并开始出乱子时，也并不会落到满盘皆输的结局。

首先，这种状况必然代表着，公司还在成长中，可能还比计划成长的速度更快。只要成长还在可控范围内，这些问题都不是问题。

如果公司的确在成长，并且是朝着健康的方向发展的，那么公司内部可能已经形成了一种内在文化、规范以及办事方法。它们虽然没有形成书面的规章制度，但每个人心里却一清二楚。

在这种状态下，日常的交流可能更多的是面对面交流，或者是基于需求的交流。不存在太多正式的会议甚至会议纪要，当然，这也意味着可以节约大把应对这些繁文缛节的时间，并花在真正需要解决的问题上。

此外，从反方面来看，这种内部的状态也可以理解为，公司的管理层正在花时间打造产品、渗透市场以及满足用户，他们可能并没有在意公司内部的结构问题。

但是，既然开始出了乱子，那就应该重视起来。否则，大家都不想看到，“青少年”在“叛逆期”里“离家出走”的局面。

为人父母的都知道，针对青少年的叛逆期，根本没有所谓的治疗方法。能够做的，只不过是静静地等待他们成长。

有这么一句关于“出乱子”的话，我非常不喜欢。它是这样说的：“必须要经历震荡、成形、常态、规范这四个阶段。”这句话在这里也适用，但我之所以不喜欢，是因为它的用处不大。

虽然出了乱子，没有所谓的“治疗方案”。但我们总可以采取一些措施，并以此来应对难关。以下四种措施，是我比较熟悉的几种解决方案，我从中也得到不少灵感，希望对你有所启发：

1、无所作为

不要以为无所作为，就没有存在的意义。很多创业公司在开始出现人员流失时，才意识到应该无所作为。

所谓“无所作为”，并不是什么都不做。毕竟，在日常经营过程中，肯定会时不时地出现各种问题，而我们也无法回避这些问题。

无所作为，其真正的含义是，要积极主动地“无所作为”，并在问题出现时积极解决问题。

但我并不推荐这种做法。

试想一下，如果我们给某些员工的职场头衔前加上“高级”二字，并且这种做法完全是无章可循的，那么将有什么后果？

再以开会来举例。针对“什么时候开会？”以及“怎样开会？”这两个问题，需要相应的规定约束。否则，每个人的日程表上都排满了各种会议，会议室资源也出现严重稀缺的局面，到最后可能什么事都做不好。

甚至，连员工的“远程办公”申请都值得考虑。如果我们没有相应的管理方法，即便事情现在没错，到时候总会出错。我并不是在讨论滥用职权。我想说的是，假如某一个或多个同事都不在公司办公的话，其它人员的工作效率到底该如何保证？

通常情况下，创业公司会惧怕在公司内部形成陈腐思维、官僚主义，甚至出现大公司病。我非常理解这些问题，而且我也很讨厌它们。但到了某个发展阶段，该来的还是会来，所以最好还是积极主动地准备好一切，并迎接它的到来。

我会怎么做？——集权管理以及可视化管理。

至少，在日常的行为习惯及办事流程等方面，要出台一些简单的规定。确保每个员工都能获取这些信息。此外，你做出的决定，要让员工清晰地知道，这个决定背后的初衷是什么。

规定，不是冷冰冰的文字，而是公司的理念和企业文化的一部分。

2、聘用大量的中层管理人员

这种做法，和“无所作为”相比，是完全相反的做法。我把它比喻为用大铁锤去砸小坚果。

通常情况下，创业公司出现这种现象的话，那只能说为时过早。此外，聘用大量管理人员，特别是管理人员比办事人员还多的情况下，那工作效率必然提不上来。

如果从公司外部空降管理者，并且认可他们在大公司的管理经验，那他们可能需要适应创业公司的工作环境，并且熟悉创业公司的办事方法。等他们真正上手过后，可能几个月都已经过去了。

此外，外部的空降管理人员通常还会将大公司的那套管理方法带过来，然而在创业公司中却一点也不适用。

或者，如果我们从内部提升人员的话，我们可能会给这些员工的工作带来更多负担。毕竟，他们在进入公司时，管理并不是他们工作职责的一部分。

比如说，首席技术官会对最优秀的程序员说，“来，你从今天开始负责管理你这个团队的所有工作，你只需要从日常工作时间中抽一半时间出来进行管理就行了。”

结果，这名程序员不仅代码没写好，连整个团队的成员都开始对管理团队持有负面情绪。

我会怎么做？——设立多个事项负责人及团队负责人，而不是只安排一个管理职位。

当公司发展到50人规模时，其实就员工而言，并不需要太多的管理。相反，真正需要管理的是，内部的日常工作以及办事流程。其中，包括产品、前端开发、招聘、开票收款等一系列你能想到的事情。

让不同的人负责不同的事项。或者，让他们成为这些流程背后的负责人。

3、跟风抄袭，别人怎么做我就怎么做

我赞成部分抄袭别人的做法，并在此基础上根据自身实际情况进行调整。

我从Agile公司那里“抄袭”了部分敏捷方法的核心。我随时都在关注亚马逊的战略部署，并时不时地跟风部署。我非常喜欢Lyft做得非常到位的用户体验。

但是，你记得三年前，硅谷的很多公司为了解决收入差距悬殊问题，而将所有人的工资公开吗？这是真实的事件，但我并不认为，公开所有人的工资就能解决问题。

这个解决方案对他们可能有用（也许也没用），但如果说要用在我的公司，我觉得完全不可能。

我们要相信，肯定有各种各样的解决方案。

开放工作空间为了提倡团队协作，于是人人都带上了耳机。为了想尽一切办法招聘到优秀的人才，有些公司甚至给员工开出了无期限的休假待遇。

我想说的是，不要因为一个、多个甚至大多数公司都在采取某种措施，你就必须要跟风采取这种措施。

我会怎么做？——拆分挑选，小范围实验。

从其他公司学到的管理方法，我们会从中挑选适合自己公司实际情况的方法，并且在公司全面推广之前，进行小范围地实验。

4、停止招聘，选择外包

当公司规模达到一定数量时，我们可以考虑停止招聘，并将一切外包给第三方。

这种方法包括两种类型。

一种类型是内外分明。可以考虑开发团队、人力资源团队以及其它支撑团队全部外包，剩余部分仍然为公司内部的团队。

另一种类型则是内外兼顾。可以考虑纳入外部资源，与内部资源形成互补。比如可以聘用外部顾问为内部团队提供支撑，或者聘用第三方服务商为内部团队提供服务支撑等。

这种方法可以让你进一步优化资源。不用考虑内部编制的情况下，也可以在公司经营道路上游刃有余地成长和发展。

另一方面，通常情况下，50人规模也是迈向100人、1000人甚至更大规模的垫脚石。如果所有的核心技术及经验都来自于外包团队，这对创业公司来说，也是很大的潜在风险。

此外，针对这个方法而言，另一个值得关注的方面是，它说起来简单但做起来难。

在公司发展壮大过程中，我们在人员变动方面需要保持谨慎的态度。如果公司规模一旦达到49人时，那接下来该怎么办？如果又发现了下一个非常优秀的候选人，那又该怎么办？是否要主动辞退某人？还是等公司内部人员主动辞职？

我会怎么做？——租了再说，买不买再考虑。

很多的创业公司都经历过这样的情况，最初的承包商或者兼职人员最后变成了公司的全职员工，但前提是公司有资金了，平台足够大了，相关资源也足够丰富了。

我自己的创业公司中，有两个公司都经历过这种情况。

随着公司成长，可以更大胆地尝试这种方法。觉得有必要的话，还可以将某个外包团队聘为全职团队。在公司内部，把它们当作独立的团队来管理。

如果要解决创业公司50人规模时乱糟糟的局面，可能最根本的解决方案还是最后这一个。

如果一个创业公司的架构并不是传统意义上自上而下的多层级结构，而更像一个个独立的池塘，那又会怎么样？而且这些池塘还可能根据自身情况存在内部的小池塘。

那么，对公司领导而言，他们则“独占一池”，并且各个大池塘直接对他们负责。

每个池塘都将是独立存在和运营的。此外，如果有外包人员或团队的话，他们也可以被视作独立的池塘。他们来去自由，并且在必要的情况下，可以和其它池塘合并。

我不确认，这个方法可以百分百地适用。

它可能有点野，如果要将这种方法书面总结出来也比较难。但我相信，既然可以被当作一种方法，必然就有与之相适用的问题。

我想说的是，如果我们要解决50人规模时可能出现的乱子，那我们必须要以发展的眼光看问题，不能用成立公司第一天的管理方法来解决50人规模时出现的问题。

而在那之前，我们只需要花时间关注于创业公司的发展，精心呵护这个“青少年”，并陪伴它进入“成年期”。

身边有个朋友是做软件行业的，业务做得比较好，估计做这个行业的人都清楚，实在是没什么进项，但是又得开票，所以被企业所得税压得喘不过气来。

一、当前我国软件企业合理避税中存在的问题

1. 由于受制于部分软件企业自身管理水平，部分软件开发企业在投资时过于关注眼前利益，忽略了对企业长期发展利益的重视，在经营过程中，管理者不注重经营方式，不加筹划和研究，不重视对纳税的合理回避，这些都会在一定程度上导致软件企业纳税负担过重，影响企业的未来长期发展，约束盈利能力提升。
2. 软件企业税收筹划的成本比较高，尽管企业依靠合理避税可以实现有效的税收筹划，但是企业在税收筹划中需要设置必要的部门或机构来进行此项工作，在这个程序中依旧会加大运营成本，尤其是依靠税务机构进行筹划，企业往往需要花费比较高的咨询费用，在这种程度上来讲，合理避税效率比较低，难以实现降低纳税负担的作用。

二、软件行业税收优惠及税收筹划思路分析

1. 明确公司的税收性质，一般纳税人？小规模纳税人？

软件销售及技术服务技术服务类的征收税率3%（小规模纳税人）6%（一般纳税人）软件产品17%

2. 技术开发费的增值税如何减免?

这一块是相对容易免税的，只需要将技术开发合同拿到当地的科技局备案即可，但必须注意：其中的知识产权必须是对方所有或者双方共享，如果是你的知识产权是不能免税的。同样如果你免税了，那么你开出的增值税专用票对方也是无法抵扣的。

3. 软件产品增值税如何减免?

软件产品销售，征税税率3%（小规模）17%（一般纳税人），小规模3%这个是逃不掉的，但是你如果软件销售达到50万（1年内）会强制你变为一般纳税人，那时候17%的税率压力就会比较大，因此建议你这之前就做好软件产品认证。快的话1个月搞定，拿到这个证书后即便是一般纳税人也可以享受3%的增值率（超过3%的部分即征即退）。

4. 研发费用加计扣除是什么?

这是能帮企业省所得税，例如，一个公司一年的研发费用是100万，做了研发费用加计扣除后，研发费用就可以按照150万来计算。就等于说多了50万的成本，自然利润就少，所得税就了。

5. 最后来说企业所得税

除了上面说的研发费用加计扣除，其实我们都知道软件企业哪来多少成本，无非就是人员成本，那么如果这样，你年底的所得税就会很可怕了。净利润的25%，这种情况下，可以在有税收优惠的地区注册一家个人独资企业，不需要缴纳企业所得税，个人所得税进行核定征收，完美解决成本问题，比如江苏徐州市高新区税收优惠政策:只要将企业注册在江苏徐州市工业园区(注册式，不用实地办公)，两种方式：

• a、有限公司(一般纳税人)

增值税根据地方财政所得部分的50%-70%予以财政扶持奖励;企业所得税按照地方财政所得部分的50%-70%予以财政扶持奖励。

• b、个人独资企业或者合伙企业(一般纳税人)

这种方式是对于缺乏或无法取得进项的企业，可以注册成个人独资企业或合伙企业对所得税进行核定征收，所得税税率可降低至0.5%-3.5%，其增值税还有返还奖励，通过纳税筹划解决企业成本、个人所得税、分红等问题。

发布于 2018-05-28