Làm thế nào bạn có tài liệu công việc, quy trình và môi trường của bạn?

Bạn đang sử dụng định dạng wiki? Nếu vậy, sản phẩm nào? (MediaWiki, Confluence, Sharepoint, v.v.)

Bạn đã tạo ra một nền tảng kiến ​​thức? (Tài liệu ngắn hướng đến vấn đề / giải pháp.)

Những thách thức nào bạn tìm thấy với việc tạo tài liệu hoạt động, vì vậy bạn không nhận được cuộc gọi khi bạn nghỉ lễ?

Đối với tôi, tôi thấy thường có một lượng "quán tính" nhất định liên quan đến việc hoàn thành tài liệu. Nó dường như là một loại người khác có thể thực hiện một nhiệm vụ, sau đó suy nghĩ về cách họ thực hiện nhiệm vụ và mô tả nó để người khác có thể thực hiện - loại lực lượng để bạn "đi meta" và không phải ai cũng cảm thấy thoải mái khi làm điều đó.

Cập nhật

Câu trả lời cho đến nay bao gồm

• Hợp lưu
• Flexwiki
• Sương mù
• Mediawiki (với các plugin như fckeditor)
• Điểm chia sẻ
• TWiki
• Tài liệu Word / Excel / Visio
• Tập lệnh tài liệu

Chỉnh sửa: Bạn không hoàn toàn làm tài liệu cho mạng của mình bằng hệ thống giám sát của mình? Nagios luôn khuyến khích việc sử dụng chỉ thị của cha mẹ để phản ánh cấu trúc mạng của bạn và chỉ thị Notes_url được thiết kế để cho phép bạn liên kết với wiki hoặc tài liệu dựa trên trình duyệt khác. Vì vậy, ở đây "tài liệu" được phân chia giữa "tài liệu sống" của hệ thống giám sát và tài liệu ngoại tuyến chi tiết hơn trong wiki. Vì tôi dành nhiều thời gian nhìn chằm chằm vào Nagios, nên cố gắng nỗ lực để làm cho nó càng nhiều thông tin càng tốt.

Nhận xét về các dụng cụ.

Chúng tôi đã thử wiki trực tuyến nhưng tìm thấy một số hạn chế, có thể là sở thích cá nhân, nhưng bao gồm cấu trúc tài liệu và hầu hết phải được kết nối với máy chủ tài liệu.

Đang kết nối là một vấn đề nghiêm trọng nếu bạn ở chế độ ngoại tuyến hoặc tại chỗ (rõ ràng bạn có thể giảm thiểu tại chỗ bằng kết nối SSL được bảo mật và các cộng sự).

Quy trình tài liệu hiện tại của chúng tôi là:

• trình tạo html tĩnh
• cú pháp đánh dấu
• hệ thống phiên bản phân tán

Chúng tôi có bố cục 'trang trọng' cho tài liệu và cung cấp cấu trúc cho các menu (và CSS được liên kết để tạo kiểu trực quan, v.v.)

Trình tạo HTML tĩnh

Chúng tôi sử dụng một trình tạo html tĩnh trong nhà dựa trên cubictemp và một số công cụ khác: pygments , docutils .

Các trang được tạo ra trông có vẻ xấu xí, vì hầu hết chúng ta / các hệ thống / lập trình viên của chúng ta đều biết cái gì là đẹp về mặt thẩm mỹ nhưng lại thiếu sự phối hợp để xây dựng như vậy.

Nhưng nó có / cho chúng tôi bao gồm các tệp cấu hình, tập lệnh mẫu, pdf, v.v., mà không phải lo lắng về định dạng html làm hỏng nó hoặc lo lắng về nơi tìm thấy nó trên 'máy chủ' để tải xuống.

Nếu nó không phải là HTML, chỉ cần thả nó vào thư mục và thêm một liên kết url vào nó.

HTML cung cấp cấu trúc 'tiềm năng' để bố trí và cũng cung cấp chính xác 'liên kết' giữa các mục kiến ​​thức / nội dung (cũng như các cơ chế cấu trúc cơ sở, chẳng hạn như có thể tạo menu, bảng nội dung, v.v.) Với HTML, giờ đây mỗi người dùng có thể chạy một máy chủ web nhỏ trên máy của họ cho dù lighttpd hoặc một cái gì đó nhỏ hoặc chỉ phát triển đầy đủ với Apache hoặc IIS.

Tất cả các máy của chúng tôi đều có khả năng phục vụ html cơ bản và hoạt động đủ tốt cho chúng tôi.

Cú pháp đánh dấu.

Chúng tôi sử dụng một phiên bản bastardised của MARKDOWN, Textish và hoặc tái cấu trúcTEXT để cho các loại nước ép 'sáng tạo' của chúng tôi viết tài liệu mà không phải lo lắng về HTML.

Điều đó cũng có nghĩa là mọi người đều được sử dụng trình soạn thảo yêu thích của họ (tôi sử dụng Scintilla trên Windows và * Nix) trong khi những người khác ở đây sử dụng vi / vim.

Hệ thống phiên bản phân tán.

Chúng tôi sử dụng Git để 'phân phối' tài liệu giữa những người dùng. Ồ, và chúng tôi cũng sử dụng khả năng phiên bản của nó.

Lợi thế chính cho chúng tôi là tất cả chúng tôi đều có thể cập nhật tài liệu mà không cần phải kết nối với máy chủ và không phải xuất bản các tác phẩm 'đã hoàn thành'. Tất cả chúng ta có thể làm việc trên cùng một phần của tài liệu, hoặc các phần khác nhau, hoặc chỉ tiêu thụ thông tin.

Cá nhân, tôi ghét bị ràng buộc với một máy chủ để cập nhật blog chứ đừng nói đến wiki. Git hoạt động tốt cho chúng tôi.

Nhận xét về quy trình làm việc

Wiki dường như là "mốt" để phổ biến / mã hóa kiến ​​thức, nhưng như đã nhận xét ở mọi nơi, mọi quy trình trở nên khó duy trì và việc tìm ra hỗn hợp các công cụ hỗ trợ tốt nhất cho các nhóm của bạn và sẽ bền vững.

Các giải pháp tốt hơn cuối cùng chỉ được phát hiện và không bắt buộc.

Chúng tôi đã bắt đầu sử dụng DokuWiki nơi tôi làm việc.

Từ trang web của Dokuwiki:

DokuWiki là một tiêu chuẩn Wiki, đơn giản để sử dụng Wiki, chủ yếu nhằm mục đích tạo tài liệu dưới mọi hình thức. Nó được nhắm mục tiêu vào các nhóm phát triển, nhóm làm việc và các công ty nhỏ. Nó có một cú pháp đơn giản nhưng mạnh mẽ để đảm bảo các tệp dữ liệu vẫn có thể đọc được bên ngoài Wiki và giúp dễ dàng tạo ra các văn bản có cấu trúc. Tất cả dữ liệu được lưu trữ trong các tệp văn bản thuần túy - không yêu cầu cơ sở dữ liệu.

Tôi thấy Dokuwiki dễ thực hiện nhất vì nó không yêu cầu cơ sở dữ liệu và rất dễ thiết lập. Ngoài ra còn có các mô-đun bổ trợ cho phép sử dụng đăng nhập tài khoản Active Directory hiện tại của tôi thay vì phải tạo tài khoản cho mọi người, đây là một điểm cộng rất lớn so với nhiều hệ thống wiki khác mà tôi tìm thấy. nó cũng có điều khiển phiên bản điển hình, nơi bạn có thể biết ai đã đăng những gì ở đâu và nó có khả năng quay trở lại phiên bản trước dễ dàng nếu cần thiết. Chúng cũng bao gồm một trang chủ có thể tùy chỉnh trong đó yo có thể dễ dàng thay đổi bất kỳ loại nội dung nào phù hợp nhất với môi trường của bạn.

Doku Wiki hoặc Sharepoint cho những thứ khác phù hợp với biểu đồ.

Bạn được sử dụng khá nhanh để đăng lên wiki và cú pháp thực sự không quá phức tạp. Rất dễ dàng để sắp xếp thông tin và giúp người khác dễ dàng tìm thấy nó sau này.

Tôi sử dụng visio để tạo các biểu đồ để giải thích rõ ràng hơn (xuất dưới dạng JPEG).

Chúng tôi đang sử dụng wiki. Thực tế, chúng tôi đang sử dụng MediaWiki. Trên đầu trang MediaWiki, chúng tôi đã cài đặt tiện ích mở rộng Semantic Mediawiki , thực sự biến MediaWiki của chúng tôi thành một cơ sở dữ liệu được gõ lỏng lẻo mà chúng tôi có thể truy vấn với Danh mục, tiêu đề, nội dung, v.v.

Ví dụ: giả sử tôi muốn xem tất cả các tên mạng định tuyến qua Cụm F. Tất cả những gì tôi cần làm là sử dụng trang Đặc biệt: Hỏi để truy vấn [[Danh mục: cname]] [[Destination :: cluster_f]] .. và nó sẽ trả về tất cả các trang được phân loại là một tên gọi với đích là cluster_f.

Chúng tôi hỗ trợ một vài trăm khách hàng rất khác nhau, vì vậy có tài liệu đó ở vị trí trung tâm (và có liên kết chéo để các trường hợp đặc biệt được ghi chép lại và gắn vào toàn bộ) là một điều rất tiện dụng. Rõ ràng, tài liệu của chúng tôi cần được duy trì, nhưng bạn có thể sử dụng nhiều hơn phương pháp 'làm vườn' để bảo trì vì bộ công cụ mediawiki để giữ một bộ dữ liệu lớn hiện tại đã khá hoàn thiện.

Với các plugin phù hợp, Trac có thể trở thành một vé kết hợp và hệ thống wiki. Điều này giúp vé của bạn dễ dàng liên kết đến các bài viết wiki và ngược lại.

Một vài plugin tôi thích:

• Plugin vé riêng . Trac được xây dựng như một bugbase nơi tất cả các vé và phản hồi của họ là công khai. Điều đó không phù hợp với hệ thống vé CNTT, nhưng plugin này khắc phục điều đó.
• Plugin Trac WYSIWYG . Hãy đối mặt với nó, hầu hết mọi người sẽ không học wikisyntax để làm cho bạn hạnh phúc. Điều này mang lại cho họ trình biên tập 'những gì bạn thấy là những gì bạn nhận được' cho cả vé và trang wiki.

Có khá nhiều tùy chỉnh cho Trac. Không khó để thiết lập và tùy chỉnh hệ thống Trac theo ý thích của bạn!

Trong công việc trước đây tôi đã sử dụng Twiki. Nó hoạt động khá tốt.

Bên cạnh đó, tôi có xu hướng tự động hóa hầu hết các tác vụ và ghi lại các tập lệnh (không phải lúc nào cũng có nhiều đặc điểm, nhưng vẫn ...). Viết kịch bản dễ dàng được thực hiện trong quá trình thiết kế chúng, vì vậy không có chi phí thực sự ...

Sự kết hợp của cả hai (và sử dụng kiểm soát phiên bản cho các tập lệnh) đã thực hiện thủ thuật khá tốt.

Một sự pha trộn của JIRA, Confluence và Word Documents.

Kiến thức thể chế hóa

Chúng tôi bắt đầu với các tài liệu. Sau đó, chúng tôi lưu trữ một số trong số họ trong thư viện Sharepoint. Sau đó, gần đây chúng tôi chuyển đến wiki Sharepoint. Tôi thích cách tiếp cận ma sát thấp của wiki trong việc cập nhật nhanh chóng mọi thứ, mặc dù các wiki của Sharepoint để lại một số điều mong muốn trong hỗ trợ đồ họa và hỗ trợ định dạng cho những thứ như bảng. Nó tốt cho văn bản và trình soạn thảo tích hợp cho phép một số định dạng HTML cơ bản và các danh sách được sắp xếp / không theo thứ tự. Có những lựa chọn thay thế chi phí thấp khác cho Sharepoint.

Chúng tôi cũng có một cơ sở kiến ​​thức không chính thức cho vé hỗ trợ của chúng tôi trong phần mềm bàn trợ giúp của chúng tôi, Numara's Track-It. Nó không hoàn hảo nhưng nó hoạt động.

Bắt nhân viên sử dụng kiến ​​thức được thể chế hóa

Tôi đồng ý với đánh giá của bạn rằng nhận được kiến ​​thức được thể chế hóa chỉ là một phần của trận chiến. Nếu tổ chức và mọi người của bạn không quen "nghiên cứu trước, hãy hỏi thứ hai" thì bạn sẽ thấy rằng cách cũ chiếm ưu thế: mọi người vẫn sẽ tìm đến các bậc thầy chính thức và không chính thức để trả lời, và đối với một số người, sẽ luôn dễ dàng hơn để hỏi người bên cạnh bạn hơn là tự mình tìm kiếm.

Đối phó với điều này sẽ liên quan đến một số quản lý thay đổi; giống như hầu hết các sáng kiến ​​thay đổi thành công ảnh hưởng đến nhiều hơn là một nhóm nhỏ, sẽ giúp có sự chứng thực và hỗ trợ của người quản lý. Bạn thực sự phải rèn hành vi mới theo hai hướng; ai đó cần nắm bắt kiến ​​thức và mọi người cần sử dụng nó. Khó hơn nữa là mọi người cũng cần phải giữ dữ liệu đó.

Chỉ cần một số ý tưởng: có lẽ sẽ cần phải được khuyến khích dưới hình thức chính sách chính thức nêu rõ rằng vé đã giải quyết và các vấn đề cần được ghi lại trong cơ sở kiến ​​thức hoặc wiki trước khi chúng có thể được coi là đóng. Ngoài ra, các nhà lãnh đạo kiến ​​thức thường nhận được câu hỏi không nên luôn luôn đưa ra câu trả lời theo yêu cầu; họ cần hướng mọi người đến wiki và làm cho họ quen với việc kiểm tra ở đó trước. Một điều nữa là làm cho dữ liệu có sẵn cho người dùng để tự giúp mình để vấn đề có thể được giải quyết trước khi nó trở thành một mục khác mà nhân viên kỹ thuật phải xử lý.

Điều tuyệt vời là hệ thống bàn trợ giúp của chúng tôi có hệ thống tương tự StackOverflow và ServerFault: khi nhập câu hỏi, công cụ tìm kiếm sẽ tìm thấy các mục tương tự và cung cấp chúng, vì vậy người dùng có thể xem chúng ngay cả trước khi gửi câu hỏi.

Ở hai nơi làm việc cuối cùng của tôi, tôi đã sử dụng Wiki của Sharepoint, cùng với một thư viện tài liệu có chứa một số tài liệu nhất định (như DRP và kế hoạch nâng cấp một lần) không thể dễ dàng tạo thành tài liệu Wiki. Những tài liệu đó có liên kết từ trong Wiki. Wiki có nhiều lợi thế trong lĩnh vực này, vì nhiều người có thể chỉnh sửa nó, phiên bản được tích hợp sẵn, dễ dàng tìm kiếm và truy cập, v.v. Để viết nhanh các ghi chú hoặc ý tưởng, tôi nên sử dụng OneNote hoặc bảng trắng.

Tôi đã tạo ra một số cơ sở kiến ​​thức trước đây, ở định dạng diễn đàn (cả trong Lotus Notes và MS Sharepoint), nhưng tôi phải nói rằng chỉ hiếm khi mọi người tìm kiếm chúng để xem liệu một vấn đề nào đó đã được giải quyết chưa. Một giải pháp như vậy phải đến từ ngày đầu tiên với một công cụ tìm kiếm rất mạnh mẽ và hiệu quả.

Nếu bạn muốn tạo tài liệu có thể được sử dụng trong khi bạn đang trong kỳ nghỉ, hãy viết chúng như thể bạn đang cố gắng hướng dẫn một trong những cha mẹ của bạn. Đây không phải là bằng chứng 100%, nhưng đôi khi giúp. Phụ thuộc vào người đọc nó.

Sharepoint là tốt đẹp.

Các tính năng tìm kiếm của nó có khả năng lập chỉ mục hầu hết mọi loại tài liệu, giúp việc tìm kiếm tài liệu thực sự dễ dàng.

Nó có thể thực hiện một số khuôn mẫu cũng có thể làm cho mọi việc dễ dàng hơn, ví dụ như bạn có một bảng thông tin tiêu chuẩn cho mỗi máy chủ bạn xây dựng.

Nó cũng có thể phiên bản tài liệu của bạn cho bạn để bạn có lịch sử kiểm toán các thay đổi tài liệu.

Ngoài ra, các tệp có trong các thư viện tài liệu có thể được truy cập qua web, trong triển vọng hoặc thông qua một chia sẻ không có quyền ra khỏi hộp.

Chúng tôi đã sử dụng MediaWiki (với fckeditor) trong vài năm, mặc dù tôi phải nói rằng sẽ rất tuyệt nếu việc xử lý ảnh (tức là ảnh chụp màn hình) dễ dàng hơn. Và trong khi có khả năng tìm kiếm là điều cần thiết - tôi thấy tìm kiếm của MediaWiki thường bỏ lỡ các trang. Có lẽ đó chỉ là vấn đề học cách tìm kiếm tốt hơn (loại nào đánh bại mục đích có cách đơn giản để người khác thực hiện công việc của bạn)

Ngay bây giờ chúng tôi đang thảo luận về việc chuyển tất cả mọi thứ sang MS Sharepoint , mặc dù không cần thiết đến wiki của họ. Tôi nghĩ Sharepoint có thể thực hiện tìm kiếm tài liệu đầy đủ theo cách phủ nhận một số lợi thế của wiki, vì vậy chúng ta sẽ thấy điều này sẽ đi đến đâu.

(không mong đợi quá trình chuyển tất cả tài liệu hiện tại của chúng tôi :))

Chúng tôi đang sử dụng wiki. Chắc chắn cú pháp đã mất một chút để làm quen, nhưng cú pháp chúng tôi đang sử dụng (twiki) lưu trữ dữ liệu của nó hoàn toàn dưới dạng tệp văn bản. Điều này cho phép chúng ta dễ dàng đọc chúng trong trường hợp xảy ra thảm họa, vì chúng ta có thể khôi phục chúng ở bất cứ đâu và tìm kiếm chúng từ dòng lệnh thông qua grep và đọc chúng trong bất kỳ trình soạn thảo văn bản nào chúng ta muốn.

Mỗi máy chủ đều có một trang, với một tập hợp các trang phụ tiêu chuẩn để thay đổi thông tin quản lý, khởi động / tắt máy và ghi chú cấu hình, cũng như thông tin dns, tường lửa và thông tin tài sản.

Chúng tôi đã sẵn sàng để chuyển sang một số phiên bản của dịch vụ Sharepoint để cố gắng đưa chúng tôi ra khỏi hỗn hợp các tài liệu từ trải rộng trên ba máy chủ và ai biết có bao nhiêu thư mục. Hiện tại, chúng tôi có một bảng tính excel lớn chứa các siêu liên kết đến các tài liệu được mô tả trong đó.

Không phải là cách tốt nhất để làm điều đó, nhưng khi công ty bắt đầu, họ không bao giờ lên kế hoạch làm thế nào để xử lý tài liệu nội bộ và để lại cho mỗi nhóm để quyết định cách sắp xếp và lưu trữ tài liệu của riêng họ khi họ thấy phù hợp. Bây giờ, chúng tôi đang cố gắng hợp nhất thành một hệ thống hợp nhất, sẽ xoay quanh một trong những dịch vụ của Sharepoint.

Trong NGO nơi tôi làm việc, chúng tôi chỉ sử dụng các tệp văn bản được đặt trong một thư mục cho các thủ tục quan trọng. Với tư cách là một nhà quản trị hệ thống / Nhà phát triển web lai, tôi đã sử dụng một nền tảng kiến ​​thức về các tệp văn bản nằm rải rác trên một thư mục cây, đó là Memex của tôi và tôi viết ra hầu hết mọi thứ trên đó (cá nhân, công việc, v.v.). Lược đồ này rất dễ quản lý bằng cách sử dụng Jedit một con dao quân đội thực thụ để xử lý văn bản, tôi đã tìm thấy trình cắm phác thảo của nó, tính năng gấp mã và siêu tìm kiếm không thể thiếu. Tất cả điều này được sao lưu an toàn bởi rsync đến một máy chủ từ xa có thể truy cập ssh.

Kết hợp với Makelink Firefox Extension và bạn có trình quản lý dấu trang hoàn hảo.

Chúng tôi sử dụng flexwiki , là một dotnet và nguồn mở.

Erm ... làm thế nào về Fogormsz? :)

Chúng tôi đang sử dụng VítTurn cho nội dung và SharePoint để lưu trữ tài liệu / hình ảnh.

Có một số điều thú vị ở đây - tôi thích một trong những mật khẩu an toàn.

Chúng tôi sử dụng kết hợp các tệp văn bản để tìm kiếm nhanh với grep. Và SharePoint cho một bộ sưu tập tài liệu chuyên sâu có tổ chức hơn (sơ đồ Visio, v.v.).

Là khách hàng của Google Apps (Doanh nghiệp), chúng tôi sử dụng trang web Google - "hương vị" wiki của họ. Dễ sử dụng và chúng tôi đã có sự áp dụng tuyệt vời từ quản trị viên và nhà phát triển.

Tôi đã không thấy câu hỏi này trước khi tôi trả lời một câu hỏi khác , nhưng ở đây chúng tôi đi.

Chúng tôi sử dụng một số công cụ và phương pháp.

• Thông số chức năng cho các thành phần cơ sở hạ tầng và phần mềm.
• Hai kết hợp Wikis . Một cho tài liệu nội bộ của công ty (chính sách, thủ tục, cơ sở hạ tầng nội bộ và CNTT, v.v.) và một cho các sản phẩm phần mềm nguồn mở của chúng tôi.
• Xét nghiệm RSpec và dưa chuột . Phần mềm của chúng tôi chủ yếu được viết bằng Ruby và chúng tôi thực hành BDD / TDD , vì vậy các bài kiểm tra đặc điểm kỹ thuật cũng lái mã thực tế và tài liệu.
• Tài liệu mã nội tuyến. Chúng tôi sử dụng đánh dấu RDoc trong các nhận xét mã.
• Quản lý cấu hình khai báo ( Chef ). Tất cả các máy chủ của chúng tôi được quản lý với Chef, "tài liệu tự" thông qua các tài nguyên truyền tải trong công thức nấu ăn và sách dạy nấu ăn.

Chúng tôi thích Confluence vì nó rất linh hoạt, mạnh mẽ và có đầy đủ tính năng, cộng với nó gắn liền với phần mềm quản lý vé mà chúng tôi thích, Jira .

Trong các công ty trước đây tôi từng làm việc, tôi đã sử dụng nhiều công cụ và phương pháp khác nhau và nhiều người đã cố gắng duy trì với một nguồn tài nguyên duy nhất (như Wiki) cho mọi thứ. Vấn đề với đó là ghi lại các chủ đề khác nhau bằng một công cụ duy nhất không phù hợp với chủ đề đó có nghĩa là nhiều thứ sẽ không được ghi lại, bởi vì rất khó để di chuyển thông tin. Là một người đam mê Unix / Linux, tôi tin rằng mỗi tác vụ đều yêu cầu một công cụ cụ thể và công cụ đó sẽ phù hợp với nhiệm vụ đó cực kỳ tốt.

Câu hỏi này rất giống với câu hỏi này và tôi đã chuyển câu trả lời của mình đến đó.

Tôi làm hầu hết các tài liệu cho công ty của mình và định dạng được thiết lập khi tôi bắt đầu làm việc ở đây là MS Word cho các bản gốc có thể chỉnh sửa, được xuất sang PDF để phát hành chung chỉ đọc. Nó hoạt động khá tốt đối với các dự án chỉ có một người đang cập nhật tài liệu và vì người đó thường là tôi, nên ban quản lý không thấy cần phải thay đổi.

Chúng tôi đã bắt đầu ghi lại các lỗi của chúng tôi và các tác vụ sắp tới với Trac , trong khi sử dụng tiện ích mở rộng "Đánh giá ngang hàng" để đánh giá mã. Điều đó đã nhận được sự chấp nhận lớn từ nhóm của chúng tôi vì việc cộng tác trở nên đơn giản và dễ dàng điều hướng. Một vài thành viên khác trong nhóm đã bày tỏ mong muốn bắt đầu cộng tác nhiều hơn với các thông số kỹ thuật, quy trình kiểm tra và hướng dẫn sử dụng, vì vậy chúng tôi đang xem xét DocBook / XML được xuất thành PDF cho các tài liệu công khai như hướng dẫn sử dụng và các trang Trac WIKI cho các tài liệu nội bộ như thông số kỹ thuật và thủ tục kiểm tra.

Trong suy nghĩ của tôi, vấn đề lớn nhất khi chọn định dạng tài liệu là:

1. Có dễ dàng để tạo ra?
2. Có dễ bảo trì không?
3. Có dễ dàng để duy trì nếu người khác viết nó?
4. Nó có thể được xuất / chuyển đổi sang các định dạng khác mà không gặp nhiều rắc rối không?

1-3 làm cho cuộc sống của tôi dễ dàng hơn và rất quan trọng để tạo tài liệu nhanh chóng mà không bị điên. Tôi nghĩ rằng cái thứ tư là quan trọng nhất về phía khách hàng, bởi vì các định dạng sẽ liên tục thay đổi. Định dạng Microsoft Word 2003 sẽ không tồn tại mãi mãi và việc triển khai PDF hiện tại của chúng tôi cũng không. Tôi cần đảm bảo rằng tất cả khách hàng của chúng tôi đều có thể đọc tài liệu của chúng tôi, bất kể hệ điều hành hoặc tài liệu mà người đọc lựa chọn là gì.

Chúng tôi sử dụng MediaWiki với nhiều plugin khác nhau, bao gồm SemanticMediaWiki. SMW là tốt vì nó biến cài đặt MediaWiki của chúng tôi thành một cơ sở dữ liệu quan hệ lớn, dạng tự do có thể được truy vấn theo ý muốn. Cần biết máy chủ của một trang web trên? Ghé thăm trang của nó. Cần biết những trang web nào được lưu trữ trên một máy chủ? Chạy một truy vấn và nó sẽ chọn tên trang dựa trên thẻ thích hợp trên mỗi trang của trang web.

Tôi sẽ trả lời không phải với một hệ thống tài liệu tôi đã sử dụng, nhưng với một cái gì đó tôi đã thấy được sử dụng và tôi thấy rất tốt: http://stackexchange.com/

stackexchange là nền tảng Q & A chạy dưới serverfault (tốt, về mặt kỹ thuật nó không hoàn toàn giống nhau, nhưng với mục đích của chúng tôi ở đây, chúng tôi có thể giả định nó giống nhau).

Fogormsz sử dụng nó .

Có một bài đăng blog thú vị từ một nhân viên Fogormsz nơi tôi tìm thấy những trích dẫn này:

Đối với tất cả các mục đích bên ngoài thông số kỹ thuật của sản phẩm, tôi nghĩ rằng các hình thức thảo luận và wiki của công ty đã bị giáng một đòn chí mạng.

...

Vì chúng tôi đã bắt đầu sử dụng FogBugz.StackExchange.com làm nền tảng hỗ trợ của mình, tôi chưa bao giờ trả lời cùng một câu hỏi hai lần. Chúng tôi thậm chí có một máy chủ SE nội bộ mà chúng tôi sử dụng cho các câu hỏi và trả lời không công khai, và các nguyên tắc tương tự được áp dụng ở đó.

Họ sử dụng stackexchange cho cơ sở tri thức hướng tới khách hàng và cơ sở tri thức nội bộ.

Tôi quan tâm xem liệu các nền tảng Q & A trao đổi kiến ​​thức như vậy sẽ thay thế wiki của công ty.

Tại nhà tuyển dụng trước đây của tôi, tôi đã sử dụng các tệp Word, Excel và Visio được thu thập cùng nhau trong một thư mục. Một bản sao cứng của mọi thứ được giữ trong một cuốn sổ trên bàn của tôi. Tôi là người CNTT duy nhất nên không có nhu cầu truy cập thông tin.

Tại nhà tuyển dụng hiện tại của chúng tôi, chúng tôi sử dụng Macola ES bởi Exact Software, nhưng tôi vẫn thích viết tài liệu của mình trong Word và tải nó lên Macola dưới dạng tệp đính kèm hơn là sử dụng trình chỉnh sửa tài liệu tích hợp.

Tại nơi làm việc của tôi, tôi đã bỏ VítTurn Wiki trên một trong các máy chủ phát triển Windows của chúng tôi và nối nó với Máy chủ SQL của chúng tôi. Nó hoạt động thực sự tốt, chạy nhanh, và chủ yếu là tránh xa tài liệu của chúng tôi. Trong hai tuần kể từ khi được triển khai, chúng tôi đã thêm khoảng 60 trang thông tin và chỉ dành cho nhóm của chúng tôi (~ 10 người).

Cho đến nay, chúng tôi vẫn giữ thông tin về các dự án hiện tại và quá khứ trên đó và đã bắt đầu thêm thông tin về các ứng dụng như cách xây dựng chúng từ đầu, URL và các thông tin quan trọng khác cho nhà phát triển mới cho nhóm.

Một trong những trang yêu thích của tôi trên wiki là trang công cụ và thư viện. Ở đó, chúng tôi đã bắt đầu thêm thông tin về các công cụ và thư viện năng suất yêu thích mà chúng tôi sử dụng rất nhiều, một ví dụ về grepWin để tìm kiếm văn bản trong Windows.

Tôi hoàn toàn khuyên bạn nên kiểm tra toàn bộ gam có sẵn của wiki và tìm một giao diện phù hợp với mục đích sử dụng, chức năng và môi trường triển khai của bạn. Tôi đã chọn VítTurn vì nó dễ sử dụng và chúng tôi có rất nhiều phòng miễn phí trên WinServer địa phương của chúng tôi, nhưng YMMV.

Chúng tôi đang sử dụng Confluence như wiki và sharepoint cho các tài liệu trong một số trường hợp. Tôi tin rằng định dạng wiki trực tuyến là một định dạng ưa thích khi bạn cần chia sẻ thông tin này thực sự rộng rãi và điều quan trọng hơn nhiều khi các tài liệu sẽ được chỉnh sửa và cập nhật rất thường xuyên. Vì vậy, tôi nghĩ rằng các bài viết cơ sở kiến ​​thức tốt hơn nên đưa vào wiki.

Chúng tôi hiện đang chuyển thông tin của chúng tôi từ các tài liệu khác nhau trải rộng trên mạng đến hai địa điểm:

1. Một wiki có sẵn trên mạng nội bộ của chúng tôi
2. Một bản sao thông tin liên quan đến một máy chủ cụ thể trong thư mục gốc / máy chủ đó.

Đối với sơ đồ mạng, Notepad mạng .

Ngoài ra, trong khi ghi lại những gì, hãy nhớ ghi lại lý do tại sao một cái gì đó được cấu hình như nó. Điều này giúp ngăn chặn những ý tưởng có vẻ như là một ý tưởng tốt biến thành sai lầm.

Chúng tôi đã phát hiện ra rằng MediaWiki đã khởi đầu chậm chạp, nhưng một khi mọi người ngoài CNTT hiểu được việc thêm bình luận, thay đổi, chỉnh sửa, v.v ... thì điều đó trở nên không thể thiếu. Các nhà phát triển đang sử dụng nó cho các tài liệu nội bộ, các cơ sở phòng. để đăng thông báo, vv Nó đã phát triển không chỉ là một công cụ tài liệu CNTT.