@GT7 这不都是 jira 上面的概念，难道翻译成中文？

@HL8 我知道自己在说什么观点。 是 15L 和你先开始胡搅蛮缠的。 日常行文习惯不会干扰工作邮件行文问题，如果做不到，那是你水平低。 我很清楚，只是你硬杠而已。 无需你提醒，你管好你自己吧，你真的挺能倒打一耙的。 我也没想和你聊什么观点，我觉得你没什么脑子。连社交发帖行文和工作需要都分不清楚。 但是你喷完粪说什么别回了，就挺尬的。这种忍不住下场发言，没道理讲不过，只能故作清高的样子有点丑陋。

@GT7 有些词就是没有好的中文翻译 , 用英文更合适 , 只能说超出你的认知水平了

这不得把“管理”人员累死 https://i.imgur.com/agAJ0Rd.png 还要写邮件标题，组织邮件内容段落、格式，还不能立马收到“收到” 能在微信里面留痕都已经算不错了，很多时候都是叫你去它工位/办公室，口头传达给你，你自己做记录。

没办法 要么忍 要么走

sb 微信办公，且不说追溯问题工作流，所有通讯软件里最不适合的就是微信， 一个主打安全隐私和移动端的应用，哪一点对工作方便。 哦手机没在边上我没法办公了？我手机用小灵通不能办公了？ 我办公还是手机办公，电脑写的代码还是微信写的代码 有些人整天拿个小绿泡泡聊骚，低着个头那个屏幕戳戳这个戳戳，就工作也要用

@duhb 你说的这些，那是人家祖上和二战后几十年发展的积累形成的厚重的壁垒，你看德国车企在新能源转型的缓慢和落后就知道他们效率肯定是比不上东大。

@zjsxwc #34 @processzzp 合理的工作方式不是"双方各自多出几次事故, 多背几次锅, 企业和员工自然会主动留存" 需求用 Jira 来管理的, Jira Issue 里的描述是需要发起人按照书面语言, 正确合理的用英语写出来的. 描述包括需求的背景, 相关的干系人, 验收的结果, 限制条件, 开发的难度(story point)等 开发人员分析确认需求之后, 还要在 comments 写出实现思路, 对系统上下游的影响. 如果需求有变更, 相关干系人需要追加 comments, 并需要开发确认, 这样在变更历史里面也能体现. 开发人员之间的沟通细节, 比如影响的代码块也可以添加到 comments 里面. 以上的沟通, 都是书面形式, 英语沟通的. 这样才实现了需求的管理, 可追溯性, 让每个接手的人能快速了解上下文. 如果用微信管理需求, 不敢想象, 根本就做不到的, 这是显而易见的吧. 至于为什么用英文, 因为我在北美, 官方语言是英文. 华人公司, 组里也是有外国人的, 你不能期望人家学会中文, 来跟你一起中文写文档, 中文写代码吧. 我真见到过, 有些人开会组里大部分中国人情况下, 上台无视一起开会的老外, 用中文讲技术解决方案的, 边上老外直接跟我吐槽:"whatever he's talking about, I totally agree on it." 顺便回答以上抬杠的. 我写文档能分清中英文, 我写文档不用中文输入法.

是的，我裸辞的这家公司就是用微信办公，我之前的公司也是 Jira ，后来转到蓝鲸，反正都是用正规的项目需求管理系统，平时同事交流只在企业微信（后来转到飞书），微信上我基本出了关系很好的那几个同事其他人都不加。用微信办公后感觉生活都焦虑了，微信一响以前是下意识朋友或者家人找我，用微信办公后微信一响心都颤一下，完全打乱生活了。

“敏捷开发”使然，刨根问底还是企业文化导致的。即使外企用微信，他们可能也会用其他工具来辅助管理需求，不会随随便便群里说几句话就推进需求开发。即使国人用邮件来办公，那可能邮件标题就一句话，很简陋，然后老板会让你即时回复邮件内容，把邮件办公整成了 IM 办公