blackcat123的博客

原创 【原创】【必看】谈谈软件行业普遍存在的一些问题

权当是本人10余年从业经验以及所见所闻的一次复盘。从大局观的角度阐述与软件项目研发相关的种种问题。这些问题非常常见，几乎所有的团队多多少少都会存在这些问题。这些问题会严重降低工作效率、降低产品质量、降低用户满意度、提高项目成本、损害企业名誉等等。产品经理极为不专业，输出的需求存在各种各样的问题，比如含糊不清、不完善、逻辑矛盾、有二义性等等。需求分析的目的就是解决这些问题。需求分析会产生分析模型，例如数据流图、。UML等。然而几乎没有产品经理做了这项工作。在我的职业生涯中接触了大约20个产品经理，无一....

原创 【原创】如何快速判断团队的技术能力和管理水平

假定技术能力和管理水平均分为两个段位：高和低。那么只需解答一个问题就可以判断出团队所属的段位：项目是否大规模应用UML？？如果答案为是，那么团队属于高段位，否则属于低段位。UML，是统一建模语言的缩写，是面相对象软件开发的最基本的技术方法。通常将UML应用于需求分析与系统设计。谈谈为什么UML与技术能力有关。如果技术人员，包括产品经理、需求分析师、架构师、技术经理、程序员，不会使用UML，会显得很外行。技术人员是一定有段位差距的。段位高的是预防问题。而段位低的是制造问题，且陷入“制造——修复——制造——修复

原创 【原创】公司长期招不到人的原因和带来的风险

岗位对能力的要求过于苛刻。打个比方，你是顾客，你想购买一个交通工具，你要求该交通工具可以在陆地行驶、在水面航行、在天空飞行。这显然，不论是对于销售方还是对于厂家，都是做不到的。结果当然就是你无法购买到了。比如对于产品经理、需求分析师这两个岗位，很多企业要求求职者具有某行业的项目经验或某种业务类型的项目经验。这固然是一个加分项，但从科学的角度，不应是必备项。比如你的团队要给某公司的财务部门开发财务管理软件。那么你一定需要派人和该财务部门的员工（例如 会计、出纳）对接需求，因为她们才是最精通..........

原创 唯技术论的危害及如何破除

唯技术论，指的是片面认为技术能解决一切问题，或者一切问题都是技术问题。项目成功的关键因素不是技术而是管理。这在《软件工程导论》中就有明确的印证。在上个世纪有许许多多的软件项目都以失败告终。然而这些项目的项目组均由技术专家组成。人们开始反思为什么技术厉害项目依然会失败。随后就有了“软件危机”的概念，并且逐渐发展起软件工程的理论体系。或许很多人认为书本上的理论知识是和现实脱节的，有很多知识是没有用处的。其实不然，书本上的内容是前人总结出来的经验教训，如果你完全不采用这些方法论，那么你一定会踩坑，最终以失败告终。

原创 【原创】程序员更适合担任产品经理和需求分析师

程序员的思维优势是善于把控细节。程序员在了解到需求后会立即思考技术实现的方法，并立马找出需求存在的缺陷，把问题扼杀在摇篮里。可能是程序员性格原因，还可能是因为程序员经过长期的项目实战训练，变得越来越对细节敏感，形成了思维惯性。毕竟计算机本身就是高精度的，如果错了一个符号，很可能全部报废，就像Windows蓝屏那样。然而没有编程工作经历的产品经理（需求分析师）在细节把控方面明显弱一些。细节肯定是很重要的，假设要开发一个导弹发射系统。如果你的程序有一点点出错，哪怕是错了一个符号，那么你发射出去的导弹势必不会击中

原创 【原创】工作成果展示（部分）

工作成果（部分），UML、原型设计、产品设计、思维导图、visio、axure、需求分析、专利

原创 【必看】【原创】压低薪资导致企业倒闭的逻辑

这样的损失是难以估量的，因为像这样的质量事故会严重损害公司的名誉、形象，势必对今后公司的发展是极为不利的。员工A的看得见的成本确实比B低，但由于他只会文字沟通，效率不如员工B，因此A的看不见的成本比B高。换句话说，看得见的成本提高了，看不见的成本降低了，此起彼伏。如果别人给10k薪水，你也给10k薪水，那么你永远都只会招到普通的人，做出普通的产品，你的企业也永远只能做一个普通的企业，甚至还可能面临裁员和倒闭的险境。综上，压低薪资的企业，由于招聘不到人才，只能做出普通的产品，成为普通的企业，不可能做大做强。

原创 为什么招聘卡年龄会导致企业倒闭

要想把一件事情做好，除了需要知识、技能、经验外，很多时候更需要见识。当你有了足够的见识，你才能把握住正确的方向。如果方向不对，不论你再怎么努力，事情都不会办成功的。这就好比是新手司机和熟路司机的区别。而见识是怎么来的呢？？一点一滴积累起来的，就是多走多看。所以，年龄大的人，他拥有更多的见识，这反倒是他的优势。另外，量变是质变的必要前提条件。 举个现实中的例子。AMD公司在2012年的时候是濒临破产的，当时公司的股价还不到3美元。随后苏姿丰和吉姆凯勒加入了AMD公司。当年苏姿丰是43岁，吉姆凯勒

原创 设计模式简介及PHP的35种设计模式（下）

有经验的00开发者(以及其他的软件开发者)建立了既有通用原则又有惯用方案的指令系统来指导他们编制软件。如果以结构化形式对这些问题、解决方案和命名进行描述使其系统化，那么这些原则和习惯用法就可以称为模式。例如，下面是一个模式样例:模式名称: 信息专家(Information Expert)问题: 给对象分配职责的基本原则是什么?解决方案: 给类分配一种职责，使其具有完成该职责所需要的信息。

原创 设计模式简介及PHP的35种设计模式（中）

有经验的00开发者(以及其他的软件开发者)建立了既有通用原则又有惯用方案的指令系统来指导他们编制软件。如果以结构化形式对这些问题、解决方案和命名进行描述使其系统化，那么这些原则和习惯用法就可以称为模式。例如，下面是一个模式样例:模式名称: 信息专家(Information Expert)问题: 给对象分配职责的基本原则是什么?解决方案: 给类分配一种职责，使其具有完成该职责所需要的信息。

原创 设计模式简介及PHP的35种设计模式（上）

在不指定具体类的情况下创建一系列相关或依赖对象。通常创建的类都实现相同的接口。抽象工厂的客户并不关心这些对象是如何创建的，它只是知道它们是如何一起运行的。

原创 究竟什么是低代码？？

低代码，顾名思义，就是代码量少。它就是软件复用的体现。软件复用的意思就是软件过程所产生的资产被复用，例如需求、设计元素，代码函数、测试用例、代码规范定义、项目流程定义。例如 你写了个公共函数 get_uid_by_token( string token )，通过token获取用户id。那么你的同事可以在他所负责的模块调用这个函数，这样就避免了重复开发。之所以这几年低代码这个概念很火，其实本质是一种炒作。俗话说，内行看门道，外行看热闹。软件复用其实并不是什么新奇的玩意，它的历史可以追溯到上个世纪80年代。

原创 精读完了一本书——《软件需求（第3版）》

部分章节还读了两三遍。个人认为这本书应当作为产品经理的入门书籍。大学软件专业也应当开设相关课程，就定名为“需求工程”，将此书作为教材。可以说，此书是关于需求的百科全书，能让你了解到各方各面。并且学习门槛低，不需要太多预备知识，也不需要多么强的逻辑思维能力和抽象思维能力。作为入门书籍太合适了。不过呢，深度肯定是远远不够的，单独把建模拎出来就够你喝一大壶了。建模三大支柱：建模语言、建模方法、建模工具。想建模的，我强烈推荐 Enterprise Architect。此工具很牛，还支持需求开发和需求管理。

原创 AMD的逆袭之路（股价暴涨60余倍，市值超Intel）

当2018年报发布之后，连亏六年的AMD终于扭亏为盈了！到了2021年之时，AMD的归母净利润更是飞跃至31.62亿美元——差不多是2018年的十倍！至于AMD的股价，更是涨上天了。苏姿丰上任CEO的2014年，年终AMD的股价收于2.67美元。到了2021年，AMD的股价最高飞到了164.46美元的“云端”，也就是说七年时间其股价翻了60倍有余！纵使现在其市值已经落至1661亿美元，却依然比老对手英特尔的1488亿美元市值高。

原创 产品经理的学习路线

这方面也是有不少书籍的，譬如 《系统工程原理与实践》《基于模型的系统工程有效方法》《系统工程中的实践创造与创新》《系统工程方法论 —— 从TBSE进阶到MBSE》《系统工程：分析、设计与开发》。另外需要补充的是，如果产品经理的工作涉及到硬件，那么恐怕还需要学习SysML（系统建模语言），它是针对系统工程的建模语言。然而事实是，这样的投资，它的回报率是很高的，甚至能达到百倍以上。回到软件开发的正题，产品经理除了学习UML外，还有必要掌握其它的和需求有关的建模方法，例如 数据流图、判定树、判定表、鱼骨图。

原创 书籍推荐 —— 笑着离开惠普

对于现代人来说，更换工作是一件十分平凡的事情。但是你是在怎样的情况下离开公司的？是垂头丧气还是尴尬无奈？有没有一种离开，可以微笑着走呢？经营好的企业意味着赚钱，管理好的企业意味着健康，文化好的企业意味着快乐。惠普，就是一个能够让员工笑着离开的地方！《笑着离开惠普》在一定意义上简直就像一本企业成长工具书，他的实用性与价值因为有作者的真情实感相伴随，而更显得可信而亲切。《经济观察报》报业公司总编辑何力认识高建华先生的时候，他刚刚离开中国惠普，那是他的第三次离开。

原创 盲目砍掉成本只会让企业走向死亡

高建华，男，1961年出生于山东，原中国惠普公司助理总裁，首席知识官CKO，原苹果电脑公司中国市场总监。现任北京洋为中用管理咨询公司首席顾问。高建华先生擅长于营销战略、品牌建设、创新管理和企业可持续发展等领域。他的研究领域包括市场营销、品牌管理、企业战略、企业文化建设等，尤其在高科技企业的市场战略。盲目砍掉成本只会让企业走向死亡。

原创 为什么年轻团队难以打造爆款产品?

在二进宫AMD的岁月里，吉姆.凯勒设计了AMD最新一代Zen系列处理器的架构，包括之后的Zen 2以及即将推出的zen 3，实际上核心架构都是由吉姆.凯乐缔造的。这也是AMD在被Intel压制这么多年后能够重新崛起的关键，如果说苏妈是AMD复兴的核心，那么吉姆.凯勒就是AMD复兴的基石，直到现在，Ryzen系列处理器依然是民用X86处理器中性价比以及能耗比最优的选择。1995年转入IBM，她的主要职业生涯便是在“蓝色巨人”中度过的，期间在多个工程和业务部门担任过领导职位，包括半导体研发中心副总裁。

原创 需求管理流程

需求管理包括项目过程中所有保持需求协议的完整性、准确性和流通性的活动。图显示了需求管理的四大核心活动:版本控制、变更控制、需求状态跟踪和需求跟踪。可以将所有这些信息包含在一个需求管理过程描述中。或者，写单独的版本控制、变更控制、影响分析和状态跟踪过程。这些过程适用于整个组织，因。组织要定义项目团队需要执行的需求管理活动。将这些活动记录下来并进行培训，确保组织成员一致而有效地执行这些活动。

原创 为什么不建议学习华为的管理？？

华为是半军事化管理，这点就不适合知识型企业。知识型企业是很需要创新的。而军队里面，叫你左转你就得左转，叫你右转你就得右转。华为的成功不能代表它的管理水平就高，它只是吃到了市场红利，运气好罢了。事实上，很多华为员工都在骂华为，从这一点看得出来华为的管理水平并不高。一个管理水平高的公司，员工是把你当家，而不是当作敌人。学管理要向外企学习，比如惠普、微软、苹果、IBM。他们那才是以人为本。管理的本质就是人的运用。既然如此，就更应该贯彻以人为本的价值观。小红书和抖音上有个叫“高建华”的，可以多听听他的课。

原创 企业看不见的三个成本是最致命的

高建华，男，1961年出生于山东，原中国惠普公司助理总裁，首席知识官CKO，原苹果电脑公司中国市场总监。现任北京洋为中用管理咨询公司首席顾问。高建华先生擅长于营销战略、品牌建设、创新管理和企业可持续发展等领域。他的研究领域包括市场营销、品牌管理、企业战略、企业文化建设等，尤其在高科技企业的市场战略。企业看不见的三个成本是最致命的。

原创 提高成本，做好产品才能实现厚利经营

高建华，男，1961年出生于山东，原中国惠普公司助理总裁，首席知识官CKO，原苹果电脑公司中国市场总监。现任北京洋为中用管理咨询公司首席顾问。高建华先生擅长于营销战略、品牌建设、创新管理和企业可持续发展等领域。他的研究领域包括市场营销、品牌管理、企业战略、企业文化建设等，尤其在高科技企业的市场战略。提高成本，做好产品才能实现厚利经营。

原创 如何让你的产品上市就畅销，上市前一定要做好这一步

高建华，男，1961年出生于山东，原中国惠普公司助理总裁，首席知识官CKO，原苹果电脑公司中国市场总监。现任北京洋为中用管理咨询公司首席顾问。高建华先生擅长于营销战略、品牌建设、创新管理和企业可持续发展等领域。他的研究领域包括市场营销、品牌管理、企业战略、企业文化建设等，尤其在高科技企业的市场战略。如何让你的产品上市就畅销，上市前一定要做好这一步。

原创 如何做出像苹果一样的好产品，首先你得做到这一点

高建华，男，1961年出生于山东，原中国惠普公司助理总裁，首席知识官CKO，原苹果电脑公司中国市场总监。现任北京洋为中用管理咨询公司首席顾问。高建华先生擅长于营销战略、品牌建设、创新管理和企业可持续发展等领域。他的研究领域包括市场营销、品牌管理、企业战略、企业文化建设等，尤其在高科技企业的市场战略。如何做出像苹果一样的好产品，首先你得做到这一点。

原创 “1234法则”教你如何找到优秀人才

高建华，男，1961年出生于山东，原中国惠普公司助理总裁，首席知识官CKO，原苹果电脑公司中国市场总监。现任北京洋为中用管理咨询公司首席顾问。高建华先生擅长于营销战略、品牌建设、创新管理和企业可持续发展等领域。他的研究领域包括市场营销、品牌管理、企业战略、企业文化建设等，尤其在高科技企业的市场战略。“1234法则”教你如何找到优秀人才。

原创 原型的风险

即使是做一个简单的原型，也需要时间和资金。虽然原型可以降低软件项目失败的风险，但原型本身也有风险，在本节中，将解释其中的一部分风险。

原创 Enterprise Architect 的介绍

完美的企业级可视化解决方案，分析，建模，测试和维护您的所有系统，软件，流程和架构。Enterprise Architect是帮助您控制工作空间，支持同事的理想平台和团队，在最复杂的项目中实现协作并建立信心。记录想法、管理工作流程和审查组织结果设计需求、管理资源和分配可追溯性。

原创 为什么在需求开发阶段绘制界面原型可能会延长工期？

从上图两个方案对比可以看出，将并行开展的活动变为顺序开展，会延长项目的流程。

原创 为什么中国的创业公司平均寿命仅3年

工匠精神”其核心是：不仅仅是把工作当作赚钱的工具，而是树立一种对工作执着、对所做的事情和生产的产品精益求精、精雕细琢的精神。中小企业的平均寿命仅2.5年，集团企业的平均寿命仅 7～8年，与日本企业平均寿命相差十万八千里。全世界成立超过200年的公司，有56%位于日本，而日本企业的平均寿命是58年，那么日本为什么有那么多的百年企业呢？企业文化是企业的灵魂，新的市场需求是企业发展的方向和要走的路，从在各种不确定因素导致的困难中存活并且能够保持活力的日本企业中可以看出，所谓的匠人精神绝不只是坚持不懈这么简单。

原创 关于敏捷开发的一些的思考

敏捷开发对人的综合素养要求极高，有较高的智商和情商，有扎实的专业知识和丰富的的工作经验。绝大多数企业倾向于招聘年轻人，但是年轻人的知识和经验是很有限的，这就注定了敏捷开发失败的命运。对于用户故事中的一系列场景，敏捷只是做一些口头沟通或者在白板上潦潦草草的画画，并不要求形成正式且规范的文档。这样会形成“知识真空区”，即人员流失后，若你需要解决问题，你既没有文档也找不到合适的人员可以帮忙，从而使项目的进度搁置。传统开发是假设“人之初，性本恶”，而敏捷开发是假设“人之初，性本善”，即人是靠得住。

原创 本人曾经主导的一个产品

本人曾经主导的一个产品，产品功能规划和界面布局设计由本人完成（仅展示约15%的页面）

原创 一些自己绘制的图

几张自己绘制的UML图。全部来源于公司项目，使用建模工具 Enterprise Architect。自己做的其余文档（含绘图），因保密协议不便于公开。

原创 一个完整的可视化建模案例

来自真实的商业项目实战，使用Enterprise Architect、UML类图、活动图

原创 【自制PPT】笑着离开惠普

原创 【自制PPT】软件需求（第3版）

对需求工作不重视所产生的一些问题，例如用户对产品不满意、项目返工、延期交付、额外成本的投入、管理层失望、开发人员怨声载道、开发组织名誉受损 ......不断发生。大量的新企业、新项目劳神费力，投入大把时间，大把烧钱，上线后无人问津，因为需求是闭门造车得来的，共性：1、希望在上线的一刹那一举形成可行的商业模式。（不切实际的幻想）2、假设最初的想法是正确的。3、认为专家（权威人士）就在办公室里。4、上线之前，知道这个想法的客户数量为0。近十年，人们逐渐意识到，正确的需求愈发重要。成功的商业模式需要依靠对正确需求

原创 【自制PPT】功能医学概述

通过补充营养、激素等人体内原本就存在的物质，以及改变生活方式，如戒烟、限酒、运动、远离毒素等，达到预防疾病和治疗疾病的目的。两度获得诺贝尔奖的Linus Pauling博士，1968年创造了『Ortho-molecular』这个字，即『分子矫正营养学』。通常被称为“正分子医学”。他认为疾病可经由给予身体“正确的分子”，达到矫正失衡及去除症状的作用。中国最早的医学典籍《黄帝内经》指出：“上医治未病，中医治欲病，下医治已病”。上医：没有名气。中医：小有名气。下医：非常有名气。成本：越晚发现问题，修复的成本就越高

原创 【PPT】SonarQube代码质量管理

成千上万的自动化静态代码分析规则，从多个方面保护您的应用程序，指导您的团队。捕获棘手的bug，以防止未定义的行为影响最终用户。在整个开发周期中，始终把质量放在首位。Quality Gates（质量关口）会在每次分析时告诉您代码是否已准备好发布，给予清晰反馈，保证您提交的代码干净，维护您的声誉。修复危害应用程序的漏洞，并在此过程中通过安全热点（Security Hotspots）了解应用的安全情况。使用静态应用程序安全测试 (SAST) 在代码审查中检测安全问题，在开发早期就能获得反馈，并获得合理模式

原创 【PPT】善总结-工作亮点-建模工具辅助工作

Enterprise Architect（EA）。企业架构师；企业建筑师；企业规划师。快速直观的建模与设计——完美的企业级可视化解决方案，分析，建模，测试和维护您的所有系统，软件，流程和架构。是帮助您控制工作空间，支持同事的理想平台和团队，在最复杂的项目中实现协作并建立信心。打开您的企业以进行建模工作。适用于业务分析师，软件架构师，开发人员，项目经理，测试人员，推广人员和支持人员的单一存储库。 具有许多视点和许多可能的子系统的复杂系统的“统一”视图。 远程团队成员可以使用Enterprise Arch

原创 【PPT】可视化建模概述

软件建模是开发优秀软件的核心工作，其目的是把要设计的结构和系统的行为联系起来，并对系统的体系结构进行可视化和控制。可视化的建模使用一些图形符号进行建模，可视化建模可以捕捉用户的业务过程，可以作为很好的交流工具，可以管理系统的复杂性，可以定义软件的架构，还可以重用性。

原创 【原创】切勿迷信崇拜开源软件

要想把软件做好，必须要有良好的团队协作和充足的资金支持。而开源软件的团队成员极有可能是分散在各地的，在协作方面容易有一定的障碍。而资金方面，大部分的开源项目都得不到足够的资金支持甚至完全没有资金，导致项目进展缓慢甚至停滞。于是我的领导（CTO）就上GitHub找了个开源的OA系统。在使用的过程中，不断的发现了问题（BUG），例如 功能不完善、流程未闭环。其实你与其考察源码，倒不如考察一些设计思想或基础知识，毕竟阅读代码的效率是比较低的。那个讲课的人说，他们做了个文件共享工具，当然肯定是闭源的。