#项目管理

𝗖𝘆𝗱𝗶𝗮𝗿

1周前

最近在和很多企业深度对话中，如果想达到目标，我们深刻发现 DRI（Directly Responsible Individual）直接责任人，这个角色的重要性，该角色最终对项目成功或失败负责的那一个人。他们是状态更新、决策制定和克服阻碍的核心成员。这个概念起源并在科技界获得了突出地位，特别是在史蒂夫·乔布斯领导下的苹果公司，它成为了他们组织结构的基本组成部分。正如《福布斯》所述："在苹果，对于谁负责什么从来不会有任何混淆。内部苹果用语甚至有一个专门的名称，即'DRI'，或直接责任人" DRI最终对项目的成功（或失败）负责 ○ 无论团队规模或复杂性如何，他们都拥有最终结果 ○ 当事情陷入困境时，他们负责推动进展 ○ 当事情陷入困境时，他们负责推动进展供答案 DRI角色的一个关键方面是决策制定权力。 DRI不必解释他们为什么做出决定，他们绝对不必说服其他人。这赋予他们权力来： ○ 对项目方向做出最终决定 ○ 打破分析瘫痪 ○ 在不需要过度共识建设的情况下推进倡议有效的DRI应该具备这些8个关键特征： ○ 注重细节 - 同时不失去战略视角 ○ 在压力下保持冷静 - 在实施和截止日期期间 ○ 强大的倾听技能 - 具有出色的提问能力 ○ 适应性强 - 能够巧妙地调整项目方向朝着目标 ○ 主动性 - 善于预见和早期解决问题 ○ 多才多艺的沟通者 - 能够在所有组织层级有效互动 ○ 有韧性 - 能够从挫折中恢复 ○ 一致性 - 对类似情况的响应可靠写在最后，这也是困局，很多人和我说的很直接，想干，但是不能干，本来应该是「砖」最后变成了「枪」这也是现状！

#DRI #直接责任人 #项目管理 #决策 #责任

Frank Wang 玉伯

1周前

Yesterday, while trying out Notion 3.0, I found myself quickly losing interest. 昨天试用 Notion 3.0 过程中，越用越无趣。 Take connecting Linear into Notion as an example. We’ve only been using Linear for less than a year, yet the connection estimate was over 30 hours. The time wasn’t the real problem—what struck me was how the whole process suddenly killed any motivation I had to continue. 比如同步 Linear 到 Notion 中，我们用 Linear 还不到一年，提示要 30+ 小时。这个时间还是其次，更重要的是，尝试过程中，突然没了欲念。 When it comes to project management, Notion is like a spear, while Linear is a machine gun. There’s no point in forcing a machine gun to behave like a spear. 在项目管理这块，Notion 是把长矛，Linear 是架机关枪。没必要把机关枪同步成长矛。 Notion’s real genius lies in its abstraction of Blocks and Bases. Blocks come together to form Pages, and Pages can be assembled into SaaS-like experiences (though not fully realized). Notion 的厉害之处，是 Block 化和 Base 化的产品抽象。由各种 Block 组装成了一个个 Page，再由多个 Page 组装成一个个 SaaS（未达成）。 But this strength might also be its biggest weakness. A Page built from Blocks and Bases will never truly become a Calendar, Mail, Slack, or Linear. To get there, Notion would have to acquire or rebuild those applications entirely. Notion 的厉害之处，可能也就是 Notion 最大的傲慢之处。由 Block + Base 组装成的 Page，成为不了 Calendar、Mail、Slack、Linear 等垂类应用。这类应用，还是得收购或重新构建。 At the end of the day, Notion is still a document collaboration tool. Notion 的底盘，依旧只是文档协作。 What’s interesting is that in the age of AI, documents are starting to find more natural homes. Product design docs, for example, can now live directly in Cursor inside the codebase. Project collaboration docs can sit in Linear itself—a long issue is essentially a document. 有意思的是，AI 时代，让各种文档开始有了更好的归属。比如产品设计文档，经常可以直接用 Cursor 写在代码仓库里。项目协作文档，则可以直接写在 Linear 里（长一点的 issue 就是文档）。 In this new era, Notion’s foundation isn’t getting stronger—it’s actually getting thinner. Documents that don’t need collaboration now have better places to go. What’s left in Notion are only the documents that still require collaboration. AI 时代，Notion 的底盘没有变厚，而是变薄了。不需要协作的文档，有更好的地方去写。Notion 里剩下的，是需要协作的文档。 And looking further ahead: if people increasingly collaborate with AI instead of other people, even Notion’s collaboration layer could be shaken. 进一步的可能是，如果人越来越不需要与人协作，而是与各种AI协作，那么，Notion 的协作底盘都会被动摇。 The next generation of Office might not have “documents” at all. 全新一代的 Office 里，可能就没有文档。

#Notion 3.0 #Linear #项目管理 #AI时代 #文档协作

2周前

昨天看纯银的产品 newsletter 里面一句话，感同身受： AI Coding 带来了一个项目管理的新问题：把项目风险后置了。

#AI Coding #项目管理 #风险后置 #纯银newsletter

在悉尼和稀泥

1个月前

Claude Code 使用技巧 7/n 如何在大型项目里面做 vibe coding？答案是「敏捷开发」。在现代的软件开发流程里，团队之间还会共享合作方式，例如代码规范，团队合约等。因为只要是大型商业项目，就一定会有团队，有团队就有团队合作，有团队合作就有团队规范。现在有了 AI，即使你不需要队友，你的 AI 们也是队友，尤其是当你在使用多个模型，多个对话的时候，需要对 AI 之间，AI 和自己之间有一些团队合作的规范定义。就好像你在公司做大项目的时候，团队直接会约定各种 Way of Working 规范一样。例如：定义“代码质量规范”，任务的“完成标准”，“测试规范”，“文档规范”，“提交规则”，代码仓库的“分支规则”等等。

AI编程工具激战：Claude Code、Gemini Cli崛起· 900 条信息

#Claude Code #敏捷开发 #AI 团队合作 #代码规范 #项目管理

1个月前

#每日推荐开源任务管理系统 DooTask是一款开源在线项目任务管理工具，提供各类文档协作工具、在线思维导图、在线流程图、项目管理、任务分发、即时IM，文件管理等工具；同时消息功能使用非对称加密技术让你的沟通更安全。

#开源 #任务管理 #DooTask #项目管理 #在线工具

1个月前

好家伙，Codex 这种级别的项目还带发了 tag 以后删了重打的，都没个规范吗。。

#Codex #项目管理 #技术项目 #质量控制 #内部规范

1个月前

当一个大型项目里，有一部分人先开始了 vibe coding，每个 PR 都会改动几十个文件，完全无法 review……我尝试用 Claude Code review，但感觉也不靠谱。在无法禁止这些同事继续 vibe coding 的情况下，怎么最大减少副作用呢？如何保证项目的稳定性和可靠性？

#Vibe Coding #代码审查 #项目管理 #代码质量 #团队协作

1个月前

刚刚回访#千里会兄弟，有兄弟光靠我们的AI 代写项目，每月已经稳稳进账好几千，却一点都不声张——低调得让我都替你们骄傲。但兄弟们，赚钱归赚钱，身体才是最贵的硬通货。白天本职工作加班到凌晨，夜里还要赶急单，保命要紧给大家三个小建议：遇到特别赶的单子，别硬扛——把需求分给群里伙伴一起做，自己收一点项目管理提成，既减压，又能让收益在圈子里流动。每周给自己留一晚“空窗期”，彻底离开电脑，让身体和大脑都有复位的时间。把你的战绩和踩坑心得大胆分享到千里会，大家一起复盘、一起升级，比闷头独行省力多了。有单一起接，有钱一起赚，有坑一起填；卷的是效率，不是生命线。身体稳了，项目才能卷得更久、更高、更稳。

#AI代写 #赚钱 #身体 #项目管理 #经验分享

1个月前

🤪 meepo 今年有2w多的外包款项没有收回来，所以不建议开发者轻易接外包，发下 meepo 的经验，注意避坑: 1️⃣ 报价一定要合理，不能客户随便一个低价就把自己卖了，如果客户前期报价低，那么后期迭代+维护，可能会更低，而且你要做好最后交付之后，尾款不结算的心理预期，不要在客户心中种下你很廉价的种子。 2️⃣ 一定要让客户预付款，我一般是 20% ~ 30%，到账了再开工，中间定几个交付节点，每交付一部分功能，让客户验收付款之后，再进行下一部分的开发。 3️⃣ 功能一定要清晰明确，并发给用户确认，写详细一点，别嫌麻烦，开线上会议时，记得顺手录屏，我曾经因为这块弄的粗糙，反复跟用户 battle，因为客户不懂开发，所以中间肯定会存在很多理解偏差。 4️⃣ 在开发功能前，先找一下有没有适合的模板或者开源项目，从零搭建去开发，是万不得已的事情，往往意味着利润更低，开发周期更长，平时要记得去收集一些符合技术栈的好的模板或者开源项目。 5️⃣ 注意培养长期合作的其他人员，不管是前后端开发，还是 UI 设计，那些平时老是嚷嚷着说"带带弟弟"的人，真的等到项目下来，你会发现他们啥也干不了，平时肯定要积累自己合作的稳定 team，毕竟你不可能什么开发语言都会，一个人可以走的更快，但是一群人可以走的更远。而对于复杂点的项目，我会专门找个测试人员跟进，毕竟开发自己自测，会浪费不少时间，控制 bug 率，是减少客户爆炸的最直接的影响因子。 6️⃣ 建立与客户之间的长期信任关系，报价，交付质量，这些东西，如果长期不合理，那么肯定会导致项目嗝屁，或者后续没法继续合作，不要想着今天坑了，明天亏了，长期可控即可。 7️⃣ 不要什么项目都做，什么都做，意味着什么都不精，那么长期搞下来，又累又没有积累。meepo 现在专注 web 全栈开发，出海业务，AI 套壳，react + nodejs + ts 的生态，一个人即可完整整个项目的开发。

#外包避坑 #Meepo经验 #项目管理 #Web全栈开发 #客户关系

1个月前

以前大家总是在质疑program manager的作用，现在项目管理反而才是最重要、最值钱的技能之一。不管是做ai最前沿的研究、工程技术实现，还是用好已有的ai产品。比如，实现一个Claude Code和用好一个Claude Code都需要很好的项目管理能力，清晰准确描述需求、做好定义清晰计划、keep on track执行。

AI编程工具激战：Claude Code、Gemini Cli崛起· 900 条信息

#项目管理 #AI #技能 #需求 #执行

1个月前

从下午朋友抛了个需求，回家吃完饭，2小时内完成全流程开发、部署、上线。这个时代不是不能慢，而是得知道：什么时候该快。 AI 工具 + 熟练流程 + 强执行力，才是普通人打赢项目战的关键。不卷流程，只卷上线。

#AI工具 #效率 #快速上线 #项目管理 #执行力

独立开发者｜欧维Ove

2个月前

独立开发前线周刊第5期：用更长的时间去看待你的项目

#独立开发 #前线周刊 #项目管理 #时间管理

2个月前

kiro 的口碑很好，毕竟是亚马逊科班出品，流程控制非常好，像擅长项目管理的技术经理。而且还有免费的 claude 4可以用。

#kiro #亚马逊 #Claude 4 #项目管理

3个月前

这玩意儿对我这种手上有一大堆特别简单的项目的人来说，实在是太友好了...多线程搬砖简直不要太美...

#多线程 #项目管理 #效率

王短鸟 (长鸟版)(Ø,G) 🔆

3个月前

小学时候觉得非常傻逼的《皇帝的新装》的故事就是现在大家嘴撸的各个项目的场面😂

#皇帝的新装 #项目管理 #幽默解读

3个月前

维护了 10 年的 JS 项目，还能发现 bug 🐞，真是个无底洞啊…… 👉

#JavaScript #bug #项目管理 #程序员生活 #软件维护 #技术债务

3个月前

个人项目一定不要一上来就什么微服务架构。以前闲着没事，开发了很多基础服务，比如用户系统、通知系统、评论系统整了一大坨，想着以后上新业务就复用不要写这些逻辑，而实际上，很多项目用不上，接入这些服务的寥寥可数，而且代码变得割裂，有时候有人想买源码，都没法直接出售

#项目管理 #微服务架构 #软件开发 #源码出售 #系统集成

3个月前

项目只要大起来了，管理依赖就是很头疼的问题，更新一下依赖就跟捅了马蜂窝一样，一堆报错排查大半天😑

#项目管理 #依赖管理 #报错排查 #项目维护 #技术管理

3个月前

我今天看了AI同事的code非常驚人！他的PR放在那邊很久沒人幫他merge，我打開看裡面有170個檔案！他明明是開發 backend 卻還有 frontend code，甚至還有spec 沒有定義的功能🫠我直接問他本人，為什麼要加這個「AI要我加的」我猜他很快會被踢出project 😑

#AI同事代码 #合并请求 #开发团队 #后端开发 #前端代码 #未定义功能 #代码审查 #项目管理

3个月前

重来Rework是Basecamp两位创始人写的书。Basecamp是一款非常流行的基于云服务的项目管理软件，以简单易用和颠覆性的创新而出名。这本书也像Basecamp一样，追求简单的成功路径。印象最深的是要尽量做减法，专注一件事情，这样很难有人跟你在你专注的领域中竞争。链接：

#重来Rework #Basecamp #云服务 #项目管理 #创新 #简化 #竞争

3个月前

建议用AI编程一两天后，停下来手动整理一下项目，代码结构和文档等等，确保你能掌控全局。因为AI仅会根据它所掌握的部分信息，而非你的系统全局来做出判断并输出。所以很容易造成同一定义或者同一个功能实现多遍的情况。AI还经常因为思路变化而大幅度修改现有可用代码。这都需要人来掌控。

#AI编程 #手动整理 #项目管理 #代码结构 #文档编写

3个月前

没有做不起来的项目，只有迈不开腿的人。任何赛道都藏着金矿，区别只在于，你是站在岸边观望，还是直接跳下去挖宝。

#项目管理 #创业 #机遇 #投资 #个人成长 #行动力

3个月前

看到 $labubu ， $bob 再次深刻明白了一点：没有庄的能力就不要抢庄的筹码你要么做顺风车，要么整个项目都给你🤣

#投资策略 #市场博弈 #项目管理 #风险控制 #深刻反思

3个月前

Trello 的开源平替: kan 一个功能强大、灵活好用的项目管理看板应用，能帮你把工作安排得井井有条，随时掌握进展。 👁️ 看板可见性: 权限管理 🤝 工作区成员: 团队协作 🚀 Trello 导入 🔍 标签与筛选: 快速查找 💬 评论: 团队沟通 📝 活动日志: 追踪变更 Github

#Trello #开源替代 #项目管理 #看板 #团队协作 #权限管理 #Trello导入 #评论功能 #活动日志 #GitHub

3个月前

AI 编程越来越厉害了，我要怎么提升自己的系统架构能力？现在 AI 写代码真的是越来越厉害了，一些小的模块让 AI 写，又快又好。慢慢的，对程序员写代码的能力要求会降低，但是对系统架构能力反而会要求更高。而且这部分能力不会轻易被 AI 取代，因为 AI 还不能像人类一样看到一个复杂项目的全貌，无法完整理解项目的业务上下文和约束条件，所以需要人去把任务拆分，一次只执行一个小任务。那么问题来了，新人要怎么才能提升系统设计能力呢？作为一个过来人，我觉得提升系统设计能力这事，可能有没有 AI 都差不多，都离不开多看、多练和多复盘。AI 的好处就是可以更方便地帮你查资料，以及更容易地理解项目，但它不能代替你去动手实践。什么是系统设计？在讨论如何提升系统架构能力之前，需要先搞清楚：什么是系统设计？想想看，如果你做一个简单的网页，或者一个小脚本，需要系统架构吗？基本上是不需要的，因为足够简单，有没有架构都能写出来。那如果是要做一个 ChatGPT 这样的应用呢？那是一定要有很好的系统设计的，因为太复杂了！而且一个人也是做不出来的，需要很多人甚至很多团队协作才能完成。但即使是 ChatGPT 这么复杂的系统，在开发团队工作的每一个人，工作职责并没有非常复杂。比如有的人只负责实现模型的 API 封装、部署，有的人只负责 Canvas 这样的文本编辑组件，有的人只做 iOS 客户端上的某个功能。一个复杂的系统，通过系统设计，把复杂系统层层分拆，变成了一个个小的模块，最终这些模块组合在一起就可以运行起来，让用户可以稳定地使用 ChatGPT 的服务。所以系统设计，就是把一个复杂的系统拆解成容易理解、容易实现、容易维护的小模块，再清晰地定义好这些模块之间如何相互协作、相互沟通的过程。通俗点讲，就好像你盖一栋大楼，系统设计就是设计图纸。图纸上详细说明了楼的结构，比如地基、钢筋框架、墙体、管道和电线，明确告诉施工人员每一部分怎么盖，哪些部分先盖，哪些后盖，哪些部件之间是如何连接起来的。如何做系统设计？系统设计这件事看起来很神秘，系统架构师似乎都是传奇般的存在，但做系统设计这事也没你想的那么复杂，因为绝大部分系统设计都有成熟的方案可以参考。作为架构师，可以灵活应用成熟的架构模式，一般是不需要去发明新的架构模式的。但系统设计也没有那么容易，否则人人都是架构师了。系统设计难在哪呢？ • 要充分理解需求和团队：我把理解需求和团队放在了第一位，因为系统设计是为需求服务的，你不理解需求做出来的设计那可能都是错的；同时系统设计要和组织架构匹配，毕竟你的系统设计出来，还是需要团队去实施的。如果你就两三个人整几百个微服务显然是有问题的，反过来你几百个人的团队还是单体应用也可能是有问题的。 • 要面对不确定性：系统设计不像写代码是一个确定性很强的事，代码模块的输入和输出都是固定的，只要去实现算法就好了。但是系统设计面对的是不确定性：需求不确定、未来的发展不确定、技术选型的影响不确定。你需要在这种不确定中做出相对稳健的决策。 • 要权衡取舍：在系统设计中，几乎不可能有绝对完美的方案，通常都是在多个选项之间权衡。例如要兼顾性能和成本、扩展性和开发复杂度、安全性和用户体验等等。这就要求设计者能做出合理的决策，并理解每个选择背后的得失。举个例子，选择微服务架构可能带来更好的扩展性，但也会增加运维复杂度和网络开销。 • 要沟通说服：系统架构不仅仅是给自己看的，更重要的是要让团队的所有成员都理解你的设计，甚至是非技术人员也能大致明白整体结构。这需要架构师具备良好的文档编写和表达能力，用清晰的语言、图表、流程来传递设计意图。不仅如此，在做系统设计时，并不是你做个设计别人就能认同的，你需要去说服别人认同你的设计，有时候也必须做出一些妥协。当然到了 AI 时代，有些地方还是有些改善的。比如你资源不够就可以用 AI 凑，不善于表达就让 AI 帮你写原型写文档，不知道如何取舍就用 AI 分别实现一套 POC（概念验证），再对比看效果。新人如何提升系统设计能力？系统设计并没有快速通道，更多的是长期积累的过程，这个时间通常是以年计的。总结下来关键是三点："多看"、"多练"和"多复盘"。 "多看"：积累架构模式就是学习经典的架构案例，知道有哪些架构设计的方法。网上有很多系统设计面试题和分析，都是很好的学习素材。另外还可以看开源项目，看看复杂的开源项目是怎么运行的，多关注： • 这些系统是如何拆分功能模块的？ • 模块之间又是如何通信的？ • 为什么他们选择了某种特定的技术或架构方案？ • 在实际中遇到了哪些挑战，又是如何解决的？比如微博是怎么 8 明星并发出轨的？推荐一些学习资源： • System Design Interview Alex Xu 写的这本系统架构设计面试书，系统地介绍了常见的架构模式 • High Scalability 网站，收录了大量真实系统的架构案例 highscalability[.]com • 开源项目如 Kubernetes、Kafka、Elasticsearch 的架构文档 "多练"：从模仿到创新除了理论学习，更重要的是主动去练习。系统设计这种事，哪怕你像 AI 一样训练了所有公开的系统设计方案，但你不试试仍然不会知道它们在不同的应用场景下的优缺点是什么。就像微服务从来不是个技术问题，而是一个和组织架构相关的问题。新人的话，最好是从模仿开始，先照葫芦画瓢，然后再去按照自己的思路去改进。一些你可以练习的方式： 1. 架构还原练习：选择一个你熟悉的系统或产品，试着去拆分架构，画出架构图；写下每个模块的功能定义，明确模块之间如何通信；再去找懂这个系统的人请教对比。 2. 对比学习：去看看类似功能的开源系统，看设计方案有什么不同，各自的优缺点是什么。比如对比 Redis 和 Memcached 的架构差异。 3. 设计先行：在做一个相对复杂的功能时，先去做一下设计再开始写代码。哪怕是个人项目，也要画架构图、写设计文档。 4. AI 辅助验证：尽可能把要实现的模块，用自然语言描述清楚，让 AI（推荐 Claude、Gemini、DeepSeek 等模型）去实现，看结果和你期望的差距在哪里。如果不是你想要的，去反复调整你的描述或者继续分拆，直到 AI 能实现你想要的效果。这个过程其实是在训练你的模块化思维。 5. 重构现有系统：去重构现有系统，在稳定性、代码重用、性能这些方面去改进。重构的过程会让你深刻理解原有设计的问题。 6. Side Project 实战：去做 side project，先尝试基于开源项目二次开发，再尝试从头搭建一套相对复杂一点的系统。比如做一个简化版的分布式消息队列、一个迷你版的容器编排系统。只有在真实项目中踩坑、解决问题，你才真正能理解系统设计中各种取舍的意义。 "多复盘"：从经验中提炼智慧每次做完项目或者完成一段设计后，都要回顾总结一下过程： • 当初做决策的依据是什么？这些决策后来验证效果如何？ • 如果再做一次，哪些地方会做不同的选择？ • 遇到的困难和挑战是什么？分别是如何克服的？ • 是不是有更好的技术或架构选择当时被忽略了？ • 团队成员的反馈如何？他们是否理解并接受了你的设计？如果不接受，原因是什么？复盘是让你从具体实践中提炼出通用方法论的重要环节。只有反复总结和不断优化，你的系统设计能力才能逐渐提高。 AI 时代更要用好 AI 帮你提升系统设计水平在学习系统设计的过程中，AI 虽然无法替代你完整地设计架构，但可以成为你提升能力的重要工具，助你快速成长： • 快速查资料与案例：让 AI 帮你迅速搜集和整理系统设计的案例与最佳实践，大大节省学习成本。比如你可以问 AI："给我解释一下 Circuit Breaker 模式在微服务中的应用场景"。 • 辅助实践：你可以把自己设计的模块先让 AI 尝试实现，以检验你的设计思路是否清晰合理，从反馈中不断优化设计。这就像有了一个永远在线的结对编程伙伴。 • 辅助沟通：你可以先把复杂的设计和思路告诉 AI，由 AI 帮助你简化表达，生成易于团队沟通和理解的文档。甚至可以让 AI 帮你生成架构图的描述文本。 • 辅助决策：当你在不同架构方案间犹豫时，让 AI 帮你分析每种方案的优劣势和适用场景，帮助你快速做出选择。AI 可以快速给你列出各种方案的 trade-off。 • 模拟场景：你可以让 AI 模拟不同的故障场景，帮你思考系统的容错设计。比如"如果数据库挂了，我的系统会怎样？" 架构设计能力的提升关键还是在人，而 AI 则能帮助你更高效地学习、更快速地试错和迭代，加速你成为合格系统架构师的步伐。写在最后原本只是打算简单写写的，不小心还是扯多了。没办法，系统设计这种事是真的没什么捷径好走，只有坚持学习。当然方法得当还是能加速一点。在 AI 时代，架构师的价值不是被削弱了，而是被放大了。因为 AI 让实现变得更容易，所以设计的好坏会更加明显地影响最终结果。一个好的架构设计，配合 AI 的实现能力，可以让你的生产力提升十倍甚至百倍。希望你早日掌握好架构设计，不用担心被 AI 替代，反而可以利用系统设计能力让 AI 更好地为你效力。毕竟，AI 再厉害，也需要有人告诉它要造什么样的房子，不是吗？

#AI编程 #系统架构 #程序员能力 #人工智能 #项目管理 #技术提升