※ 引述《karst10607 (新陈代谢)》之铭言： : 最近公司的主管突然想到 : 我们应该要去搜寻世界各大科技软体公司使用的文件管理工具 : 才能跟上面报备我们的tool chain应该怎麽更新或列出明确使用规范 : 比方说我们用confluence, jira, google doc, slack, github : 可是没有规范大家必须把什麽样的资料记录在confluence，於是资讯会四散 : 回报会出现在spreadsheet或g doc的某个comment里面之类的 : 不回报到特定jira或负责人，或是回报故意模糊，其实就是要甩锅的节奏 : 这很正常，但公司已经到了有点无法管理的状态了 : 我跟主管说，可是其他公司怎麽用各种软体管理工作流程应该算是它们的机密耶 : 但主管执意说就是要去上网蒐，不管你用什麽方法 : 其实就是暗示你用自己的人脉和过去的经验去挖 : 我说有三个合法的办法，就是上网搜寻比如某工具 + 抱怨功能 : 第一招: 比如 SDL + search : Confluence + search : 就会看到某前公司的职员抱怨分享以前在哪任职时公司内的文件工具或作法如何 : 比如有人开单超级懒，用对话截图取代打字或code snippet，结果单当然都找不到资讯 : 因为没有ocr，这些单资讯都是空的 : 第二招: : 公司如Atlassian会疯狂用客户帮自己软体背书 : 都是讲转移到自家服务，但其他细节或使用方式都不会多说 : NASA好像也是他们客户 : 第三招: : 根据过去某些公司招人时，留下的使用工具等公开资讯 : 类似新闻或徵才条件 : 比如boeing公司的工程文件新闻 : 我确实是可以分享过去面试的时候，或是任职的公司怎麽管理文件 : 但我比较担心这会有什麽营业问题吗? 即使并没有显示的内容开发机密 : 我的工作就是做这方面的，所以有一些经验 : 但日商文化就是: 先辈就是官，官大学问大， : 台商有些偏制造业的会有DCC (document control center) : 资料只进不出，只更新不删除，标示过期作废而已 : 但偏软体的通常不会是这种模式 : 各位先进会建议我怎麽做? : 要认真做不是不行，只是每次都要用职业道德和职业生命当底线，有点讨厌 : 题外话: 今天经过一间古本行，发现原来日本的出版文化很像抵抗焚书坑儒的精神 : 当时只印刷千本的照片或报导，其实是为了数十年後被挖掘出来的实体证据， : 因为主流大众媒体是不断被政府和企业在进行操弄和删除报导的 : 反过来，也有些报社和出版社，即使在被摸头的情况下，依然刻意留下蛛丝马迹给後人 : 一方面是为了自保，另一方面是为了销量 : 如果身处这样的社会，也许会觉得只要有耐性，什麽都能被找出真相 : 但资讯软体业，即使用git还是能甩锅的，关键的描述不计入就好了... 根据过去经验，我看到比较好顺的做法是， 将部门文件资产，分成四类管理： 专案管理：可用Jira，或类似工具。 文件管理：可以用 FTP or NAS。 code：各种git工具。 知识管理：可用confluence，或类似工具。 工具不太重要， 你把Jira换成office 356上的excel也可。 你把confluence换成 gitlab wiki也无所谓。 你把文件管理换成Windows网路分享资料夹也可。 重点是 如何将整个产品生命周期的重要文件，重要知识，都可管理起来。 以一个产品功能的整个开发流程为例： PM先与团队的 Technical Lead讨论某个功能是否的技术上可做。 确认可做，讨论一下优先权与工作量。 接下来，PM会用Jira先把使用者需求， 拆成Epic或 story，或Scenario。 不够细的story再拆成小的story，直到这个story可在一个版本周期内开发完。 也就是保证每个story都可在固定时间内关闭。 工程师压力也小。 这个story就是，PM，tech lead，开发者，测试，共同交流的地方。有疑问，完成什麽，只要是需要被记录与的全在此讨论。 如果是闲聊专案，不需要纪录的，就用即时通讯讲一下就好。 所以专案的需求，开发，测试，纪录全部可管理起来，可搜寻。 开发前，tech lead会写规格书，xxx系统1.0.4版，系统设计。然後透过系统规格书与大家讨论做法。并分配工作。 这种产品设计规格书，产品release note，deployment 手册，会统一放在一个部门专门的FTP或NAS管理。因此，你要看整个软体产品发展历程，设计文件，每个版本都有。 开发人员就开发程式码，利用git管理程式码版本，分支。git工具通常会与CI/CD工具结合，控管大家上传程式码品质。 我以前待过的公司，每天还会自动启动CI流程检查每天的程式码，因此，大家程式码修改可追朔，程式码品质可管理。 管理上，不允许上传CI不会过的程式，每日自动CI没过，不能下班。否则影响考绩。不会有人为了应付，上传不可run的程式。 CI过了以後，才会有code review。 code review，很多人只做，程式码有没有bug的review。但真正有在知识管理的公司，还要确认程式码风格，架构，不要有只有一个人看得懂的 magic number… 由於CI/CI流程有接jira。所以CI有没有过都会更新在story或issue，确保大家都能同步知道现在程式码状态。另外，Jira也有绑mail通知功能，所以有紧急重要的事情，都可以不上Jira就知道。 接下来是技术知识管理。 很多解bug的流程，常常犯的错，系统性能瓶颈，为什麽上线了会有bug，当初技术选泽，survey技术或产品的文件…这些用一个知识管理交流系统存放。例如confluence。 不管是专案的市场survey，需求的技术选型，debug过程，只要是对别人有帮助，管理者都要求要写，要放在知识管理系统中。知识管理系统最重要是能全文搜寻就好，让人方便搜到过去人的经验。 当初我前公司还规定与鼓励，根据职级不同，每半年要求不同的篇数，来保障资深人员不要只出一张嘴。要写文件传承知识。然後没达篇数低标的扣分，每季会评选好的文章做奖励。 整个流程包含，四大类工具： 专案管理：可用Jira，或类似工具。 文件管理：可以用 FTP or NAS。 code：各种git工具。 每间公司文化与流程不同，应该是先去盘点自己公司软体生命周期，该做什事情，各阶段该产生什麽产出物，来决定适合工具，而不是照别人公司的建议照抄。 再谈谈到管理： 工作那麽累了，同事又彼此藏东西乱坑人， 我干嘛要去记录，分享这些记录，文件，知识？ 我是从来没看过一个组织，不靠管理， 能自动自发做好这些啦， 是我，我也模糊纪录，应付文件，到处藏经验啊。这样我才轻松，我的考绩才会好。 我待过的公司，大部分都是失败的，即使号称走CMMI ,L4的组织也是失败的，要查文件一堆，但内容打开来，全是废文，应付式的文件占全部。 唯一比较成功的部门，想要什麽文件或纪录，大概都搜得到，管理有以下特色： 1.专案生命周期，每一阶段要生什麽文件，纪录，用什麽系统存，有标准做法。且每个专案一致。 例如上述说过，Jira用来做需求纪录，这个系统开发的进度，不会有第二个地方纪录。系统的SDS，部署方式，就放在某个FTP位置不会有第二个地方。这些事情，新人来的时候，我们都会一步一步指导。 我当时进这家公司，还是新人时，我也觉得麻烦啊，各种流程都规范要上传文件，上传知识到某个地方。 但是真的各种bug出现，流程不过，自己去搜以前的文後，就知道这组织的用心了，回头看还会很感谢这种组织的。 流程与文件管，管理者要负全责， 没做好是管理者的问题，不是开发者的问题。 很多人认为，专案开发流程生文件浪费时间？ 有痛过的就知道，应该倒过来想， 不生文件讨论，更浪费大家时间呢？ 不生文件与流程，线上又出了个bug损失几万的广告播放量，谁负责？ 员工不懂文件怎麽写？那也是管理没做好， 要嘛招人有问题，要嘛，管理者没指导。 事情是否成功，管理者责任最大。 2. 文件的产生与纪录，要绑定部门与个人利益。 例如，Jira没按照规范做，人家问你问题你不回，人家发issue给你，你超过24小时不回，SDS，测试文件都没有… 直接影响了个人与部门考评。(与奖金) 看起来很严厉，其实也是管理能力的差别而已。 烂的管理者只会骂人： 你怎麽不去把文件上传，扣你考绩。 好的管理者，懂得鼓励，懂得当个教练， 营造出文件分享可帮助别人， 可以增加自己影响力， 可以让跨部门的人认识有你这个专家， 为自己考绩加分的气氛。 管理者本身也该把知识分享， 纳入每次的考评作为参考，做得好的就大声鼓励。 文件与知识管理成功的特徵，就是： 1.流程产生什麽文件，有建立规范。 2.文件分享知识分享，绑定个人利益。 用什麽工具，才能文件或知识管理成功， 根本不是重点。 没有人会无缘无故分享知识的，除非对自己有利。 至於怎麽样的管理手段，可以将知识分享绑定利益，就是管理者的能力了。 看的少的只会骂人，批评人， 看得多的自然有更好的手段。 原PO： 了解别人怎麽使用工作做专案知识管理， 应付一下就好 (我也分享给你了) 部门能否管理好文件或知识重点在於： 1.自己公司的流程，产出物，适合的工具盘点。 2. Manager有没有待过成功团队， 自己有没有能力管理好部门知识。管理者有没有看过成功例子，深刻体会人性就是不爱分享，要绑定利益才是关键。导入後是否顺畅要靠管理者沟通能力。 以上是个人经验分享，不是标准答案。 如果见解不同很正常，大家的经验不同而已。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 42.73.78.150 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1719833895.A.D0C.html