23 | 考虑限制，让自己的产品不入险地
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文讨论了在项目管理中如何通过考虑限制来避免产品陷入风险，强调了“认知到位 + 彪悍执行 = 成功交付”的公式。作者指出，在架构设计和个人成长等方面都需要系统化地理解和实践限制。通过对限制的理解和实践，可以确保产品不陷入风险，避免无法交付的情况发生。文章还详细介绍了业务限制和技术限制的各种因素，以及如何在产品设计和落地过程中考虑这些限制，从而确保产品的成功交付。同时，文章还探讨了向上管理的“限制”问题，强调了具备全局思维、专业性和表达能力的重要性。最后，文章强调了限制对企业发展的重要性，指出限制意味着在企业发展的某个阶段，选择放弃某类用户，从而聚焦当下，学会取舍，持续进步、持续改进。
《乔新亮的 CTO 成长复盘》，新⼈⾸单¥59
全部留言(17)
- 最新
- 精选
spark我一般能用计划的30%时间完成我负责的任务，其他时间要么没事干、要么项目的代码都是我在Review，其他兄弟们加班累死累活、延迟交付且质量不高。 我做事的方法： 1.向领导学习(让领导替我想想办法如何完成的快和好)：做事前对齐目标，路径。和领导沟通如何更快完成任务，领导的效能至少比我高3倍5倍。这样就算最后完不成，领导也不能说我偷懒和能力问题，我预先把风险和问题和领导沟通清楚了。 2.做事需要经过专业人士的训练才行，训练前后差距可以是10倍的效能。 我一直从CEO角色角度看待我的工作的价值。手里写着代码，脑里思考着业务如何成功，企业如何存活和发展。作者回复: 你好，spark 你太棒了，真的很棒，领导应该提拔你才对。
2020-12-16327
流浪地球请教乔老师一个问题，文中提到了项目经理在一个项目成败中的重要性，自己感同身受，有个问题是项目经理在一个团队中的职权范围应该是怎样的，或者更直接的说地位应该摆在什么高度。经历过的2个团队 1、pm职权范围极大，在制作人一人之下，对整个团队成员有考核权。但问题是这个角色本身的技术专业度不够深，和技术leader，产品leader很容易产生摩擦，团队成员往往更愿意听命于自己的专业线leader，觉得pm瞎指挥，就是个监工。 2、pm权职范围有限，仅做排期沟通的相关工作，没有考核权，这样他们的威信很低，往往指挥不动人。 这个问题该如何解决比较好，难道一个好的pm一定是一个优秀的产品专家和技术专家吗？谢谢作者回复: 你好，流浪地球 实际是靠团队。 在项目启动中，一个项目要明确PM-项目经理，PM-产品经理，架构师，专才，项目启动就是明确各自职责。 从公司层级，项目启动的时候，项目所有人要听PM的安排，PM要充分发挥以上四种角色的专业，一起制定项目的WBS。 所以权力在项目启动的时候赋予了项目经理，项目启动会其中一个最重要的目的是赋予项目经理权力，否则那不是项目经理，而是项目助理。
2020-12-176
Weehua我作为技术管理者，感受最大的就是项目排期，总是和业务方或者老板博弈。如果坚持自己原定的排期，有些重要需求确实对业务来说很重要（比如双11或双12搞活动），这个时候只能压缩排期，只能加班了，但确实有些需求不符合客观规律，或者如果按时交付但质量不行也经常出现，最后会损害团队声誉，有时候也是各方逼迫的。 我学习之后的感受： 1. 要在专业的方面说出各种限制，提出风险，在全局思维给出合理的建议，和业务一起想办法解决问题，如果只考虑技术而不考虑业务，是不负责任的。让自己变得专业，别人才能相信你。 2. 有时候做业务限制是非常有效的手段，可以在技术架构和实现方面节省很多，比如：业务想查询一个数据报表，大部分情况查询三个月的数据足够了，限制查询时间可以大大提高用户的体验（特别是涉及到精确排重，数据量大的时候），对于大范围的时间查询可以离线或异步进行。作者回复: 你好，Weehua 从业务发展出发，和业务一起讨论共赢方案。考虑限制，和业务讨论限制，是对业务更负责任的态度，相信时间会证明自己，业务会理解，双方的信任也会越来越强。
2020-12-185
子夜枯灯老乔讲的内容干活满满。化为己用，会是听完课程优先需要考虑怎么落地首要问题。作者回复: 你好，子夜枯灯 谢谢，学以致用很重要，都掏钱学习了，一定要用起来
2020-12-162
术子米德🤔☕️🤔☕️🤔 有一种限制，也很致命，那就是大家对于项目本身可能遇到的问题的认识，这个认识本身就是一个关键约束 如果遇不到啥大问题，大概率这个项目本身比较平庸；如果这个项目有挑战，那么很多问题就是在项目开展过程里，才会遇到、才开始真正处理到挑战点。这时候往往出现认知不一致的矛盾。 如果大家都认可，这是项目调整引起的问题，由此而导致项目延期，甚至无法继续，那已经是认知很对齐，也是理想情况。 更多时候，大概率的PM会越来越盯紧架构师，直到最终说出来，作为架构师为啥没考虑到这些约束呢？ 好了，此时所谓的约束，甚至有点埋怨，又有点甩锅性质的约束，实际上就是刚开始认知不一致的约束埋下的种子。作者回复: 你好，术子米德 你提的这个问题的解决，要在管理三板斧的目标对齐解决，如果目标对不起，专业复盘中提的问题都没有根。 专业会变成出现问题时扯皮的资本，根基不稳，一切都没了基础，这也是专栏组织的一个考虑点。
2020-12-201
glutton乔老师讲的，总能让我有通透的感觉 放在个人成长上，"知不可为"(考虑限制)可能比"知可为"更重要。之前一直忽略了这点。 又值得反复读的一课，感谢乔老师持续输出高质量干货。作者回复: 你好，glutton 谢谢，感谢你的陪伴
2020-12-161- 张浩要深刻理解时间、资源、范围这个铁三角，在限制内做到最好，谢谢乔老师分享。
作者回复: 你好， 张浩 聚焦，舍弃，人生必修课
2021-07-22 
罗小黑这一课讲到痛点了。我想IT人几乎都有“疯狂赶进度”的经历吧~ 从业务和技术两方面入手，寻找解决办法，有被启发到。感谢老乔作者回复: 你好，罗小黑 加油加油
2021-07-01
小白条项目管理的本质是消除不确定性；项目管理不是为了管，而是为了不管。作者回复: 你好，小白条 你get到了要点。
2021-06-25
leslie"交付的领导视角"：这个可能是大多数初中级管理者在早期不会去思考的事情，中层其实就是向上理解向下梳理。作者回复: 你好，leslie 总结的好。
2021-03-07
