Hello World - 工作
type: channel
link: http://blog.38data.com/index.php/category/work/
items: 第七届世界智能制造大会
items: 管理心得，不间断记录
items: 涉密信息管理系统(分级保护评测)
items: 软件架构师应该知道的97件事之概括
items: 安全可靠技术和产业联盟-会员单位介绍（2018）
items: 7大迹象，表明你的DevOps 做对了！
items: 新项目别一上来就用微服务
items: 一人公司方法论
items: 软件外包思考 二 验收
items: 软件外包思考 一

第七届世界智能制造大会
type: item
date: 2023-05-19T23:42:09+08:00

管理心得，不间断记录
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、会激发，你是专家我不行、顶梁柱；

涉密信息管理系统(分级保护评测)
type: item
date: 2022-09-11T23:34:00+08:00
description: 主要包括两个部分：三员和密级，其他的包括标准的漏扫等三员包括：服务器、数据库、应用系统涉密机东方通中间件、达梦数据库只能安装在root创建user用户，限制文件夹权限服务器三员：中孚数据库三员：达梦DM8 SYSDBA、SYSSSO、SYSAUDITOR(SYS、CTISYS)应用系统三员包括：SYSADMIN 系统管理员 简称：管理员SYSSSO 安全保密管理员 简称：保密员SYSAUDITOR 安全审计员 简称：审计员SYSADMIN：创建、编辑、删除用户创建、编辑、删除角色创建、编辑、删除表单、流程等业务数据，包括数据字典、菜单等SYSSSO：重置、修改用户密码权限角色设置用户日志、管理员日志、审计员日志审计策略SYSAUDITOR：管理员日志、保密员日志，日志内如除了基本的时间、地点、API地址、业务描述，还需要业务数据应用系统密级设定内容：用户密级设定表单密级设定、表单附件密级设定密级优先级设定：人员密级>=信息密级，具体如下发起人>=表单>=附件接收人>=表单>=附件应用系统设置其他要求：Session 10分钟 用户重新登录密码复杂度要求附件存储于服务器指定用户目录默认用户无权限，需要保密员授权用户登录失败次数锁定(含日志)、保密员重置解锁

软件架构师应该知道的97件事之概括
type: item
date: 2022-05-15T21:49:00+08:00
description: 架构师是一种神秘的职位，据说每个架构师都有密不可传的方法，当然我们不信，更多的是只可意会不可言传。就是说了我们也不会懂，因为还每到“火候”。所能做的就是，当我们到这种火候的时候我们能想起来曾经有过架构师这么说过，然后我们就可以更自信的向前大步走....1、客户需求重于个人简历要想拥有漂亮的个人简历：我们常常向客户推荐技术、手段，甚至方法论来解决问题，使用时髦的编程技巧和流行的范式，有时候根本不是寻求解决问题的最佳方案。积累一批满意的客户，选择切合实际的技术解决他们的难题，让他们乐于推荐你才是最好的履历。2、简化根本复杂性，消除偶发复杂性根本复杂性指的是与生俱来的、无法避免的困难。比如，协调全国的空中交通就是一个“天生的”复杂问题，必须实时跟踪每架飞机的位置。偶发复杂性：是人们解决根本复杂性的过程中衍生的。架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。怎么做？尽量选择源自实际项目的框架，警惕那些象牙塔里面的产品。3、关键问题可能不是出在技术上简单的项目也会翻船，而且这不是个别情况。大多数项目是人完成的，人才是项目成败与否的基础。如果团队里有人工作方式不正确，拖项目后腿怎么办？有一种非常古老但很完善的技术可以帮助你解决问题。它可能是人类历史上最重要的技术创新，这就是对话。有几个简单的对话技巧可以显著改善对话效果：不要把对话当成对抗。不要带着情绪与人沟通。尝试通过沟通设置共同的目标。4、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格沟通必须简明清晰，没有人愿意阅读冗长的架构决策文档，架构师言简意赅的表达观点是项目成功的必要条件。架构师往往忽略了自己也是领导者。作为领导者我们必须获得同伴的尊敬才能顺利开展工作。所有的成员都希望有明确的沟通和开明的领导。只能这样才能改善沟通效果，建立团结健康的工作环境。5、架构决定性能大家似乎理解，事实并未如此，有些架构师认为简单的更换底层架构就足以解决应用的性能问题，他们很可能轻信了“经测试产品性能超出竞争对手25%”，比如从4ms到3ms，这1ms放在一个性能极低的架构里几乎可以忽略不计。归根结底，所有产品和架构必须遵循分布式计算和物理学的基本原理：运行应用和产品的计算机性能有限，通过物理连接和逻辑协议实现的通信必然有延时。因此，应该承认架构才是影响应用性能和可伸缩性的决定因素。性能参数是无法简单的通过更换软件，或者“调优”底层软件架构来改善的，我们必须在架构的设计和重新设计上投入更多的精力。6、分析客户需求背后的意义顾客和最终用户通常提出的所谓需求，只是他们心目中可行的解决方案，并不是问题唯一的解决途径，当了解顾客的需求背后的意义，我们可以为顾客解决真正的问题并可能降低难度。7、起立发言许多架构师都是从技术岗位上成长起来的，他们擅长和机器打交道，然而架构师更需要与人打交道，无论劝说开发人员接受具体的设计模式，还是向管理层解释购买中间件的利弊，沟通都是达成目标的核心技能。有经验的架构师会很重视推销自己的想法也明白有效沟通的重要性，其中一个简单又实用的技巧是在2人以上的场合发表意见时请“站起来”，起立发言非常重要尤其是当其他人坐着的时候。当你站起来的时候无形中添加一种权威和自信，自然就控制住了场面，听众不会随意打断你的发言，这些都会让你的发言效果大为改观，你会发现站立可以更好的用双手和肢体语言。在10人以上的场合，起立发言方便你与每位听众保持视线接触。眼神交流、肢体语言等表达方式在沟通中的作用不可小觑。起立发言还可以让你更好的控制语气、语调、语速和嗓门，让你的声音传的更远。当你讲到重点内容时，注意放慢语速。发声技巧也能显著改善沟通效果。比沟通事半功倍，起立发言是最简单、有效的方法。8、故障终究会发生硬件会出错，于是我们增加冗余资源来提升系统的可靠性，同时也增加了至少有一台设备出错的概率。软件会出错，增加额外的监控程序也会出错。于是我们又为自动化增加监控，结果是更多的软件，导致更高的故障率。类似的如：三里岛核电站泄漏事故既然必然会出错就需要事先设计好防范故障的模型，以应对威胁系统安全的意外情况。9、我们常常忽略自己在谈判我们都面临过削减预算的要求，如果资金运转促襟见肘，技术方案只能委屈求全。比如如下情景：“我们真的需要这东西吗？”项目投资人发难道。尽管真的需要，我们通常也不能这么回答，因为此时我们是在谈判，此时我们需要认清自己的角色，不能把自己当成工程师，而且投资人明白他在和你谈判，我们应该这样回答"真的需要吗"这类问题：“单台服务器每天至少崩溃3次，没有第二台我们甚至无法跟董事会演示，事实上我们需要4台服务器，构成2组，这样在需要时断开一组而不必被迫关闭系统。即使有一台出现意外，也不影响系统正常运行”10、量化需求速度快不能算作需求，响应灵敏和可扩展也不能算需求，因为我们无法客观…

安全可靠技术和产业联盟-会员单位介绍（2018）
type: item
date: 2022-05-05T10:53:00+08:00
description: 安可联盟，全称是“安全可靠技术和产业联盟”，它的前身是“信息技术应用创新工作委员会”。2016年3月4日工委会成立，是由24家从事软硬件关键技术研究、应用和服务的单位发起建立的非营利性社会组织。2019年1月9日起，安全可靠技术和产业联盟正式变更为中国电子工业标准化技术协会安全可靠工作委员会（后文简称“安全可靠工作委员会”）。这个是官网地址：信息技术应用创新工作委员会安全可靠技术和产业联盟主要成员单位包括联盟理事和联盟会员两大类。安可理事会主要由四类单位：集成厂商、互利网厂商、第三方机构、高等院校，他们主要负责审核后续加入的安可成员单位资质，制定安可标准规范。其中联盟理事（19家）又分为：集成厂商（10家）、测试厂商（4家）、互联网厂商（3家）和高等院校（2家）四大类。集成厂商（10家）包括：华宇软件、神州航天软件、东华软件、东软集团、航天信息、浪潮软件集团、神州信息、太极股份、同方股份、中国软件测试机构（4家）包括：国家工业信息安全发展研究中心、中国电子技术标准化研究院、工业和信息化部电子第五研究所、中国电子信息产业发展研究院互联网厂商（3家）包括：阿里云、金山软件、华为技术高等院校（2家）包括：北京航空航天大学、北京理工大学联盟会员则包含：芯片厂商（7家）、集成厂商（12家）、整机厂商（8家）、操作系统厂商（9家）、数据库厂商（6家）、中间件厂商（3家）、流版签厂商（7家）、外设固件厂商（3家）、安全厂商（6家）、网络厂商（3家）、互联网厂商（2家）、存储厂商（5家）和应用软件厂商（2家）共十二大类。芯片厂商（7家）包括：上海兆芯（X86）、东土军悦（交换机芯片、东土科技）、国科微（安防、存储、物联网芯片）、盛科网络（交换机芯片、中国电子、振华科技）、天津飞腾（ARM、中国长城、振华科技）、上海高性能集成电路设计中心（Alpha、申威）、龙芯中科（MIPS）集成厂商（12家）包括：百得科技、华胜天成、中软信息（中国软件）、广东省信息工程公司、中科软、南威软件、太极信息（太极股份）、烽火信息（烽火通信）、万达信息、中软系统（中国软件）、中科九洲、长城软件（中国软件）整机厂商（8家）包括：上海仪电智通、联想长风、华胜天成、长城科技（中国长城）、宝德网络、曙光信息（中科曙光）、百信信息、北京计算机技术及应用研究所（航天二院706所）操作系统厂商（9家）包括：中科方德（兆芯）、一铭软件、湖南麒麟信安（中国软件）、天津麒麟（中国软件）、思普投资（X86）、深之度、普华基础软件（中国电科）、航天国盛（航天科技）、中标软件（中国软件）数据库厂商（6家）包括：武汉达梦（中国软件）、神舟通用（航天科技）、人大金仓（太极股份）、南大通用、恒辉信达、瀚高基础软件中间件厂商（3家）包括：金蝶天燕中间件、东方通、中创软件流版签厂商（7家）包括：金格科技（电子签章）、方正国际软件（电子文档）、书生电子（启明星辰、安全文档）、数科网维（版式OFD）、航天福昕（文档OFD）、安证通（电子签章）、永中软件（office，办公软件）外设固件厂商（3家）包括：立思辰（文件管理）、中电科技（中国电子、BIOS等）、光电通信（传真机）安全厂商（6家）包括：星网锐捷（通信、安全）、中孚信息（安全保密）、安宁创新（邮件、消息）、中安网脉（密码、存储）、海泰方圆（密码、安全）、卫士通（密码、芯片、系统）网络厂商（3家）包括：紫光集团（从芯到云）、迈普通信（中国电子、网络设备）、仰联信通（交换机）互联网厂商（2家）包括：拓尔思、恒生电子存储厂商（5家）包括：滕凌科技（存储）、亚细亚智业（存储灾备）、同有科技（存储）、鲸鲨软件（存储）、鼎甲科技（中国电子、灾备）应用软件厂商（2家）包括：慧点科技（太极股份、管理软件）、华电园技术（办公自动化）来源时间 2018-07

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-13T14:17:33+08:00
description: 微服务变得越来越理所当然，似乎我们一直生活在微服务的世界中。很多时候，我们常常讨论微服务采用与否、如何选型等问题。但本文作者 Arnold Galovics 想讨论的是，为什么一个全新的项目从开始就使用微服务通常是个坏主意。很长一段时间以来，他都在思考这个问题。最近，当他与其他开发人员交谈并询问他们如何启动一个全新项目时，答案几乎都是：这儿用一个微服务，那儿用一个微服务，用户管理用一个微服务，身份验证用一个微服务，鉴权用一个微服务，session 管理用一个微服务等等。因此，关于微服务，Arnold 想基于他过去工作项目的一手经验，讲讲别人没有讲过的一些东西，他撰写了一篇题为《不要从微服务开始，单体架构才是你的朋友》（Don’t Start With Microservices – Monoliths Are Your Friend）的文章。Arnold 的文章很快在技术社区引发热议。有持赞同意见的人直言，微服务对于大多数普通需求来说是一种“矫枉过正”，还有人提出微服务有个 Arnold 没提到的更严重的缺点——将事情分成模块需要时间，并且涉及做出我们可能不知道答案的决定。“启动新产品时，最重要的是尽快启动并运行产品，以便人们可以试用并提供反馈。而根据收到的反馈，我们往往可能会意识到需要构建与现有的完全不同的东西。我见过很多工程劣质的成功产品，也见过很多设计精良的产品失败。产品的成功与其设计的好坏无关。速度往往是最重要的因素。”另外，有条热门评论提出了个有意思的问题：为什么没有人谈论介于这两者之间的架构——模块化单体？对此，有回复说道“因为没有新发明的架构称为‘模块化单体’——单体从一开始就应该是模块化的。”该回复进一步指出，微服务不是单体应用不好而诞生的答案，人们的理解在某些地方出现了问题，这也可能是因为很多人不知道应该在代码中构建模块，然后大量的单体最终成为“意大利面条式”代码，就像现在许多微服务架构那样。有人对此表示赞同并表示，“模块化单体”只是“代码中关注点的适当分离”，其实从一开始就存在。但也有人提出反对意见，认为“模块化单体”要比“分离关注点”要更复杂，并不完全是一回事。一千个人眼中有一千个哈姆雷特，我们将 Arnold Galovic 的这篇文章翻译出来，希望能为读者带来一些参考价值。以下是他的分享内容：理想中的微服务我们先来看看，多数文章提到的一些微服务的主要优势有哪些：故障隔离消除技术锁定更容易理解更快的部署可伸缩性是的，这些都不是书中的虚假承诺，但我也必须对你说实话，使用微服务的话，你的系统很难实现这些承诺。下面让我一一列举这些优势。故障隔离。由于应用程序由多个服务组成，因此如果其中一个服务宕机或出现问题，则只会影响系统的那个部分。以 Netflix 为例，当你观看节目时，你并不关心推荐。因此，如果它们有一个服务来处理当前观众，为他们提供视频流；它们有另一个服务来处理个人用户推荐。如果推荐服务宕机，系统中最重要的功能（例如观看节目）不会受到影响。故障被隔离了。消除技术锁定。想想单体应用。它是一个巨大的应用程序，有成百上千个 API，管理数百个数据库表。这个应用程序是用 Java 写的，团队花了 5 年时间开发它。一种奇特的新语言出现了，纸面上带来更好的性能、提供更好的安全性等等。这可能是 Go 或 Rust，团队想试验下该语言及其技术栈。他们如何在一个单体应用中做到这一点呢？他们做不到，因为这是一个单独的部署包。你可以将应用程序的一部分切换到不同的语言，但这并不容易做到。使用微服务时，不同的服务可以使用不同的技术栈。服务 A 可以用 Java 写，服务 B 可以用 Go 写，服务 C 可以用Whitespace写，如果你有勇气这么做的话。更容易理解。当你有多个服务负责整个功能的一小部分时，这个服务本质上会更小，因此更容易理解。更快的部署。在常规的单体应用系统中，要么完全部署，要么根本不部署。你需要部署一个包，这是一个要么全有要么全无的场景。使用微服务，你有机会独立部署，这意味着，如果你想要部署推荐服务的一次升级（回到 Netflix 的例子），你可以部署单个服务并节省大量时间。可伸缩性。我的最爱。你可以通过启动多个实例来增加特定功能的容量，从而扩展服务。像前面举的例子，如果人们在 Netflix 上查看大量推荐，它们可以很容易地启动多个推荐服务的实例来应对负载。在单体应用环境中，你要么扩展应用程序的每一个部分，要么什么都不扩展。现实生活中的微服务我要用残酷的事实打击你，我的朋友。我并不是说这些优势无法实现，但是你、你的项目、你的组织必须非常努力才有可能实现这些优势。基础设施要求下面让我从微服务的一个最大困难——基础设施开始讲起。绝对是 10 r6g 的真实照片。在 K8S 上运行的单个登录应用程序的 16x…

一人公司方法论
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