兼职管理1、响应时间 微信响应时间 超过5分钟 2次 中止合作2、培养能力 经验、工具3、收益高于预期4、工程师和质量关于裁员裁员名单是根据个人在公司工作期间对代码的贡献来制定和排名的。高效工作总结：0、必胜信心1、结果导向2、完成时间3、物理专注公司管理思路：互相投资、互相信任，非传统主雇关系1、培养人，把能力传授给下面的人2、放权3、分享机制小团队项目组基本管理：1、放手，新问题主动处理、老问题交给下属处理，借此制定标准处理问题流程化；2、榜样，有困难主动承担、有问题主动冲锋；3、让功让利，向上让功、向下让利；温和派领导人管理思路：1、立功，对公司有贡献；2、握权，能够影响员工收入组成40%、考核评分、项目奖金；3、守信，不轻易承诺、一旦承诺必须兑现；4、立标杆，培养典型员工进步并树立标杆；团队凝聚力1、身先士卒，带动员工积极性；2、知人善任，用人长处；3、勇于背锅；4、尊重、感谢，公约机制；提高员工工作效率1、责任到人；2、限定时间；3、确定标准；4、重复一次；5、检查机制；6、验收考核；老版轻松X成就感V想明白，布置下去1、会算账，不算公司赚多少钱、算员工能赚多少钱；2、会画饼，公司壮大时候做到位置、发展前景；3、会激发，你是专家我不行、顶梁柱；
据预测，未来 10 年中，企业或组织的数字化转型会达到高峰，将比过去几十年的总和还要多。而这一进程，开发工程师必须找到更加有效的开发方式，才能实现。在这一层面来说，DevOps 是数字业务转型计划的核心。目前，企业越来越重视DevOps，并开始向这种开发方式转型。但是，如此多声称专注于 DevOps 的企业或组织，真的都做对了吗？在大多数的 DevOps 实践中，仅仅涉及到了特定工具的使用，企业非常松散地遵循着某些 DevOps 原则。然而，要想真正成为一个以 DevOps 为中心的组织，这些远远不够。参照以下 7 点，或许能够帮助你及时纠偏：一、部署是完全自动化的每一个项目工程通常都包含了很多的代码文件、配置文件、第三方文件、图片、样式文件等不同部分，要想将这些部分有效组装、最终形成最后的应用结果，往往需要借助构建工具或策略。构建过程如果仅仅依赖人工，就会十分繁琐。于是，自动化构建、自动化发布、自动化部署的想法和探索就浮现了。自动化的出现，将大大提升工作效率。在 DevOps 实践中，是需要从头到尾完全自动化部署的。自动部署的意义不仅仅在于节省时间，更多是避免问题的出现，手动部署更常出现因为人为错误引起的问题，而自动部署可以在问题出现时迅速恢复到以前的版本。二、有频繁且快速的发布周期天下武功唯快不破。想要获得更强大的竞争力，只有不断部署和快速修复。DevOps 中一个核心功能就是 CI/CD（持续集成/持续交付），寻找更有效的自动化和部署更新迭代的方法，让开发人员提高生产效率、并快速地发布到生产环境中。CI/CD 通过在构建、测试和部署应用程序时强制自动化完成。这种 DevOps 方法的精髓在于：1）通过频繁的代码库提交、自动化构建等来提高生产力；2）通过集成自动化测试以及开发期间的测试，增加在开发早期发现错误的机会；3）得益于频繁的测试和自动化部署系统，可以更快地发布版本。三、注重可观察性国外的一份报告显示，可观察性正在成为 DevOps 实践中绝对不能缺少的一环。在跨越多个流程的数字业务转型中，可观察性有非常重要的意义。New Relic 对 1300 名 IT 领导者、软件工程师和开发人员进行的一项全球调查发现，90% 的受访者认为可观察性对业务至关重要。只有更多地基于事实而非直觉，才能作出明智的决策，越来越多的团队开始从整个企业应用程序环境中收集数据，来提高整个开发过程的可观察性，可观察性也在生产前和生产后的环境中扮演越来越重要的角色。四、有持续的反馈循环初期，DevOpsDays 活动的发起人和 DevOps 这个词的创始人 Patrick Debois 发现，有关 DevOps 的话题相互交织在一起形成了四个不同的反馈环，如上图所示。其中，蓝色气泡代表技术，黄色气泡代表过程管理。一起形成了 4 个循环。开发-测试反馈环（黑色箭头反馈环）；开发-运维反馈环（绿色箭头反馈环）；业务-运维反馈环（红色箭头反馈环）；业务-用户反馈环（紫色箭头反馈环）。在现在的 DevOps 理念中，出现错误并不可怕，可怕的是没有一个持续的反馈循环系统来检测何时何地出现问题。反馈循环需要在发生错误时快速通知，从而使问题得到更快地解决。很多时候，我们遇到问题仅仅是简单地解决了它，并没有花时间分析问题发生的原因以及如何防止问题再次出现。这样的循环是不完整的。从某种程度上，如果你设置了一个系统来识别问题、修复问题和改进问题，还需要认真分析，才意味着你在正确地实践 DevOps。具体来说，一个监控系统需要观察并记录系统状态变化和数据的流程：1）状态的变化：可以通过状态的直接度量或者更新日志来表示；2）数据：可以通过记录内部组件和外部系统之间的请求和响应来记录。五、开发和运营团队一起工作Dev（开发） 和 Ops（运维） 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。这个矛盾最先由 John Allspaw 和 Paul Hammond 在“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”提出，并以“Cooperation”作为整个演讲的核心，讲述了他们解决这个矛盾的实践经验。在一个组织中，如果相关利益者的利益不一致，在既定流程的进行中一定会碰到诸多阻力。而在这一点上，首先做的就是把 Dev 和 Ops 的利益一致化，从而减少 Ops 对软件交付的阻力。在传统观念中，开发的工作是增添新的功能，而运维的工作则是保证站点的稳定和高性能。 而在 DevOps 的观念中，Ops 的工作目标应该是激活业务（enable the business ），与 Dev 是一致的。至此，DevOps 众所周知的主要好处就是打破开发和运营之间的孤岛。在维基百科上，DevOps 的解释也着重于一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。因此，开发、测试和 IT 运维团队之间的沟通对于 DevOps 的成功至关重要。六、目标明确虽然不同团队之间的沟通至关重要，但明确定义每个人都在努力实现的目标同样重要。归根结底，所有团队都有同一个目标：让组织更有效率。但是，他们为实现这一目标而遵循的个人实践可能会有所不同。团队成员应了解实现目标所需满足的精确要求，而不是做出假设或任其发展。七、使用正确的工具和平台DevOps 不仅仅是一种文化转变——它需要强大的工具才能实现。在实践过程中，如果你发现往往需要花费大量时间来解决出现的问题，那么很可能是因为你没有选择正确的 DevOps 工具。幸运的是，目前的市场上有大量且广泛的 DevOps 工具可以选择，以适应当前现有的所有的数字化基础设施。尽管工具是 DevOps 的重要组成部分，但是要记住，真正使改变发生的是实践。在众多 DevOps 工具中，近两年来被业内广泛关注的飞算SoFlu因其对软件开发流程的变革而被大量企业应用于DevOps落地，飞算SoFlu是一款管理加开发工具，通过可视化编程的方式满足开发需求。使用平台的一个ID相当于一个10人科技团队，从而使用户有更多精力可以更多关注自身业务。飞算SoFlu中包含的三大核心技术，全都是 DevOps 实践中所要关注的重点：1）可视化开发改变传统开发方法，业务逻辑可视化展示，降低开发门槛，无需编写代码，在设计业务逻辑时就形成微服务应用。2）平台组件可视化平台组件是一类通用的技术功能模块，平台支持循环条件判断，函数调用，通过拖拽方式以及参数配置实现等同于编写复杂代码的业务逻辑，有别于通过组件排列组合。3）管理方式主要通过管理平台来管理需求、研发、测试、部署、上线、运维等整个软件生命周期，经验沉淀、知识积累，将管理制度真正的落地。截至目前，飞算SoFlu已为包括医疗、金融、制造、零售等在内的八大行业的上百家机构提供了技术服务，助力其落地DevOps，提升研发效率。一个典型的案例是，飞算SoFlu在某大型国有银行的应用。该银行原本需要3天才能开发完成的接口，使用飞算SoFlu，仅用了5个小时。其IT负责人表示，使用飞算SoFlu后，银行软件中心的整体研发效率获得了大幅提升。飞算SoFlu的DevOps功能正是在不断的实践中完善升级，从实际业务出发，真正让企业实现降本增效。
作者和授权信息本文由 Easy 撰写。Weibo: https://weibo.com/easyTwitter: https://twitter.com/easychenYoutube: https://www.youtube.com/c/Easychen(欢迎大家关注和订阅，等 Youtube 订阅过 1000 ，我会试试制作本方法论的视频版)本文在 cc-by-nc-sa 协议发布。您可以复制、发行、展览、表演、放映、广播或通过信息网络传播本作品，但必须署名作者并添加链接到本文。不得为商业目的而使用本作品。仅在遵守与本作品相同的许可条款下，您才能散布由本作品产生的派生作品为什么有这篇文章不管是独立开发还是IT课程，一个人做业务也好几年了，最近开始回过头整理通过实践获得的认知，并尝试将其梳理为一个方法论。当然这个体系还不完善，但一直没有找到同一个方向又更为完善的。所以不如自己来整理和维护，对自己而言可以定期回顾修正，读过的大家也可以来参与补充。什么是一人公司这个方法论，我把它叫做「一人公司方法论」。那首先什么是「一人公司」呢？字面的理解就是一个人运营的公司，但实际上它指代的是比较少的人运营的小公司，一般来说1~3个人运营的公司，也可以把它放到一人公司的范围以内。其他一些形式，比如说一个人再加上很多的兼职一块运营的公司，其实也可以看成一人公司。所以从人数上来定义一个公司，实际上并不是很准确。我更喜欢另外一个层面的定义：「 一人公司就是建立在个人品牌之上的公司。」这个定义更为准确，它是说整个公司的业务和品牌影响力都主要源于基于一个人。它周围可能有一些辅助运营的团队，有一些外包、有一些兼职，甚至全职助理的角色，那也是一人公司。为什么要单独来观察这一类公司呢？因为我觉得它是以个体创造财富的典型。之前我翻译过一篇趋势报告，叫做「百万美金的一人公司」。说的就是越来越多的一人公司，可以做到百万美金的价值。当然，直接盈利达到百万美金的不多，但是以 100 万美金估值卖掉的却不少，而且正变得越来越多。一人公司的特点优点下面我们来看看一人公司的特点。先看优点。第一个显而易见的优点就是成本低。因为整个公司只有一个人，所以无需办公场所等硬性成本；也没有长期雇员，所以它没有固定人工成本。这里需要注意，固定人工成本，实际上是一个会引入风险的成本。很多程序员创业副业喜欢做外包，但是如果你做一家外包公司，就会纠结于固定人工成本。比如在你规模小的时候，接到几个大单子，就需要扩展人员来完成开发。但是如果做完这些项目以后，接不到同样数量的活，你还却依然需要支付同样的薪资来维持团队。这就成为了一个很高的风险。你又不能把员工开掉，下次需要时再招。先不说这样干下次还能不能招到人，每次团队磨合和培养的成本就非常高。回到低成本上来，因为你只有一个人，你不需要协同，所以没有沟通成本，很多事情可以保质保量的快速完成。再一个，因为你没有团队，个人的话，想在哪个城市就可以在哪个城市。现在一些新一线和二线城市的生活成本非常低，生活环境也非常舒适，如果可以把业务放在一线城市，然后生活在其他城市的话，不但生活成本低，而且生活品质反而会得到提高，这也是一个非常划算的地方。因为成本低，相应的对收入的压力就小。一个每月只能挣 10 万的业务，对大公司来讲可能成本都收不回来，但对于一人公司来讲，去掉成本和税都是自己的，很可能可以活得挺滋润。也正是因为存在这些结构性的市场空白，才让一人公司可以存在并得到发展。缺点一个人的精力是有限的说完优点，下面我们来说一下缺点。首先就是一个人的时间和精力是非常有限的。因为如果我们一天工作10个小时，一周工作5天，那一周其实就50个小时的工作时间。如果把这50个小时的工作时间均摊到各种要做的事情上边，就会发现其实每一件事都分不了太多时间，这会造成整体业务进展慢。同时，因为就一个人，所以必须在多种业务之间来回切换，这会带来一些额外成本。比如说我们正在编程、正在做架构设计的时候，是在进行深度思考，如果这时候有一些紧急但不重要的事情插入进来，就会把我们从深度思考中拉出来，之后需要再花很多时间才能重新进入到这个状态里边去，甚至可能再也回不到当时的状态，从而丢失掉一些很好的想法。尤其是对一些创造性高的工作来讲，这是非常可惜的。一个人需要做全部事第二个缺点就是，一人公司往往要求我们一个人把整个链条上的所有事情都做了。原因很简单，因为整个公司就你一个人，你不做就没有人做。这样带来的一个非常明显的问题，就是工作量的大额增加。即使很多没有难度的事情，处理细节也会消耗大量的时间。另外还有一个更严重的问题，「麻雀虽小、五脏俱全」。它不但要求工作量，还对技能有要求。如果你缺乏特定的技能，就需要投入上百个小时的学习时间，而且还不一定能学得好。更有一些大型公司具有的资源，一人公司可能是不具备的，比如像做运营和销售时候的人脉资源。如果持续解决不了，就只能调整策略去绕开。矛盾和解决这里就出现了一个非常明显的矛盾：一方面是我们个人的时间精力非常有限（一周就50~60个小时）；另外一方面，我们又有非常大量的事情要做，因为公司就我们一个人，所有的事情都是要有人来做的。这个矛盾不解决，一人公司就运转不好。怎么解决呢？还是从矛盾的双方分别入手。提升效率第一个方向，一个人的时间和精力是有限的，那我们能不能提升效率。这个对于其他的行业来讲，可能会比较难，但是对于程序员来讲，可以考虑自动化和人工智能。如果在这两个方向上有突破的话，我们就可以把个人的时间和精力从重复劳动里面解放出来，让机器高效率的去处理重复的事情，把我们仅有的精力放到创造性的、开创性的业务上面来。对于通用业务而言，这个难度可能很大，但如果针对某些特定的业务，还是有可能构造出一人+机器人的效率放大结构的。这个结构一旦完成，就可以极大的提升效率。选择要做的市场另一个方面，我们还可以从选择要做的市场入手。虽然每个公司都有各种业务，但对于不同的市场，每一种业务的工作量是完全不同的。如果我们对进入的市场进行取舍，就可以把精力集中到那些工作量小的细分市场或者小众市场。比如我们只针对一个小众人群去做一个功能简单的软件，产品和开发的工作量就会小很多。但小众市场往往伴随获客问题。通用渠道首先是通用渠道的相对获客成本变高。比如同样是花一百万买开屏广告，面向大众的快消类产品，100 万人看，其中有 80 万都是潜在目标用户，最后点击可能是 20 万。但小众产品如果以同样价格去投放，100 万人中很可能只有 10 万人是目标用户，这样点击和转化就非常低了。相对而已，小众人群的获客成本反而高很多。定向投放除了通用渠道，我们还可以考虑做定向投放。所谓定向投放是说，对这个小众市场的行业网站和社区投放广告，或者向这个小众市场相关的意见领袖（KOL）做营销推广，再或者购买搜索关键字来导流。这部分的效果会好一些，但成本就要看这个行业竞争如何了，竞争激烈的比通用渠道投放还要贵。自制内容以上两种方式都是需要相当的市场预算的，对于一个刚刚启动还没有盈利的产品，更多的是没有什么预算的情况。这时候我们更多的会考虑自己来做内容、自媒体、成为 KOL。但做内容是需要持续不断投入的事情，在精力上的投入比较大。如果我们是一个人的公司，那一周50个小时的时间，花在视频录制剪辑加字幕发布上的时间，很可能高达20个小时。40%的时间花在做视频上，而这个视频它还不是立竿见影的，需要很长的时间去积累用户。这也是为什么你会看到很多的程序员，不是靠写软件挣钱，而是靠公众号卖广告挣钱。因为做内容就很费时间了，如果还要去开发一个软件，精力上很难支持住。自传播除了做内容，我们还可以在产品设计上发力。如果我们能让产品做到自传播 —— 就是让用户能不断地邀请来新用户，我们就不用花自己的精力在上边了。有网络效应类的产品比较适合做自传播相关功能，因为用户的收益和用户数量成正比的。有的产品不一定适合传播，比如定位是一个非常私密的个人数据类产品，就不一定适合通过分享内容来拉新。当然除了直接整合在产品中，我们也可以通过积分、物质回报来激励。比如现在已经很常用的分销返利或者邀请用户送付费会员等。小结对比以上方案，自传播应该是最好的渠道。需要付出的成本低，效果相对的也好。但它的问题在于如何优化产品，实现持续不断的自传播。这个是非常考验产品能力的。选择成为平台或生态的一部分除了选择市场以外，我们也可以选择成为平台或者生态的一部分。因为有平台在，我们就可以少做很多事情，甚至只需要关心业务逻辑。对于早年的苹果市场来讲，只要会开发应用可能就OK了。苹果商店会帮你进行销售，其他的事情都不用管。但这其实是理想状态，随着市场慢慢的从蓝海变成一个红海，我们会发现即使应用写完了，在市场里已经有很多同样的应用。我们又只能想办法去做营销相关的优化，在其他渠道去做一些推广。最后之前要做的事情，又回来了。因为对于每一个产品来讲，平台能提供的入口大家都能拿到，只能在这个基础上再竞争。用现在的词就是「内卷」，市场「卷」起来以后，我们就必须去做更多的事情。当然我们也可以不做海，选择去做一个小池塘 —— 就是说这个市场非常小，不太可能变成红海，因为没有那么多的人看得上它。但相应的，这种市场一是很难发现，二是往往随着趋势的发展，它可能会消失掉。可能短期内还能挣点钱，但最后这个市场可能就没了，你又不得不从头来重新寻找新市场，这也是非常痛苦的。苹果商店已经很成熟，所以比较卷。我们也可以去找一些新的平台和生态。比如 toB 的 SaaS 的话，国内可以看看企业微信和钉钉，国外的话可以看看 Airtable 这种新兴生态。如果进入的时间点合适，就能分到很多流量。当然，还是想之前说的，一旦市场竞争变激烈后，红利就会消失，剩下的就是大家真刀真枪的竞争，要做的事情又会变多，如此往复。分离非核心业务确定了市场以后，我们还可以对自己的业务进行取舍。比如，我们把非核心业务给分离出来。这些业务，我们可以外包、可以兼职。对于一些基础设施，我们可以「以租代建」。所谓「以租代建」，就是说以前我们需要什么系统都要自己开发，但是现在有各种各样的云平台、行业SaaS、以及不少按量付费的商业服务。比如商品代发，就已经有平台可以帮你来做。只要付一点钱，就可以让他们帮发货，自己就不用再搞个仓库或者店面来做中转。基础设施和制造业也正在逐渐的成熟和开放，比如3d打印、周边印制。最后它们都会抽象成一些API接口，我们在网上去调用它，付费，剩下的事情就自动完成了。这样的话，很多非核心的业务都可以被分离出来。当然这个是一个过程。不同国家和地区的市场、不同的行业成熟度都不同，需要自己去考察。强调「以租代建」对于程序员有特殊意义，因为对我们来讲写程序是很容易的事情，自己建一套系统也很方便的，而租用别人的还要花钱。以租代建的核心是节省时间和精力，如果我们只是通过不断开发各种系统来省钱，那这样跟我们去接外包挣钱不会有太大的区别。（这也是我自己经常犯的错误，需要时刻提醒自己）这里还有一个概念要明确，前面我们有提到说要分离非核心业务，那什么样的业务是核心业务呢。这里有一个简单的判断标准。在我们做的这个业务中，最稀缺的资源应该成为我们的核心业务。比如对网课平台来讲，能持续不断生产优势课程的讲师就是稀缺资源，如何聚集和维护这个群体就是核心业务。只要保证这点，其他资源都会慢慢聚集过来。而其他的部分，比如课程平台的开发，就是非核心业务，可以通过租用或者购买的方式来解决。增强优势除了降低工作量，我们更需要想办法来增强优势。因为降低工作量只是保证我们能把产品完成，但如果产品和其他竞品一样的话，并不会具有优势。从用户的角度来讲，大部分的用户并不关心产品背后的开发者是个人还是大企业，更看重付出的成本和得到的收益。所以我们最终还是要回到产品价值上来，为用户提供不可或缺的价值。从标准品到独立品类我们可以给一些标准化的产品去添加独有的特色功能，从而把它变成一个独立的品类。比如我之前做过一个软件叫做福利单词，它是一个背单词的软件。在任何一个市场上，这类软件都是一大堆。但福利单词有一个额外的功能，就是在输入单词正确时，会给你显示一张高清的萌妹子福利图。这就带来了完全不同的体验，在它和那些千篇一律的背单词软件中划出了界限，成为了一个同时融合叫教育和娱乐功能的独立品类。如果你觉得这点小功能还不足使其以成为一个独立品类的话，可能我之前做的学前端 RPG 游戏 更明显一些。副产品优势另外一点就是，我之前在「从精益开发到精益副业」的视频 中提到的「副产品优势」。虽然是在运营一人公司，但不一定非要全职来做这件事情。也可以一边上班，一边把一人公司作为副业来做。在这种情况下，我们就会多出来一个优势，我叫它「副产品优势」。核心是说，因为有主业，所以可以保证基本收入和生活品质；在主业工作里边产生的副产品，可以进一步加工为商品，作为副业来销售。这样既没有生活压力，又降低了副业的制作成本。虽然刚开始可能收益的绝对值不大，但可以慢慢把它做大，直到有了充足的现金流，再把它当成主业来做。营销优先还是开发优先除了上边提到的这些，在实际运营中，我们还经常会遇到很多其他需要选择的地方。比如，在优先度上，到底是应该营销优先还是开发优先。对于大一点的公司，有足够的人力，营销和开发都是不同的部门去做，所以可能不存在这个问题。但是对于一人公司来讲，其实很难一边做营销，一边不停的去给产品开发新功能。因为营销和运营不是一个短时间的事情，需要持续不断的进行。如果你不去做，很可能流量就没有了，没有流量就没有转化、也就没有收益。另一方面，如果我们不断的开发新功能，时间长了就会有一堆项目需要维护，维护成本累加起来会很大。假设有 50 个项目，平均每个项目一年升级维护一次，每次两天，那么就会花掉我们工作时间的 40%。如果这些项目是免费的还好，可以随时关闭。但如果每个项目都有那么几十个付费用户，既不挣钱就要不断的提供维护和客服，是非常麻烦的。这之间的取舍，会对我们的一人公司的运营产生很大的影响。营销优先营销优先模式是说，我们只开发一个很简单的产品，维持一个很小的功能集。然后不断的去为这个产品寻找新用户。这个模式的优点是，我们开发的功能很少，维护成本比较低，不用不停地开发。而它的缺点就在于，我们需要持续不断的进行营销，不断的获取新的用户。最后可能会发现，越来越多的精力都用到了营销上，用到了拉新上。最后完全变成了做内容或者做业务的竞争。即使这样，如果能做好营销，那其实也不错。但大部分程序员并不喜欢和擅长做营销，而且在没有市场预算的情况下，要成为影响力不错的营销号是需要花很多的时间和精力，甚至还有运气的。关于营销的难度，很多同学没有基本的概念。我这里有一个自己常用的参考转化率，是在以微博为主要流量入口的环境下测试得到的。从信息流展示次数到有效付费购买之间，转化率略为 1~5‰ 。当然，具体的数据会因为营销材料、产品需求有很大的不同（这其实是优化得不错的数据了），当你自己测试过后，可以得到自己的转化率数据。如果你没有自己的数据，那么不妨以 1‰ 为基础简单评估营销难度。也就是说，如果想要获得 100 个购买，大概需要十万次的有效阅读，那么首先以 10 万的触达为基础思考如何达到。开发优先另一种模式叫做开发优先。是说我的营销能力可能不够，那我就面向同一群用户，不做营销了；改为针对已有的这些用户，不断的为他们开发付费产品。这其实就是凯文·凯利那篇《1000个铁杆粉丝》的文章中的逻辑。文章中说，如果你有1000个铁杆粉丝，无论你卖什么东西他们都会买的那种，那你只需要面向他们不断推出产品，就可以维持不错的生活。这种模式的优点是，我们不用到处去做营销，不用过多的去做我们（可能）不擅长的领域。而缺点就是，开发很累，维护也很累。如果不能形成规模效应，就要不断的开发付费应用，每一个产品可能就会做得很浅。你可能要问，为啥我要不断的开发应用，我只开发一个应用，然后不断的收钱不行么？答案当然是可以，但难度有点高。为什么要这么说呢，我们来计算下。假设我们期望每个月的毛收入在 5 万（除去成本和税以后大概在 3 万），如果以 1000 个铁杆粉丝来算，那每一个用户，就需要每个月消费50块钱。这其实是一个很高的费用。从开发者的角度来讲，你可能觉得这个费用不高，但从用户的角度来讲，是很高的。如果你收集下自己和周围的人在软件和互联网服务上的实际开销，就会明白。我之前在微博上发过一个提问，从评论来看，即使一年花销达到200左右的产品和服务都不太多，而且基本是资源导向的，比如视频音乐会员、电商外卖会员。很少有工具类软件能达到这个数的。所以，to C 的工具软件和 SaaS 里边，要找到每年能持续挣600块钱的需求，难度相当高。to B 的服务在价格上相对容易上去，但是在获客成本和开发工作量上又相对较高。如果能在其中找到一个好的需求，倒是很不错。总之，如果我们找不到这样的需求，就只能退而求其次，用多个付费服务来提升客单价。实际操作前面说了这么多的分析，但离落地还有一点点距离。在最后一部分里，我们就来思考下怎么落地。发现一个趋势寻找一个小市场针对这个市场面向 1000 个用户，提供一个每月 50 元定价的产品或者面向 10000 个用户，提供一个每月 5 元的产品开发产品并持续运营发现趋势首先，我们应该集中精力在发现趋势上。以前创业的时候，我经常思考一个问题。凭什么一个创业公司可以以很小的团队，在很短的时间，用很少的资源崛起。以前的人都没这些人聪明吗？显然不是。后来在阅读一些创业方法论的时候才明白，这是因为创业公司发现了趋势，找到了变化。因为这些变化是新出来的，所以以前的商业虽然有能力，有资源，但难以未卜先知。新的趋势就像山脉的崛起，将原来严丝合缝的商业逻辑撑开，出现了新的商业路径。发现趋势，就是要看到变化。个人的努力虽然重要，但也要考虑时代的进程。尤其对于一人公司来讲，跟上大趋势，才能放大自己有限的精力投入。关于趋势发现，简单粗暴的方式是读研究报告。比如艾瑞网会定期更新一些简版报告，从里边的数据可以发现很多有意思的趋势。不过这些报告更多的是面向创业投资领域，未必适合一人公司。像我经常在微博上提到的 Trends.vc 这种专门为独立开发者和一人公司准备的分析报告，就更有针对性一些。寻找一个小市场正在高速增长的赛道里往往有大量的巨头和创业公司，从资源上来讲，一人公司在这些领域很难占据优势。但在这些赛道周边，通常都存在一些年收入最高几千万人民币的小市场，这些市场大厂和资本是看不上的，反而是一人公司很好的切入点。如果能结合趋势，选择到一个现在看起来很小，但是会随着趋势慢慢变大的市场，就能进一步保证将来的收益。早期进入，持续深耕，当这个市场成长起来时，即使是一人公司，也会具备很强的竞争力。设计产品然后就是针对这个市场设计产品了。根据自己的能力，可以有两个选择：面向 1000 个用户，提供一个每月 50 元定价的产品或者面向 10000 个用户，提供一个每月 5 元的产品当然，其实你还可以进一步调节用户数和月定价，只要乘起来是 5 万就可以。而且 5 万也只是一个参考值，做不到还可以调低。如果一个产品做不到，可以把一个改成两个。这里量化数据的意义在于，给出一个清晰的模式，用来做前期的参考。参考依据在设计的过程中，我们可以准备很多备选方向和产品，通过比较选出最适合自己的。以下是我觉得有用的参考依据：市场安全性：发展趋势（是否快要没了）、竞争情况（是否红海）客户价值：MRR（每月经常收入预期）、LTV（客户生命期价值）获客渠道和成本：是否能够自传播，传播系数工作量：MVP（最简可行产品）所需工时、迭代和升级维护成本资源匹配度：是否有自己难以掌控的资源开发和持续运营接下来就是 MVP（最简可行产品） 的开发，PMF（产品市场契合） 的寻找以及后续的持续运营（或者转型）了。这一部分的内容可以参考精益创业系列方法论。一人公司的基础设施无公司运营虽然写的是「一人公司」，但其实我们并不需要一开始就注册一家公司。因为会带来办公地址和记账的固定成本。一般来讲，最理想的方式是以个人身份运营业务，在有了稳定的现金流以后，再注册公司。在国内，很多平台对个人主体并不友好，需要自行寻找替代方案。以 Web 业务为例，我们需要和平台对接的部分通常包括：第三方用户登入（比如微信登入）支付（没有这个就没法收钱）消息触达（群发通知）其中，① 和 ③ 算是加分项，② 则是付费业务不可绕过的。个人支付解决方案就我了解，在目前个人主题可用的支付方案中，唯一安全而且稳定的是「小微商户」及类似方案。这种方案其实是支付平台（比如微信、支付宝）在提供底层能力，只是通常为了防止被滥用，不开放直接申请，而改用服务商代理的形式。正因如此，它可以做到资金完全走支付平台（而不是你的支付服务商），保证了资金的安全而且没有二次清算问题。国内提供基于小微商户支付方案的有好几家，通过搜索可以发现有 xorpay 、payjs 等服务商。但不少服务商不太厚道的自己搞了一个审核流程来收取审核费或者叫开通费。我自己使用的是面包多推出的支付平台：面包多Pay。官网注明的特点如下：没有开通费，交易时才付费，非常适合启动期的项目，费率为每笔交易 0.1 + 2%支付完成以后可以显示文字、图片或者跳转到网址，一些简单场景就不用写代码来接入了不过对我而言，最主要的考量还是平台稳定性，现在面包多每月结算数百万，这个支付平台其实就是其业务核心「闪电结算」平台的扩展，属于主业副产品，因此不挣钱应该也会维护下去。一个 Tips：面包多Pay（其他平台我并未交费试用，因此不做评价）的支付接口里边，有一个获取 openid 的接口。它其实可以用来做微信体系下的用户登入。换句话说，无需认证公众号就可以实现微信用户的登入和支付。这就非常适合个人。消息触达常规操作是，在登入时要求用户补全邮箱、手机号并将其作为消息触达主通道。但邮箱时效性差、短信被拦截可能性高，且费钱。因此微信成为了发送通知实时性和到达率最高的通道。但是未认证公众号只能被动回复消息，均不能主动发送消息。即使认证公众号，模板消息权限正在收回。经过比较，我认为目前适合个人的消息触达方式是微信机器人/QQ机器人。通过关注机器人，发送 token 实现账号关联，之后就可以通过机器人推送消息给用户了。我知道的方案如下：微信机器人方案： wechaty (网页版协议免费，其他协议收费)QQ机器人方案：mirai （未亲测）机器人方案除了可以用作消息推送，还可以用作登入。比起通过支付接口的 openid api 登入而言，没有因 openid 改变导致用户无法登入的风险。公司注册如果你不能找到满意的个人主体解决方案，那么就只能考虑注册公司了。需要留意的是，即使注册公司资质，其实也有个体工商户和公司两个选项。个体工商户的申请流程虽然简单，但其背后是无限责任。而有限责任公司则以注册资金作为上限，更容易规避风险。公司注册不是本文的内容范围，在此就不做展开了。
交付物软件100%实现需求明细列表所有功能，即100%满足业务需求的软件。文档项目验收验收方式1、将要交付的软件安装于指定服务器，并完成调试和上线；2、完成培训后，业务验收人员根据需求明细列表实现情况进行验收评价，研发验收人员根据以下内容进行验收评价。文档验收1、文档齐全（参考如上文档清单）；2、文档内容描述准确, 没有歧义和错误的表达；3、文档内容容易理解, 通过使用适当的术语、图形表示、详细的解释来表达；4、文档对主要功能和关键操作尽量提供应用实例。界面验收1、界面设计符合自己公司的设计规范；2、外包团队需提供与软件适配的浏览器、手机、PAD等品牌与版本号清单；3、各界面需要做好PC、手机、PAD等UI兼容与机器适配；4、原则上，浏览器至少需适配Chrome、Safari、火狐、IE8以上；5、原则上，手机至少需适配苹果、小米、华为、vivo、OPPO、三星、魅族。功能验收1、功能验收范围覆盖（接口、数据库存取、页面功能）；2、提供单元测试用例、集成测试用例和系统测试用例；3、提供BUG管理跟踪记录表；4、提供质量分析报告。性能验收1、提供性能测试报告；2、相关重要指标达到以下要求：安全验收1、软件中的敏感数据需以密文方式存储；2、软件需有留痕功能，即保存用户的操作日志、系统异常日志、接口调用数据日志等；3、软件中各种用户的权限分配合理；4、扫描出的安全漏洞（包含但不限于：越权访问、XSS跨站攻击、SQL注入、文件上传漏洞、跨站请求伪造等）外包团队需修复完毕。用户验收1、外包团队需提供稳定的用户验收环境和联调环境；2、业务场景功能测试不通过数的比例<1.5%；3、不存在严重等级为1的错误；4、不存在严重等级为2的错误；5、严重等级为3的错误数量≤5；6、所有提交的问题都已得到修复；7、以上功能，用户验收测试通过后，由用户负责人签署验收通过确认书。源码交接如涉及到源码交接，按下列规范进行验收和交接。交接前提条件1、需提供用户验收通过确认书；2、涉及交接的软件，原则上建议接受交接软件所有功能，不建议交接软件部分功能模块；3、跟薪资类无关的软件或功能，所有功能需在线上稳定运行不少于3个月；跟薪资类相关的软件或功能，所有功能需在线上稳定运行不少于6个月；4、线上稳定运行既线上可用率，需满足：最近3至6个月内，线上没有出现影响20人以上或数据错误的严重bug，且每月线上bug数不超过3个。源码验收1、代码应只保留跟本项目相关的代码，无效代码应一律去除；2、数据库应只保留跟本项目相关的表、视图、存储过程、函数、触发器、定时job等，无效内容应一律去除；3、特别注意合理做好数据表结构设计，适当冗余提升性能；4、代码结构清晰无冗余，注释完整有效，避免硬编码；5、但凡不符合源码验收规范的，外包团队需修复完毕。其他注意点1、对于外包团队的软硬件选型，建议业务部门邀请本公司IT团队一起参与决策；2、与外包团队商签署的商务合同和补充协议等，建议业务部门邀请本公司IT团队一起参与制定；3、外包团队使用的环境、数据库、网络、语言、框架、技术、组件等需事先获得本公司IT团队认可；4、如外包项目不符合或无法满足上述验收规范的，建议商务层面延长付款周期、扣除相应款项或终止合同；5、每一笔合同款在支付给外包团队之前，除了需获得用户验收通过确认书之外，还应通过IT团队验收；6、以上内容建议附加进商务合同，成为其中一部分。
软件外包存在风险，外包人员技术、态度、交付能力，如果想通过合同或者诉讼降低风险，由于太多的未知因素和太多的主观性，不现实。因此唯一的外包原则应该是：如果外包人员做得不好，有能力随时终止合作且可控费用损失和项目交付。可以尝试渐进式方法，首先废除传统开发外包大瀑布方式（例如签订需求URS、项目总金额、进度款支付）（不过目前大部分外包会坚持使用瀑布法，并签订大额的预付合同），尝试新方案，项目按照功能或者阶段划分为多个子合同，做小项分包，或者改为签订人力外包合同。针对我们想要构建的功能，拟定一个顺序列表。找几名开发人员，最好是独立的自由职业者，但如果同意以下流程，开发工作室也没问题。对于每名开发人员，挑选列表中最重要的功能，与他们讨论功能需求、预算和成本。让他们实现那个特性并测试。让一名内部人员审核他们的 PR，测试升级后的 App，并标出有问题的地方。符合要求后，合并并部署该特性，这样，所有创始人/用户就可以继续审核该 App，并提供反馈或者根据需要调整。如果我们对他们所做的工作感到满意，就挑选下一个我们希望他们实现的功能，然后再次重复这个过程。如果我们对他们的工作不满意，就解雇他们，并寻找替代者。当前需要做的工作，整理敏捷开发平台或者公共开发平台，并且参照以下原则：客户合作胜于合同谈判个体和互动胜于流程可运行的软件胜于详细的文档响应变化胜于遵循计划参考文章：Experiences working with an Outsourced Dev Shop
敏捷项目管理需要知道的五类图表
轻量级的报表、文档可以有效地帮助敏捷团队更好的将工作可视化、辅助和客户的沟通、清晰的展示进度并且对风险进行把控，对项目管理有很好的作用。在过去的项目管理经验中，个人认为有五类图表是项目经理需要了解并且可以在日常工作中频繁使用的。敏捷的价值观强调可工作的软件更加重要，但也不能否认文档的价值。燃尽图 ( 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（专业） 的管理领域这个领域主要指的是如何通过管理干系人，为客户提供专业的服务。首先，需要做的是对干系人进行分类，干系人分类的方法有很多，下面介绍的这种是基于干系人的权利和对项目的赞同程度来分的：针对每一类型的干系人，进行区别管理：对于位高权重且立场坚定的干系人，需要做的是建立同盟，邀请决策；对于位高权重但容易动摇的干系人，需要做的是管理争议，帮助其坚定信心；对于权利较低，左右摇摆的干系人，需要做的频繁沟通，尽量争取；对于权利较低，死心塌地的干系人，需要做的是并肩作战，打听情报。其次，需要在深度了解客户的基础上，通过自己的专业经验和服务态度引领客户做出最优的决策，并且帮助客户落地解决问题。深度了解客户是提供专业服务的第一步，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人左右时，就很容易走向倒闭。 其中，很重要的一个原因是，创业公司大多倡导唯快不破，公司的管理层将大部分的时间花在了打造产品、扩大市场以及满足用户上，很有可能并没有在意公司内部的结构问题。 但员工人数一旦增加后，最初创业的氛围就会发生改变，老员工和新引入的员工之间的融合和配合渐渐会出现问题，这种人际上的问题最终将会影响到公司动作的执行和落地。 很多创始人在这个阶段也会出现困惑——是继续坚持无为而治，还是开始集权管理？是从外部招募中层管理人员还是内部提拔员工加强管理？是继续扩大招聘以满足增长需求还是外包团队？ 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人规模时出现的问题。而在那之前，我们只需要花时间关注于创业公司的发展，精心呵护这个“青少年”，并陪伴它进入“成年期”。
软件企业缺成本费用怎么做税收筹划节税
身边有个朋友是做软件行业的，业务做得比较好，估计做这个行业的人都清楚，实在是没什么进项，但是又得开票，所以被企业所得税压得喘不过气来。一、当前我国软件企业合理避税中存在的问题由于受制于部分软件企业自身管理水平，部分软件开发企业在投资时过于关注眼前利益，忽略了对企业长期发展利益的重视，在经营过程中，管理者不注重经营方式，不加筹划和研究，不重视对纳税的合理回避，这些都会在一定程度上导致软件企业纳税负担过重，影响企业的未来长期发展，约束盈利能力提升。软件企业税收筹划的成本比较高，尽管企业依靠合理避税可以实现有效的税收筹划，但是企业在税收筹划中需要设置必要的部门或机构来进行此项工作，在这个程序中依旧会加大运营成本，尤其是依靠税务机构进行筹划，企业往往需要花费比较高的咨询费用，在这种程度上来讲，合理避税效率比较低，难以实现降低纳税负担的作用。二、软件行业税收优惠及税收筹划思路分析明确公司的税收性质，一般纳税人？小规模纳税人？软件销售及技术服务技术服务类的征收税率3%（小规模纳税人）6%（一般纳税人）软件产品17%技术开发费的增值税如何减免?这一块是相对容易免税的，只需要将技术开发合同拿到当地的科技局备案即可，但必须注意：其中的知识产权必须是对方所有或者双方共享，如果是你的知识产权是不能免税的。同样如果你免税了，那么你开出的增值税专用票对方也是无法抵扣的。软件产品增值税如何减免?软件产品销售，征税税率3%（小规模）17%（一般纳税人），小规模3%这个是逃不掉的，但是你如果软件销售达到50万（1年内）会强制你变为一般纳税人，那时候17%的税率压力就会比较大，因此建议你这之前就做好软件产品认证。快的话1个月搞定，拿到这个证书后即便是一般纳税人也可以享受3%的增值率（超过3%的部分即征即退）。研发费用加计扣除是什么?这是能帮企业省所得税，例如，一个公司一年的研发费用是100万，做了研发费用加计扣除后，研发费用就可以按照150万来计算。就等于说多了50万的成本，自然利润就少，所得税就了。最后来说企业所得税除了上面说的研发费用加计扣除，其实我们都知道软件企业哪来多少成本，无非就是人员成本，那么如果这样，你年底的所得税就会很可怕了。净利润的25%，这种情况下，可以在有税收优惠的地区注册一家个人独资企业，不需要缴纳企业所得税，个人所得税进行核定征收，完美解决成本问题，比如江苏徐州市高新区税收优惠政策:只要将企业注册在江苏徐州市工业园区(注册式，不用实地办公)，两种方式：a、有限公司(一般纳税人)增值税根据地方财政所得部分的50%-70%予以财政扶持奖励;企业所得税按照地方财政所得部分的50%-70%予以财政扶持奖励。b、个人独资企业或者合伙企业(一般纳税人)这种方式是对于缺乏或无法取得进项的企业，可以注册成个人独资企业或合伙企业对所得税进行核定征收，所得税税率可降低至0.5%-3.5%，其增值税还有返还奖励，通过纳税筹划解决企业成本、个人所得税、分红等问题。发布于 2018-05-28