Hello World - 管理
type: channel
link: http://blog.38data.com/index.php/category/%E7%AE%A1%E7%90%86/
items: 管理心得，不间断记录
items: 7大迹象，表明你的DevOps 做对了！
items: 一人公司方法论
items: 软件外包思考 二 验收
items: 软件外包思考 一
items: 敏捷项目管理需要知道的五类图表
items: 一页纸手把手教你怎么做敏捷项目管理
items: 腾讯内部论坛热文：如何做一个小型公司的技术总监
items: 为什么大多数创业公司止步于50人规模？ |【经纬低调分享】
items: 软件企业缺成本费用怎么做税收筹划节税

管理心得，不间断记录
type: item
date: 2022-09-18T18:17:00+08:00
description: 兼职管理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、会激发，你是专家我不行、顶梁柱；

7大迹象，表明你的DevOps 做对了！
type: item
date: 2022-03-08T16:20:15+08:00
description: 据预测，未来 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 的解释也…

一人公司方法论
type: item
date: 2022-02-07T21:55:00+08:00
description: 作者和授权信息本文由 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个小时的工作时间均摊到各种要做的事情上边，就会发现其实每一件事都分不了太多时间，这会造成整体业务进展慢。同时，因为就一个人，所以必须在多种业务之间来回切换，这会带来一些额外成本。比如说我们正在编程、正在做架构设计的时候，是在进行深度思考，如果这时候有一些紧急但不重要的事情插入进来，就会把我们从深度思考中拉出来，之后需要再花很多时间才能重新进入到这个状态里边去，甚至可能再也回不到当时的状态，从而丢失掉一些很好的想法。尤其是对一些创造性高的工作来讲，这是非常可惜的。一个人需要做全部事第二个缺点就是，一人公司往往要求我们一个人把整个链条上的所有事情都做了。原因很简单，因为整个公司就你一个人，你不做就没有人做。这样带来的一个非常明显的问题，就是工作量的大额增加。即使很多没有难度的事情，处理细节也会消耗大量的时间。另外还有一个更严重的问题，「麻雀虽小、五脏俱全」。它不但要求工作量，还对技能有要求。如果你缺乏特定的技能，就需要投入上百个小时的学习时间，而且还不一定能学得好。更有一些大型公司具有的资源，一人公司可能是不具…

软件外包思考 二 验收
type: item
date: 2021-07-20T09:27:00+08:00
description: 交付物软件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、以上内容建议附加进商务合同，成为其中一部分。

软件外包思考 一
type: item
date: 2021-07-04T22:26:00+08:00
description: 软件外包存在风险，外包人员技术、态度、交付能力，如果想通过合同或者诉讼降低风险，由于太多的未知因素和太多的主观性，不现实。因此唯一的外包原则应该是：如果外包人员做得不好，有能力随时终止合作且可控费用损失和项目交付。可以尝试渐进式方法，首先废除传统开发外包大瀑布方式（例如签订需求URS、项目总金额、进度款支付）（不过目前大部分外包会坚持使用瀑布法，并签订大额的预付合同），尝试新方案，项目按照功能或者阶段划分为多个子合同，做小项分包，或者改为签订人力外包合同。针对我们想要构建的功能，拟定一个顺序列表。找几名开发人员，最好是独立的自由职业者，但如果同意以下流程，开发工作室也没问题。对于每名开发人员，挑选列表中最重要的功能，与他们讨论功能需求、预算和成本。让他们实现那个特性并测试。让一名内部人员审核他们的 PR，测试升级后的 App，并标出有问题的地方。符合要求后，合并并部署该特性，这样，所有创始人/用户就可以继续审核该 App，并提供反馈或者根据需要调整。如果我们对他们所做的工作感到满意，就挑选下一个我们希望他们实现的功能，然后再次重复这个过程。如果我们对他们的工作不满意，就解雇他们，并寻找替代者。当前需要做的工作，整理敏捷开发平台或者公共开发平台，并且参照以下原则：客户合作胜于合同谈判个体和互动胜于流程可运行的软件胜于详细的文档响应变化胜于遵循计划参考文章：Experiences working with an Outsourced Dev Shop

敏捷项目管理需要知道的五类图表
type: item
date: 2020-11-22T18:15:19+08:00
description: 轻量级的报表、文档可以有效地帮助敏捷团队更好的将工作可视化、辅助和客户的沟通、清晰的展示进度并且对风险进行把控，对项目管理有很好的作用。在过去的项目管理经验中，个人认为有五类图表是项目经理需要了解并且可以在日常工作中频繁使用的。敏捷的价值观强调可工作的软件更加重要，但也不能否认文档的价值。燃尽图 ( 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方面目前还在尝试解决。如果发现有红色出现或者某项持续绿色，项目经理就需要…

一页纸手把手教你怎么做敏捷项目管理
type: item
date: 2020-01-12T00:29:00+08:00
description: 文章来源于聂子云 ，作者聂子敏捷项目是为应对变化和不确定性而生，作为项目的管理者（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)：核心议题是下一个迭代要实现的…

腾讯内部论坛热文：如何做一个小型公司的技术总监
type: item
date: 2019-07-28T19:42:31+08:00
description: 本文在腾讯内部论坛被浏览达7347次，收藏615次，评论几百条，曾经是讨论最热烈的项目管理文章之一。作为作者本身，感觉这个话题可以讨论的范围非常大，希望能有更多朋友一起切磋探索技术团队的管理之道。资深程序员是团队中最强大的生产力，但往往被不合理的工作安排浪费掉。因此作为一个团队的技术的“头”，必须要有明确清晰的认识，把主要的事务性工作剥离出来。并且放弃大量的管理“权力”，以提高团队开发质量和效率为最主要的目标去安排自己的工作。一般来说技术总监其实会被要求做事实上是2个职位的工作：主程、项目经理（技术化）。因此必须明确此两个职位的工作任务分割。然后把项目经理的工作，安排给另外一个人做，当然其职称可能同样也得叫“技术总监”或“主程”，总之听起来越牛X越好。而真正的主程（技术总监）则应该投身于尽量多的技术工作中。而最重要的工作则是开发——生产代码和文档。主程的工作：一、开发从来没有一个资深的外科医生会放下手术刀，而转到手术室外面指手画脚。一个资深的程序员也不应该离开代码和文档的编写，而只是做做架构图。作为对一个复杂系统的负责人，必须亲手领导和参与建造，才能有足够的能力去负担起这个责任。因此需要至少使用60%的时间来参与开发的工作，并且建议从一开始上班就开始，虽然早上的效率很低，但是跟任何艰巨工作都一样：万事开头难。在你好不容易等待电脑慢吞吞的打开了所有的IDE、需求文档、参考资料、工作计划这堆要命的东西之后，你就迈出了最重要的一步，你会发现你不在需要在网上看微博和聊QQ来提振开始工作的激情，而会被某一个优化代码的灵感而激励，或者被一个复杂而有趣的问题所吸引，从而更快的能投入到开发中。坚持打开电脑做的第一件事是打开IDE软件，是这一切最重要的一步。开发的工作内容包括有：1、提出非功能性需求一般来说功能需求总是让开发人员焦头烂额的主要原因。但是实际上很多项目死在发布之后，却是因为性能、产品质量、扩展性、二次开发效率等非功能性需求没认真去解决而导致的。主程作为经验最丰富的成员，必须要利用自己曾经的经验和教训（在这里教训往往比经验重要），提出那些自己折腾自己的“非功能性需求”，来保障整个项目在发布后不会轰然倒塌。这是个吃力不讨好的工作，因为老板和客户往往只会抱怨技术人员在玩弄把戏，骗取更多的资源或者杞人忧天。如何说服这些家伙也许不是主程的工作，但是主程必须要以高度的责任心把问题放到台面上来。沟通的工作也许让项目经理去做会更好，他们有一整套如何威逼利诱老板和客户的戏法。2、设计和修正软件架构软件架构设计至关重要，而且工作繁重。不画图纸就敢开工的技术人员要么是天才要么是笨蛋。对于团队来说，架构在分工合作、避免风险、提高质量等多个方面有无可替代的作用。架构要避免成为空洞的文档，最重要的一步是有人来掌控和实施。而主程主持设计和修正的架构，并且亲手实施，让团队中的腹诽之徒完全无法避开，否则代码将无法运行！所谓设计和修正架构，并不意味所有的文档应该一个人写，而是指这个架构的每个环节，都是经过主程决策同意的。当然最好这些文档能尽量由他撰写，对于“菜鸟”团队来说，输出这种文档本身就意味着“权势”，有助于主程建立个人威信——这种看起来有点肮脏的“政治”东西，在避免团队内无止境的扯皮，以及稳定那些随时准备跳槽的成员来说，都是相当实用的。3、难点代码（关键需求）的开发主程必须写代码，写那些大家都认为风险大的代码。有的系统对于性能要求很高，他就必须去完成容易出性能问题的部分，比如IO操作或者设计数据库索引。有些系统的需求非常飘忽，他就要去想办法完成框架代码或者脚本引擎，以便众多小弟可以跟着产品人员疲于奔命。这种工作内容会让主程不必完全的读过所有代码，而能牢牢的“掌握”代码，以免团队成员甩耙子的时候能充当备胎。因为融入团队的代码开发，也是一个让架构设计从日常工作中真正控制系统的工作。而且主程代码通常会被别人接触，能直接教育其他团队成员，同时也能建立——威信。4、救火和杀虫这个工作其实和代码开发是一致的，如果没有平日的开发，通常紧急问题的解决也是比较难处理的。但是这个也有一个调试技巧的要求，比如要求会使用各种诊断工具。这些工具一般的开发人员可能会比较少使用。找问题的过程本身也可以提高团队其他人的技术水平。二、培训培训的工作应该占用30%左右的工作时间。培训是稳定团队人员最重要的手段。也是提高团队开发效率最有效的手段。工具、过程、制度、奖惩，这些都代替不了程序员一行行的去写代码，最直接的方法是让他们做的更快更好，这些需要经验和知识的积累。1、代码审查关于代码审查，有太多的论述。但是代码审查还是一种“强迫”推行某种风格或者技巧的手段，这是最真实的“控制”系统的手段。也是推广知识和经验最直接的手段。一个人写的代码通常应对的问题不会特别“广泛”，因此只要审查其中一部分代码，就…

为什么大多数创业公司止步于50人规模？ |【经纬低调分享】
type: item
date: 2019-05-14T01:11:00+08:00
description: 许多成长中的创业公司，一旦规模扩大到50人左右时，就很容易走向倒闭。 其中，很重要的一个原因是，创业公司大多倡导唯快不破，公司的管理层将大部分的时间花在了打造产品、扩大市场以及满足用户上，很有可能并没有在意公司内部的结构问题。 但员工人数一旦增加后，最初创业的氛围就会发生改变，老员工和新引入的员工之间的融合和配合渐渐会出现问题，这种人际上的问题最终将会影响到公司动作的执行和落地。 很多创始人在这个阶段也会出现困惑——是继续坚持无为而治，还是开始集权管理？是从外部招募中层管理人员还是内部提拔员工加强管理？是继续扩大招聘以满足增长需求还是外包团队？ 50人规模，是迈向100人、1000人甚至更大规模的垫脚石。因此，在这个阶段，尽早地解决公司出现的管理问题是至关重要的。今天分享的这篇文章，提供了在这个阶段的公司，可以参考的四种解决方案，希望给你带来一些启发。以下，Enjoy:许多正在成长的创业公司，一旦规模扩大到50人左右时，就很可能走向倒闭。我把它称作创业的“青少年期”，我自己也经历过几次。其中，有我作为员工的经历，也有作为管理者的经历。初创公司不断成长的初期到底有什么变化？1至10人规模：到某个阶段时，元老级员工就不再愿意接纳新的员工。他们有什么事情不会立即说出来，并且他们内心中开始出现一种愤懑感，特别是需要重复为新来的“菜鸟”展示如何简单地完成某项任务时。他们对新人出错的容忍度极其地低，尽管那些错误也是他们曾经犯过的错误。10至25人规模：第二批员工开始形成自己的小圈子。他们可能有时候会怀念“过去的好日子”，但他们越来越重视像职位头衔以及公司地位等方面的内容。在日常的交流中，带有“高级”二字的职位名称出现得越来越频繁。26至39人规模：在这个阶段，就会出现“权力的游戏”这类现象。如果“青少年”会形成自己的“群体”，那么“而立之辈”则会对公司内部的“顽固守旧派”充满了愤懑和不满情绪。40至49人规模：天哪！现在到底是什么状况？虽然前述各阶段的变化情况并不是适用于所有的创业公司，但当创业公司达到50人规模时，总会有遇到类似经历的时候。我之前说过，我经历过上述各个阶段，并且对每个阶段可能发生的变化进行了归纳描述，因此，我不再做任何评价。或者，我可能需要评价一两句。在创业公司快出现倒闭征兆之前，至少应该采取一些补救措施。我们需要把处于“青少年期”的创业公司“赶出家门”，让它自己去亲身经历和体会“成年人的世界”，并且像“成年人”一样地发展下去。公司规模达到50人并开始出乱子时，也并不会落到满盘皆输的结局。首先，这种状况必然代表着，公司还在成长中，可能还比计划成长的速度更快。只要成长还在可控范围内，这些问题都不是问题。如果公司的确在成长，并且是朝着健康的方向发展的，那么公司内部可能已经形成了一种内在文化、规范以及办事方法。它们虽然没有形成书面的规章制度，但每个人心里却一清二楚。在这种状态下，日常的交流可能更多的是面对面交流，或者是基于需求的交流。不存在太多正式的会议甚至会议纪要，当然，这也意味着可以节约大把应对这些繁文缛节的时间，并花在真正需要解决的问题上。此外，从反方面来看，这种内部的状态也可以理解为，公司的管理层正在花时间打造产品、渗透市场以及满足用户，他们可能并没有在意公司内部的结构问题。但是，既然开始出了乱子，那就应该重视起来。否则，大家都不想看到，“青少年”在“叛逆期”里“离家出走”的局面。为人父母的都知道，针对青少年的叛逆期，根本没有所谓的治疗方法。能够做的，只不过是静静地等待他们成长。有这么一句关于“出乱子”的话，我非常不喜欢。它是这样说的：“必须要经历震荡、成形、常态、规范这四个阶段。”这句话在这里也适用，但我之所以不喜欢，是因为它的用处不大。虽然出了乱子，没有所谓的“治疗方案”。但我们总可以采取一些措施，并以此来应对难关。以下四种措施，是我比较熟悉的几种解决方案，我从中也得到不少灵感，希望对你有所启发：1、无所作为不要以为无所作为，就没有存在的意义。很多创业公司在开始出现人员流失时，才意识到应该无所作为。所谓“无所作为”，并不是什么都不做。毕竟，在日常经营过程中，肯定会时不时地出现各种问题，而我们也无法回避这些问题。无所作为，其真正的含义是，要积极主动地“无所作为”，并在问题出现时积极解决问题。但我并不推荐这种做法。试想一下，如果我们给某些员工的职场头衔前加上“高级”二字，并且这种做法完全是无章可循的，那么将有什么后果？再以开会来举例。针对“什么时候开会？”以及“怎样开会？”这两个问题，需要相应的规定约束。否则，每个人的日程表上都排满了各种会议，会议室资源也出现严重稀缺的局面，到最后可能什么事都做不好。甚至，连员工的“远程办公”申请都值得考虑。如果我们没有相应的管理方法，即便事情现在没错，到时候总会出错。我并不是在讨论滥…

软件企业缺成本费用怎么做税收筹划节税
type: item
date: 2019-05-10T10:52:22+08:00
description: 身边有个朋友是做软件行业的，业务做得比较好，估计做这个行业的人都清楚，实在是没什么进项，但是又得开票，所以被企业所得税压得喘不过气来。一、当前我国软件企业合理避税中存在的问题由于受制于部分软件企业自身管理水平，部分软件开发企业在投资时过于关注眼前利益，忽略了对企业长期发展利益的重视，在经营过程中，管理者不注重经营方式，不加筹划和研究，不重视对纳税的合理回避，这些都会在一定程度上导致软件企业纳税负担过重，影响企业的未来长期发展，约束盈利能力提升。软件企业税收筹划的成本比较高，尽管企业依靠合理避税可以实现有效的税收筹划，但是企业在税收筹划中需要设置必要的部门或机构来进行此项工作，在这个程序中依旧会加大运营成本，尤其是依靠税务机构进行筹划，企业往往需要花费比较高的咨询费用，在这种程度上来讲，合理避税效率比较低，难以实现降低纳税负担的作用。二、软件行业税收优惠及税收筹划思路分析明确公司的税收性质，一般纳税人？小规模纳税人？软件销售及技术服务技术服务类的征收税率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