- 博客(223)
- 收藏
- 关注
RSS订阅原创 A14 问消费者想要什么没有意义
虽然已经做了大量消费者调查，取得了消费者的意向，但按此推出的产品或服务大多数以失败告终。因为我们错误地假定了消费者清楚自己想要什么。但是若让用户参与设计产品，便能发现他们希望在新产品或服务里有什么功能。如果有用户参与，产品或服务的设计就变得更有创意了。（例如，可以用于设计服装店，或设计飞机乘客舱里的座位安排。2012年，谷歌收购了摩托罗拉(Motorola)的移动电话部门。谷歌产品经理Johnathan被派去参加摩托罗拉被收购后的第一次产品会议，他发现摩托罗拉有非常多款的手机。
2025-06-03 17:17:02
637
原创 A13 行政 / 管理 / 领导
但如果管理者可以影响到大家，让大家发自内心同意这个方向的话，效果会更好，因为所有事情都难以单靠个人去完成的，如果只是按个人的想法、方式都是有局限，效果还不如整个团队的每个人都发挥自己的智慧，做出贡献，最终对公司的价值会更大。领导会带大带领大家希望去的方向，所以他们是自愿跟随领导，领导不是依赖权威权利，但经理是依赖指导和控制，不算是领导，只算是管理。让有能力的团队充分自主发挥是敏捷开发的核心思想，如果领导若要企业健康发展，必须依赖有能力的团队，自主发挥，而不是仅仅听上级的安排或按最高领导的个人想法。
2025-05-30 16:59:34
408
原创 A12 乐队指挥更懂管理
直到初二时，我加入了红十字会少年团后，才因为集体操练的原因，让我开始体会到协作与同步的意义。若某位乐手的水平不足，就会影响乐队的演出效果，指挥亦无能为力。后来，我加入了香港富士通，有机会到东京总部开会，感受到日本的管理文化非常强调员工之间的协作（可能因为是终身制，员工如家人般共事）。绝大部分乐手比指挥更清楚如何演奏自己的乐器，因此，只有愚蠢的指挥才会试图去教乐手如何演奏，这只会让双方尴尬。同理，如果管理者希望团队的协作和谐，就必须确立共同目标，并关注成员之间的互动，确保每位员工都可以获取其他成员的信息。
2025-05-16 14:07:07
255
原创 A11 难教老人新把戏
这就会导致企业停滞，甚至倒退，只有等到继任者上任后，才会有改进的希望。最顶层的人反而缺乏改革创新的动力，因为对他们来讲，变革是风险，成果也未必在他们任期内显现出来，所以他们不愿冒险。但总经理不同意，他说既然有免费工具，为何要用付费的呢。他们只是重复过去的做法，虽然嘴上说“都试过了，没用”，实际上根本就不想改变，因为这些变革的效果可能要到他们退休后才显现出来，对他们的声誉或退休待遇都毫无帮助。例如，我一位老同学在大学当老师，就常常抱怨校长缺乏创新改进的意愿，这直接影响学校的发展，对老师和学生都不好。
2025-05-09 12:26:30
393
原创 A10 如不能容错，大家都尽力少做
例如，成立于1999年的法国 埃本四重奏 (Quatuor Ebene) ，从2004年赢得ARD国际音乐比赛后，他们已经得过4次“留声机大奖”(Gramophone awards)，由于希望扩大他们演奏的范围，在2010年开始发版他们首张爵士乐唱片FICTION，2014年BRAZIL，他们都配合歌手、爵士鼓、低音提琴，2017年与单簧管手 Michel Portal 合作出唱片 Eternal Stories。没有变化反而比不断变化更危害企业的存亡，尤其是在不断变化的环境下，什么都不做，是极度危险的。
2025-05-09 12:21:52
636
原创 A9 引导学生自己找答案
他们会提出一些无解的疑问或未解决的问题，激励学员去探索，因为他们的目标是培养未来的领袖，而非盲从的信徒。反之，有些管理大师只给企业提供方案和答案，却不指出不足或提出问题，导致他的信徒们认为只有某些问题值得探讨，而且这些问题已有定论，其他的都不值一提。后来，我在培训中逐渐减少理论的讲解，把更多时间留给小组互动练习：抛出一个具体问题，只提供背景和数据，让小组讨论，45分钟后分享他们的分析过程与方案。否则，我只在旁边提醒时间，等他们讲完方案后，再分享可行的方案，与他们分析差异。
2025-04-11 16:53:40
425
原创 A7 应对未来变化，假设比预测好
A公司以IT系统集成类项目起家，随着市场竞争加剧，于2005年组建了软件开发团队，主攻政府项目。虽然政府每年有固定预算，但都是公开投标，利润薄，而且政府部门常常提出种种需求，如果管理不善，很容易会引起项目验收风险。若项目管理不善，如项目经理隐瞒问题，到最后爆发时才上报，就可能面临严重后果，如撤职。改革后，部门年年盈利，总收入持续增长，到2025年，部门总人数接近500人（2017年仅一百多人）。反之，若仅凭主管的主观打分，只会培养一群唯命是从的人，对个人和企业都毫无益处。
2025-04-11 16:53:31
386
原创 A6 服从度与创新
如果重看苹果公司1984年1月Macintosh个人电脑首次发布会视频，你会惊讶地发现：乔布斯拿出一片3.5英寸软盘（floppy disk），插入电脑，电脑便开始“开口”讲述自己的故事，展示各种新奇的游戏、办公应用和多种字体，用户第一次通过鼠标操作（相比之下，1981年IBM推出的IBM PC仍依赖键盘输入）。1975年，乔布斯刚从印度回国，回到游戏机公司Atari工作时，他光着脚，留长发，几天不洗澡，身上经常有异味，许多同事不愿与他共事。乔布斯希望团队保持反叛精神，他曾说宁做海盗，也不当正规海军。
2025-04-07 08:45:02
899
原创 A5 知识分显性和隐性
但是如果看到真人表演的时候，评判团虽然口里说是公平公正，受传统观点影响，心里都会觉得某些是男性的乐器（比如伸缩喇叭），必须由男性吹才得到预期效果。以前交响乐团的乐手都是男性，有些著名的传统乐队，比如著名的维也纳爱乐到1997年才打破155年传统，有首位女乐手加入。但如果你看近代的交响乐团，越来越多女性，不仅仅是在一些弦乐或木管乐器，不少乐团的铜管乐，如法国号、伸缩喇叭等的首席都有女性了。所以我们也需要隐性知识，如骑车、跑步、读书、写字，这些都是潜意识行为，不需要仔细思考也知道怎么做，但难以用文字说明。
2025-04-07 08:44:33
154
原创 A2 最佳学习方法
那个时候就要开始找参考书，准备实例和联系，准备和教学的过程中，就让我更了解里面的概念，比如挣值分析(Earned Value)，可以不用对着教材，直接在白板写出来给大家讲的地步，也能很顺利自然地解答学生的问题。2017年开始教敏捷ACP课，也同样做很多授课前准备，同时间也开始写分享文章，把教材 PPT 里的 知识点编成分享文章，放朋友圈，优快云和公众号等，覆盖更多人众，过程中又进一步理清敏捷、精益管理的道理，比如平常给人家讲课比较随意，但成文章就必须精简内容。现在回看，以上每一点都是学习，帮我更了解。
2025-03-24 15:33:07
707
原创 A1 PPT 投影
2005年，我第一次做PMP项目管理培训，只是按PPT的点读，再补充解释，当天立马收到学生投诉。所以现场讲解，我都会选择用白板与水笔，或黑板与粉笔， （如果有学员远程听课，我会打开空白excel表，用电脑笔边画边讲）。如果有准备PPT的话，我在讲完后，才打开PPT，只用来总结重点，不会按PPT逐条读。著名的18分种TED Talk演讲，都是以讲故事为主，有些会投少数几张能辅助学员更好了解故事内容的幻灯片，我听过几次精彩的TED Talk，纯讲，一个幻灯片都没有。
2025-03-21 15:07:35
445
原创 《A++ 敏捷开发》- 19 协作改进整个系统
“专注用户，从顾客的角度生产产品。”某次现场培训，我分享了丰田汽车故事后，请学员分组讨论，写出对工作最有帮助的3条。以上是某组的第一条，我请他们解释说明。“我是做开发的，反思时发现其实不清楚我的工作对客户有什么作用。”一位年轻的编码人员说。因为编码工作大部分都是由产品经理或项目经理过滤后分配，所以如果你随便问身边的编码人员，70-80%的可能不知道用户为什么要这样做，要开发的功能有什么价值。这位年轻编码人员的分享让我想到2年前某公司要推行需求与研发分离的故事。质量部经理：以前需求是研发团队的一部分，
2025-03-14 15:58:25
776
原创 《A++ 敏捷开发》- 18 软件需求
需求没有按价值过滤与分析，分优先级；没有全面考虑各种场景没有全面识别利益相关者没有明确描述非功能需求，并可验证用户故事卡需求评审需求分析：RDM 3.5, 3.6, 3.2 ( 场景 )干系人：PLAN 2.4, MC 2.2 ( 沟通的策划与监控 )非功能需求：RDM 2.2 ( 客户需求，包括功能与非功能需求 )需求卡片：RDM 2.2 , 2.4 ( 客户需求与活动或工作产物之间双向可追溯 ）需求评审：RDM 2.3。
2025-03-07 16:11:48
1322
原创 《A++ 敏捷开发》- 17 持续集成
为了避免客户验收前或使用后才暴露大量棘手缺陷，可能要花很长时间才能发现并解决，便应依据精益和系统工程的原则，把系统拆分成子系统/模块，先开发并测试子系统/模块、集成、再测试，按部就班地完成整个软件开发。
2025-02-28 10:24:38
1156
原创 《A++ 敏捷开发》- 16 评审与结对编程
提高代码质量和可读性（编码规范）提高代码复用加强测试驱动开发一边写代码一边说提问，如：这方法是否归为这个类每人带纸和笔（最好铅笔）不断想复用客户：我猜你说的3步是：第一步，高层认同软件质量问题的严重性，为此交过学费，知道损失多大第二步，管理层不仅了解软件的质量问题和改善措施，更需要内部立项做培训和投入资源（人力），做过程改进第三步才是具体的培训课。因为缺乏第一步和第二步，所以之前做完了结对编程培训后，没有效果我：厉害，完全对。
2025-02-21 20:16:01
1029
原创 《A++ 敏捷开发》- 20 从 AI 到最佳设计
虽然本部分分章节讨论需求、设计、编码、集成、评审、测试各过程的最佳实践，但若想改进应先设定总体目标，用多种视角看整个系统，再定各过程如何配合，好比建筑师按你的新花园别墅要求（如2层4房2厅，预算在一千万内）一样，必先做总体别墅设计，而不是先分别房间、客厅。
2025-02-19 15:10:26
811
原创 《A++ 敏捷开发》- 15 TDD与重构
从50年代起，软件系统越来越普遍，规模越来越大，越复杂。但延迟甚至失败的项目也越来越多。如果我们沿用系统工程的严格思维，是否可以像造一架飞机一样，写好大型的复杂软件？1968年，Dijkstra提出要structured programming方式编程，所有的程序都应该跟设计飞机一样，要先总体设计，然后一层一层分解下去，程序里不能随便用 GOTO 语句。七八十年代的软件开发几乎都是用这种思路去设计，但发现复杂项目还是经常失败或者严重延误。
2025-02-12 16:13:01
1226
原创 《A++ 敏捷开发》- 14 精益与敏捷
看完某研发部总监的缺陷分析报告后，我问：“你们什么时候做分析？总监：“产品发版后。”他们最近一次发版是八月份，立项早在三月份已经开始。我：“如果你们分析的目的是之后做改进，发版后才分析的作用不大。要想有真正的效果，就必须让开发团队每次2-4周迭代后一起做回顾分析。虽然总监说很赞同，但估计他心里想：“我们这几个月一直天天都很忙，中间怎么能腾出时间做回顾复盘！一条原则应能改变他的思路，从2013年起，这原则一直驱动我每天每月做规划。
2025-01-16 13:44:54
665
1
原创 利用工作坊促进持续改善
如果领导关注质量改进并支持，首先要估计改进能带来多少收益，估计能减少多少返工成本，减除投入的成本，包括人力资源、培训、辅导等，然后申请立项，才可以把改进当成正式项目来策划和监控。把所有关键利益相关者都拉到一起，用2到3天的工作坊培训，促进部门尽快制定改进目标和行动计划，挑选项目做试点，并预估何时可以取得效果，再大规模推广。因为大家第一次都没有经验，不知道如何入手，工作坊可以让所有人一起讨论和制定改进目标与计划。本来可能需要几个月来回讨论修正，现在只能压缩到2、3天。
2024-12-10 08:42:10
975
原创 《A++ 敏捷开发》- 7 策划与监控
自己可以首先使用刚才的原型法制定公司总体的过程改进计划（要注意刚才我举的例子只是改进小组的计划，并不是公司总体计划），并要求项目组针对改进目标下制定自己的改进项目计划，他们后面可以再使用APF的方法，针对软件开发项目制定计划和监控，后面便应可以回应开会时胡总要实时监控项目偏差的要求。
2024-11-28 16:33:23
799
原创 《A++ 敏捷开发》- 26 根与翼
今年被质量经理邀请参加他们的质量沙龙，但只有30分钟，我就用了TED演讲思路，用了17分钟讲软件开发公司的常见质量问题和改进措施。你觉得下面4种工作，哪一类工种占的工作量最多？编码与代码设计。交付后的所有工作，包括维护、更新与缺陷修正。交付前的评审、静态扫描、测试与缺陷修正。项目管理与监控。从2012年Capers Jones对美国软件公司的统计中看到，编码只排第二（占开发工作量的25%），测试与评审和缺陷修改的总工作量才是排第一（占30%）。
2024-09-14 16:06:37
1294
1
原创 《A++ 敏捷开发》- 13 从团队实验 到持续改善
反观世界级企业如丰田汽车，从二战后一直到现在不断持续改善，超越了原本的美国汽车巨头。“90年代，丰田汽车共8万员工，每年共用4百万条过程改进建议，平均每员工每年有50条。”Dr Juran 用以上例子什么是企业持续改善文化。也正是这种改善动力让丰田超越竞争对手，成为全球最大汽车公司。
2024-08-12 10:10:08
840
原创 《A++ 敏捷开发》- 12 软硬兼施
某次量化根因分析培训里，我跟各现场同学说：“前面我们说可以用鱼骨图分析根本原因，但我不建议在迭代回顾时用它找根因。知道是什么原因吗？请问你是读那所高校？当时是否自己选的？”“XX大学。当时是我自己挑选的。”“现在回想，是否觉得XX大学挺不错？ ”“是的。”“如果是自己选择的，都会觉得比其他好。1956年，Brehm 决策影响实验 （详见附件）验证了这心理。 所以如果用鱼骨图分析根因，大家都会觉得这只是组长的分析，并非我自己的想法，后面便没有动力执行。”前面第二章里的粮食分配实验也验证了团队只有兴趣执行自己
2024-08-08 08:02:51
737
原创 《A++ 敏捷开发》- 11 团队协作 分析根因
公司主要为全国不同的医院开发医疗行业的软件产品。六年前，公司规模还不到五百人；四年前，公司办公地点扩大了一倍，占地3000平方米，总人数也增加到接近900人。尽管公司骨干比较稳定，但新人的流动性很大。公司制定了很多量化指标，如需求一次性通过率、开发速度、测试缺陷密度等，并不断监控，但并未取得明显改善。技术总监问：“请教一个一直困扰我的问题——如何激励团队，让他们更有积极性？“现在你们员工的收入底薪和奖金的比例大概是多少？总监：“大概七成底薪，其他的就按每人每年的表现分发。“主要依赖主管的打分吗？
2024-07-24 09:20:12
1304
4
原创 《A++ 敏捷开发》- 10 二八原则
团队成员协作，利用项目数据，分析根本原因，制定纠正措施，并立马尝试，判断是否有效，是改善的“基本功”。10-12章会探索里面的注意事项，13章会看两家公司的实施情况和常见问题。如果已经获得高层支持，她也赞同目前返工工作量太多并愿意投入资源进行过程改进，我们首先应该针对哪些方面进行改进呢？软件开发的特点是，超过95%的成本都是人力成本。因此，我建议利用二八(20/80)原则，继续识别哪类工作的占比最高（详见附件）。
2024-07-11 10:21:50
1157
原创 《A++ 敏捷开发》- 25 创新：从个人到公司
创新，顾名思义，是指创造新的事物或提出与常规不同的见解。丰田汽车公司精益生产(JIT)的案例展示了丰田通过一线员工的智慧不断改善，最终实现了许多人最初认为不可思议的目标，如“零”缺陷和“零”库存。这使得丰田成为现代汽车生产的标杆。但这些改善都只属于解决问题（Problem Solving），而并非创新（即使团队迭代回顾时针对缺陷排除率分析根因也不能算是创新）。为什么有些公司和个人能够通过创新取得成功呢？接下来将首先回顾个人创新的要素，然后探索团队创新的方式和成功的关键要素。
2024-05-19 09:42:49
658
1
原创 公司如何制定年度目标
要工作坊有效，须要注意以下4点原则（例如第一点是必须所有相关人参与）：注意：老师的主要作用是辅导，所有要抛开传统的“老师教、学生学”的思路，尽量让大家自己投入和沟通。
2024-04-03 16:33:52
1404
原创 EV 挣值分析案例
软件开发项目最大的成本就是人工成本，但如果项目监控不足，最终很容易导致项目整体延期，成本超支。因为每个人都习惯了尽量等到最后一刻才完成提交，所以必须把任务分解到几人天的颗粒度并监控，才可以控制任务不延误。但如果只是做了项目任务分解，没有对应的监控，也不会有任何作用。如果只靠项目经理自己人工去监控每个活动的延期，并在里程碑做汇报，会很困难。
2024-03-20 09:26:20
1105
原创 《A++ 敏捷开发》- 9 寻找改进机会
发现培训反馈靠主观，只是靠老师主观打分，可以增加考试就可以满足不客观了发现有些课学生成绩及格率低，下一次同类外部培训要求学员备课，以提高学生的通过率只是采取这些行动，对公司级培训质量改进作用吗？几乎没有，因为只是对问题做correction,没有改变系统与习惯，类似问题还是会再出现。但如能深入探索根因，就发现原来新员工正式上课的培训不长，只有一天，大部分还是靠新员工在工作中，跟有经验“老”员工导师，老带新，边做边学。
2024-03-01 09:27:30
1003
原创 《A++ 敏捷开发》- 8 获取高层支持
我：对过程改进来说，最重要的成功要素是什么？客户：最难的是如何得到高层的支持，这不仅仅是嘴巴说说而已，而是要切实地给人、给时间。高层往往不清楚什么是质量改进的重点，但他们对员工的人均收入、利润（比如员工可为公司盈利的时间占比。如果少，就表示这个员工对公司的盈利贡献不够。）等这些财务指标都非常清楚。我：非常赞同。我们可以利用评估机会来引起高层对质量改进的重视，但往往评估组只说软件开发的各种问题，难以引起他们注意。一般人，尤其是高层，一听到问题都会觉得比较烦，没有动力听下去，更不要说有对应的改进行动了。
2024-02-13 13:28:49
1362
原创 《A++ 敏捷开发》- 7 估算工作量
这几年大数据很火，很多高科技公司都推相关的工具或者方案，很多软件开发项目经理觉得应该也用数据分析，分析历史数据，准确预估项目工作量、工期。但实际上，虽然预测模型已经有超过50年的历史，过千份研究报告、教材、指南，但使用在项目中不多。更多研究发现如果用专家估算可能更准确。以上是2009年IEEE杂志中的文章，Jorgensen先生的结论。
2024-02-05 09:23:50
1647
1
原创 《A++ 敏捷开发》- 6 估算软件规模
虽然简化功能点(SiFP)比传统国际功能点（IFPUG）简单易学，但开发人员还是容易用工程师的视角来估算（本应用用户的视角），导致计算错误。所以要多看案例并做练习，才能把握（能参加培训会更好）。它是做什么的？功能性需求技术需求质量需求第二类和第三类归为非功能性需求。功能点主要是针对功能性需求，目的是提供对客户有意义的功能点数，来客观地衡量软件规模。该如何去做？数据功能——实体 (逻辑文件 Logical File)事务功能——行为（基本过程 Elementary Process)
2024-01-28 19:45:35
1602
1
原创 《A++ 敏捷开发》- 5 量化管理从个人开始
PSP 的简单介绍PSP0基础 - 工时：计划与实际对比；每阶段引入多少缺陷；排除了多少缺陷PSP0.1加入代码行统计 - 计划与实际对比；代码规范PSP1加入使用 PROBE 方法 做规模估算PSP2加入设计与代码评审的计划与统计PSP3Cyclic process 先做策划与总体设计，然后多轮开发 ， 有点类似迭代开发。PSP跟CMMI成熟度模型类似，也是按部就班一步步，帮助软件工程师利用度量改进自我的开发过程。
2024-01-21 21:37:31
1095
1
原创 《A++ 敏捷开发》- 4 三点估算
估算是一个范围，不是一个数唐工：你估计完成开发用户登录模块要多少天？小李：3天。唐工：能在3天完成的可能性有多高？小李：可能性很高。唐工：可否量化一点?小李：可能性为50%~60%。唐工：所以很有可能不止3天，要4天了。小李：对的，其实也有可能要56天，但我估计概率不大。唐工：你信心有多少？小李：难说，有95%的信心可以在6天之内完成。唐工：所以有可能要用上7天了？小李：这样说吧，如果所有可能出问题的都出了问题，甚至会10天或11。
2024-01-16 21:25:27
1119
原创 《A++ 敏捷开发》- 3 克服拖延症
技术总监问：现在我遇到最大的难题就是如何提升下面技术人员的能力，如果他们全都是高手，我就很轻松了，但实际上高手最多只有 1/3，其他都是中低水平。你接触过这么多软件开发团队，有什么好方案？我：你可以先听听以下故事。小李：你平常办公时间一直都很忙，还可以腾出晚上和周末时间，把客户遇到的问题，如何解决等，汇总成分享文章，每两周公众号发布，很厉害呀。我：其实你也可以做到。要成为专业软件工程师，除了要学习软件工程相关的知识与技能外，个人有没有高效率的习惯其实更重要。
2024-01-09 20:26:42
1001
原创 《A++ 敏捷开发》-2 改进从团队开始
上一章介绍了丰田方式水面下的七个习惯，但公司应如何有效开展与推行？有哪些误区要注意？我们先看美国东岸某家小印刷公司的故事。
2023-12-30 09:42:42
989
原创 《A++ 敏捷开发》-1 如何改善
既然SCRUM方法有不足，XP方法能解决开发质量问题，是否团队学好XP便能帮助团队做好敏捷开发？ 怎样才能不断完善？
2023-12-21 09:46:11
1224
1
原创 A++ 敏捷开发-1 如何改善
A公司一直专门为某电信公司提供针对客服、线上播放等服务服务。张工是公司的中层管理者，管理好几个开发团队，有5位项目经理向他汇报。他听说老同学的团队都开始用敏捷开发，很感兴趣，便参加了几次敏捷交流会，觉得可以解决很多开发团队的问题，尤其是可以快速交付给客户。他便提建议给部门经理推动敏捷开发，找咨询公司做相关培训，例如SCRUM Master 内部培训，然后全面开展实施。开始时，部门经理有些怀疑，问：“听起来很吸引，但后面那些工程文档都不做，会不会影响质量和交付？
2023-12-01 14:16:43
1369
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人