คุณบันทึกการทำงานกระบวนการและสภาพแวดล้อมของคุณอย่างไร

คุณใช้รูปแบบวิกิหรือไม่? ถ้าเป็นเช่นนั้นผลิตภัณฑ์ใด? (MediaWiki, Confluence, Sharepoint และอื่น ๆ )

คุณสร้างฐานความรู้หรือไม่? (เอกสารสั้นปัญหา / วิธีแก้ปัญหา)

คุณพบข้อท้าทายอะไรบ้างในการสร้างเอกสารที่ใช้งานได้ดังนั้นคุณจะไม่ได้รับสายเมื่อคุณหยุดพักร้อน?

สำหรับฉันฉันพบว่ามีองค์กร "ความเฉื่อย" จำนวนหนึ่งที่เกี่ยวข้องกับการทำเอกสาร ดูเหมือนว่าจะเป็นคนประเภทอื่นที่สามารถทำงานได้แล้วลองคิดดูว่าพวกเขาทำงานได้อย่างไรและอธิบายให้คนอื่นทำเช่นนั้นได้ - ประเภทของคุณ "go meta" และไม่ใช่ว่าทุกคนจะสบายใจในการทำเช่นนั้น

ปรับปรุง

คำตอบจนถึงขณะนี้รวมถึง

• ที่บรรจบกัน
• Flexwiki
• Fogbugz
• Mediawiki (พร้อมปลั๊กอินเช่น fckeditor)
• Sharepoint
• หัวข้อใดกรุณาติดต่อ
• เอกสาร Word / Excel / Visio
• สคริปเอกสาร

แก้ไข:คุณไม่ได้ทำการจัดทำเอกสารเครือข่ายของคุณด้วยระบบการตรวจสอบของคุณหรือไม่? Nagios สนับสนุนให้ใช้คำสั่งผู้ปกครองเสมอเพื่อสะท้อนถึงโครงสร้างเครือข่ายของคุณและคำสั่งnotes_urlได้รับการออกแบบมาเพื่อให้คุณเชื่อมโยงกับวิกิหรือเอกสารที่ใช้เบราว์เซอร์อื่น ๆ ดังนั้นที่นี่ "เอกสาร" ถูกแยกระหว่าง "เอกสารที่มีชีวิต" ของระบบการตรวจสอบและเอกสารออฟไลน์ที่มีรายละเอียดมากขึ้นในวิกิ เนื่องจากฉันใช้เวลามากมายที่จ้องมอง Nagios มันสมเหตุสมผลที่จะใช้ความพยายามเพื่อให้ข้อมูลมากที่สุด

แสดงความคิดเห็นในการขับรถ

เราได้ลองใช้วิกิออนไลน์ แต่พบข้อ จำกัด จำนวนหนึ่งซึ่งอาจเป็นรสนิยมส่วนตัว แต่รวมถึงโครงสร้างเอกสารและที่สำคัญที่สุดคือต้องเชื่อมต่อกับเซิร์ฟเวอร์เอกสาร

การเชื่อมต่อเป็นปัญหาร้ายแรงหากคุณออฟไลน์หรืออยู่นอกสถานที่ (เห็นได้ชัดว่าคุณสามารถลดความแออัดในสถานที่ด้วยการเชื่อมต่อ SSL ที่ปลอดภัยและอื่น ๆ )

กระบวนการเอกสารปัจจุบันของเราคือ:

• เครื่องกำเนิดไฟฟ้า html คงที่
• ไวยากรณ์ของมาร์คดาวน์
• ระบบการกำหนดเวอร์ชันแบบกระจาย

เรามีเลย์เอาต์ 'เป็นทางการ' สำหรับเอกสารประกอบและที่ให้โครงสร้างสำหรับเมนู (และ CSS ที่เกี่ยวข้องสำหรับการออกแบบภาพเป็นต้น)

ตัวสร้าง HTML แบบคงที่

เราใช้ในบ้านเครื่องกำเนิดไฟฟ้า HTML คงขึ้นอยู่กับcubictempและจำนวนของเครื่องมืออื่น ๆ : pygments , docutils

หน้าเว็บที่สร้างขึ้น (ไม่?) ดูน่าเกลียดอย่างเห็นได้ชัดเนื่องจากพวกเราส่วนใหญ่ / sysadmins / โปรแกรมเมอร์ของเรารู้ว่าอะไรคือสุนทรียะที่สวยงาม แต่ไม่มีการประสานงานทั้งหมดในการสร้าง

แต่มันช่วยให้เรารวมไฟล์การกำหนดค่าสคริปต์ตัวอย่าง pdf และอื่น ๆ โดยไม่ต้องกังวลเกี่ยวกับการจัดรูปแบบ HTML ซึ่งทำให้เกิดปัญหาหรือกังวลว่าจะหาไฟล์บน 'เซิร์ฟเวอร์' สำหรับการดาวน์โหลดได้จากที่ใด

หากไม่ใช่ HTML ให้วางไว้ในโฟลเดอร์และเพิ่มลิงค์ URL ลงไป

HTML ให้โครงสร้าง 'ศักยภาพ' สำหรับการจัดวางและยังให้ 'การเชื่อมโยง' ระหว่างรายการความรู้ / เนื้อหา (รวมถึงกลไกโครงสร้างพื้นฐานเช่นความสามารถในการสร้างเมนูตารางของเนื้อหาและอื่น ๆ ) ด้วย HTML ตอนนี้ผู้ใช้แต่ละคนสามารถทำได้ เรียกใช้เว็บเซิร์ฟเวอร์ขนาดเล็กบนเครื่องของพวกเขาไม่ว่าจะเป็น lighttpd หรือสิ่งเล็ก ๆ หรือเพียงแค่เต็มไปด้วย Apache หรือ IIS

เครื่องของเราทุกคนมีความน่ากลัวสำหรับการให้บริการ HTML พื้นฐานและทำงานได้ดีพอสำหรับเรา

ไวยากรณ์ MARKDOWN

เราใช้ MARKDOWN, Textish และหรือreStructuredTEXTในเวอร์ชัน bastardised เพื่อให้น้ำผลไม้ 'สร้างสรรค์' ของเราเขียนเอกสารโดยไม่ต้องกังวลกับ HTML

นอกจากนี้ยังหมายความว่าทุกคนสามารถใช้โปรแกรมแก้ไขรายการโปรด (ฉันใช้ Scintilla บน Windows และ * ระวัง) ในขณะที่คนอื่น ๆ ที่นี่ใช้ vi / vim

ระบบการกำหนดเวอร์ชันแบบกระจาย

เราใช้Gitเพื่อ 'แจกจ่าย' เอกสารระหว่างผู้ใช้ โอ้และเราก็ใช้ความสามารถในการกำหนดเวอร์ชันด้วย

ข้อได้เปรียบที่สำคัญสำหรับเราคือเราทุกคนสามารถทำงานในการอัปเดตเอกสารโดยไม่ต้องเชื่อมต่อกับเซิร์ฟเวอร์และไม่ต้องเผยแพร่งานที่เสร็จสมบูรณ์ เราทุกคนสามารถทำงานในส่วนเดียวกันของเอกสารหรือส่วนต่าง ๆ หรือเพียงแค่ใช้ข้อมูล

ส่วนตัวฉันเกลียดการผูกติดอยู่กับเซิร์ฟเวอร์เพื่ออัพเดทบล็อกให้วิกิของคนเดียว Git ทำงานได้ดีสำหรับเรา

แสดงความคิดเห็นในเวิร์กโฟลว์

ดูเหมือนว่า Wiki จะเป็น "แฟชั่น" สำหรับการเผยแพร่ความรู้ / การประมวลความรู้ แต่เมื่อมีการแสดงความคิดเห็นในที่อื่นกระบวนการทั้งหมดยากที่จะรักษาและค้นหาการผสมผสานของเครื่องมือที่รองรับความต้องการของทีมได้ดีที่สุดและยั่งยืนจะต้องใช้เวลา

ทางออกที่ดีกว่าเพิ่งถูกค้นพบและไม่ได้รับคำสั่ง

เราเริ่มใช้DokuWiki ในที่ที่ฉันทำงาน

จากเว็บไซต์ของ Dokuwiki:

DokuWiki นั้นเป็นมาตรฐานที่ง่ายต่อการใช้ Wiki โดยมีจุดประสงค์หลักในการสร้างเอกสารทุกประเภท มันมีเป้าหมายที่ทีมนักพัฒนากลุ่มงานและ บริษัท ขนาดเล็ก มันมีไวยากรณ์ที่เรียบง่าย แต่มีประสิทธิภาพซึ่งทำให้แน่ใจว่าดาต้าไทล์ยังคงสามารถอ่านได้นอก Wiki และลดการสร้างข้อความที่มีโครงสร้าง ข้อมูลทั้งหมดจะถูกเก็บไว้ในไฟล์ข้อความล้วน - ไม่จำเป็นต้องใช้ฐานข้อมูล

ฉันพบว่า Dokuwiki ใช้งานได้ง่ายที่สุดเพราะไม่ต้องใช้ฐานข้อมูลและติดตั้งง่าย นอกจากนี้ยังมีโมดูล Add-in ที่เปิดใช้งานให้ใช้การเข้าสู่ระบบบัญชี Active Directoryที่มีอยู่ของฉันแทนที่จะต้องสร้างบัญชีสำหรับทุกคนซึ่งเป็นข้อดีอย่างมากต่อระบบ wiki อื่น ๆ ที่ฉันพบ นอกจากนี้ยังมีการควบคุมเวอร์ชันทั่วไปซึ่งคุณสามารถดูได้ว่าใครโพสต์ที่ใดและมีความสามารถในการย้อนกลับไปเป็นเวอร์ชันก่อนหน้าได้ง่ายถ้าจำเป็น นอกจากนี้ยังมีหน้าแรกที่ปรับแต่งได้ซึ่งคุณสามารถเปลี่ยนเนื้อหาประเภทใดก็ได้ที่เหมาะกับสภาพแวดล้อมของคุณมากที่สุด

Doku Wikiหรือ Sharepoint สำหรับสิ่งอื่นที่เข้ากับแผนภูมิ

คุณคุ้นเคยกับการโพสต์บน wiki อย่างรวดเร็วและไวยากรณ์ไม่ซับซ้อนนัก มันง่ายมากในการจัดระเบียบข้อมูลและทำให้ง่ายต่อการค้นหาในภายหลังโดยบุคคลอื่น

ฉันใช้ visio เพื่อสร้างกราฟสำหรับคำอธิบายที่ชัดเจนยิ่งขึ้น (ส่งออกเป็น JPEG)

เรากำลังใช้วิกิ อันที่จริงแล้วเรากำลังใช้ MediaWiki ด้านบนของ MediaWiki เรามีส่วนขยาย Semantic Mediawikiซึ่งจริง ๆ แล้วเปลี่ยน MediaWiki ของเราเป็นสิ่งที่ฐานข้อมูลที่พิมพ์อย่างหลวม ๆ ที่เราสามารถค้นหาด้วยหมวดหมู่ชื่อเนื้อหา ฯลฯ

ตัวอย่างเช่นสมมติว่าฉันต้องการดูชื่อเครือข่ายทั้งหมดที่กำหนดเส้นทางผ่าน Cluster F. ทั้งหมดที่ฉันต้องทำคือใช้พิเศษ: หน้าถามเพื่อสอบถาม [[หมวดหมู่: cname]] [[ปลายทาง :: cluster_f]] .. . และมันจะส่งคืนเพจทั้งหมดที่ถูกจัดหมวดหมู่เป็น cname โดยมีปลายทางเป็น cluster_f

เราสนับสนุนลูกค้าสองร้อยรายที่แตกต่างกันอย่างมากดังนั้นการมีเอกสารดังกล่าวในที่ส่วนกลาง (และมีการเชื่อมโยงข้ามกันเพื่อให้กรณีพิเศษที่มีการบันทึกไว้และผูกติดอยู่กับภาพรวม) เป็นสิ่งที่มีประโยชน์มาก เห็นได้ชัดว่าเอกสารของเราต้องได้รับการบำรุงรักษา แต่คุณสามารถใช้วิธีการ 'ดูแลสวน' เพื่อการบำรุงรักษาได้มากขึ้นเนื่องจากชุดเครื่องมือ mediawiki สำหรับการรักษาชุดข้อมูลขนาดใหญ่ในปัจจุบันนั้นค่อนข้างเป็นผู้ใหญ่แล้ว

ด้วยปลั๊กอินที่ถูกต้องTracสามารถกลายเป็นตั๋วรวมและระบบวิกิ ทำให้ตั๋วของคุณเชื่อมโยงไปยังบทความ wiki และในทางกลับกันได้ง่าย

ปลั๊กอินที่ฉันชอบ:

• ปลั๊กอินตั๋วเอกชน Trac ถูกสร้างขึ้นเพื่อเป็นฐานในการจองตั๋วและการตอบรับของพวกเขาเป็นสาธารณะ ไม่เหมาะสมกับระบบตั๋ว IT แต่ปลั๊กอินนี้จะแก้ไข
• ปลั๊กอิน Trac WYSIWYG มาเผชิญหน้ากันผู้คนส่วนใหญ่จะไม่เรียนรู้ wikisyntax เพื่อทำให้คุณมีความสุข สิ่งนี้จะช่วยให้พวกเขาเห็นสิ่งที่คุณเห็นคือสิ่งที่คุณได้รับสำหรับทั้งตั๋วและหน้าวิกิ

มีการปรับแต่งเพิ่มเติมสำหรับ Trac ค่อนข้างน้อย การติดตั้งและปรับแต่งระบบ Trac นั้นไม่ยากสำหรับคุณ!

ในงานก่อนหน้าของฉันฉันใช้ Twiki มันทำงานค่อนข้างดี

ถัดจากนั้นฉันมักจะทำให้งานส่วนใหญ่โดยอัตโนมัติและจัดทำเอกสารสคริปต์ (ไม่เสมอกับความกระตือรือร้นมาก แต่ยัง ... ) สคริปต์การเขียนสคริปต์สามารถทำได้ง่ายในขั้นตอนการออกแบบดังนั้นจึงไม่มีค่าใช้จ่ายจริง ...

การรวมกันของทั้ง (และการใช้การควบคุมเวอร์ชันสำหรับสคริปต์) ทำได้ดีพอสมควร

การผสมผสานของ JIRA การรวมตัวและเอกสาร Word

ความรู้ด้านสถาบัน

เราเริ่มด้วยเอกสาร จากนั้นเราเก็บบางส่วนไว้ในไลบรารี Sharepoint จากนั้นเราก็ย้ายไปที่ Sharepoint wiki ฉันชอบวิธีการที่มีแรงเสียดทานต่ำของ wiki ในการอัพเดตสิ่งต่าง ๆ อย่างรวดเร็วแม้ว่าวิกิของ Sharepoint จะปล่อยให้บางสิ่งเป็นที่ต้องการในการสนับสนุนกราฟิกและการจัดรูปแบบการสนับสนุนสำหรับสิ่งต่าง ๆ เช่นตาราง ใช้ได้ดีกับข้อความและเครื่องมือแก้ไขในตัวอนุญาตให้ใช้การจัดรูปแบบ HTML พื้นฐานและรายการสั่งซื้อ / ไม่เรียงลำดับ มีทางเลือกต้นทุนต่ำอื่น ๆ ใน Sharepoint

นอกจากนี้เรายังมีฐานความรู้แบบไม่เป็นทางการสำหรับตั๋วสนับสนุนของเราในซอฟต์แวร์ช่วยเหลือของเราคือ Track-It ของ Numara มันไม่สมบูรณ์แบบ แต่ใช้งานได้ดี

การให้พนักงานใช้ความรู้เชิงสถาบัน

ฉันจะเห็นด้วยกับการประเมินของคุณว่าการรับความรู้เชิงสถาบันเป็นเพียงส่วนหนึ่งของการต่อสู้ หากองค์กรและคนของคุณไม่คุ้นเคยกับ "ค้นคว้าก่อนถามสอง" จากนั้นคุณจะพบว่าวิธีการแบบเดิม ๆ ทุกคนจะยังคงมองไปที่ผู้เชี่ยวชาญอย่างเป็นทางการและไม่เป็นทางการเพื่อหาคำตอบและสำหรับบางคนมันจะง่ายกว่าเสมอ คนที่อยู่ถัดจากคุณมากกว่าที่จะค้นหาด้วยตัวเอง

การจัดการกับสิ่งนี้จะเกี่ยวข้องกับการจัดการการเปลี่ยนแปลงบางอย่าง เช่นความคิดริเริ่มการเปลี่ยนแปลงที่ประสบความสำเร็จส่วนใหญ่มีผลกระทบมากกว่าแค่ทีมเล็ก ๆ มันจะช่วยให้มีการรับรองและการสนับสนุนจากผู้จัดการ คุณต้องปลอมแปลงพฤติกรรมใหม่ในสองทิศทาง บางคนต้องการที่จะรวบรวมความรู้และผู้คนจำเป็นต้องใช้มัน ยิ่งยากขึ้นคือผู้คนยังต้องรักษาข้อมูลนั้นให้ทันสมัยอยู่เสมอ

เพียงแค่ความคิดบางอย่าง: อาจจะต้องมีการสนับสนุนในรูปแบบของนโยบายอย่างเป็นทางการที่ระบุว่าตั๋วที่ได้รับการแก้ไขและปัญหาจะต้องมีการบันทึกไว้ในฐานความรู้หรือวิกิก่อนที่จะพิจารณาปิด นอกจากนี้ผู้นำความรู้ที่มักถามคำถามไม่ควรเสนอคำตอบเสมอ พวกเขาต้องชี้ผู้คนไปที่วิกิและทำให้พวกเขาคุ้นเคยกับการตรวจสอบที่นั่นก่อน อีกสิ่งหนึ่งคือการให้ข้อมูลแก่ผู้ใช้สำหรับการช่วยเหลือตนเองดังนั้นปัญหาอาจได้รับการแก้ไขก่อนที่จะกลายเป็นอีกหนึ่งรายการที่เจ้าหน้าที่ด้านเทคนิคต้องดำเนินการ

สิ่งที่จะดีสำหรับระบบแผนกช่วยเหลือของเราคือมีระบบที่คล้ายกับ StackOverflow และ ServerFault: เมื่อพิมพ์คำถามเครื่องมือค้นหาจะค้นหารายการที่คล้ายกันและเสนอให้พวกเขาเพื่อให้ผู้ใช้สามารถดูได้ก่อนที่จะส่งคำถาม

ในที่ทำงานสองแห่งสุดท้ายของฉันฉันใช้ Wiki ของ SharePoint พร้อมกับห้องสมุดเอกสารที่มีเอกสารบางอย่าง (เช่น DRP และแผนการอัปเกรดครั้งเดียว) ซึ่งไม่สามารถสร้างเป็นเอกสาร Wiki ได้อย่างง่ายดาย เอกสารเหล่านั้นมีลิงก์จากภายใน Wiki Wiki มีข้อดีหลายประการในด้านนี้เนื่องจากผู้คนสามารถแก้ไขได้การกำหนดเวอร์ชันในตัวสามารถค้นหาและเข้าถึงได้ง่าย ฯลฯ สำหรับการเขียนบันทึกย่อหรือแนวคิดอย่างรวดเร็วฉันจะใช้ OneNote หรือไวท์บอร์ด

ฉันเคยสร้างฐานความรู้มาก่อนในรูปแบบฟอรัม (ทั้งใน Lotus Notes และ MS Sharepoint) แต่ฉันต้องบอกว่ามีเพียงคนที่ไม่ค่อยมองผ่านพวกเขาเพื่อดูว่าปัญหาบางอย่างได้รับการแก้ไขแล้วหรือไม่ โซลูชันดังกล่าวต้องมาจากวันแรกด้วยเครื่องมือค้นหาที่แข็งแกร่งและมีประสิทธิภาพ

หากคุณต้องการสร้างเอกสารที่สามารถใช้งานได้ในช่วงวันหยุดพักผ่อนให้เขียนเอกสารเหล่านั้นราวกับว่าคุณกำลังพยายามที่จะสอนผู้ปกครองของคุณ นี่ไม่ใช่การพิสูจน์คนโง่ 100% แต่บางครั้งก็ช่วยได้ ขึ้นอยู่กับว่าใครอ่าน

Sharepoint นั้นดี

มันเป็นคุณสมบัติการค้นหาที่มีความสามารถในการจัดทำดัชนีเอกสารเกือบทุกประเภททำให้การค้นหาเอกสารนั้นง่ายมาก

มันสามารถทำเทมเพลตได้เช่นกันซึ่งทำให้ง่ายขึ้นตัวอย่างเช่นถ้าคุณมีแผ่นข้อมูลมาตรฐานสำหรับแต่ละเซิร์ฟเวอร์ที่คุณสร้าง

นอกจากนี้ยังสามารถจัดทำเอกสารของคุณเพื่อให้คุณมีประวัติการตรวจสอบการเปลี่ยนแปลงเอกสาร

รวมถึงไฟล์ที่มีอยู่ในไลบรารีเอกสารที่สามารถเข้าถึงได้ผ่านทางเว็บในมุมมองหรือผ่านการแชร์ทั้งหมดออกจากกล่อง

เราใช้MediaWiki (กับ fckeditor) มาหลายปีแล้ว แต่ฉันต้องบอกว่ามันจะดีถ้าการจัดการรูปภาพ (เช่นภาพหน้าจอ) นั้นง่ายกว่า และในขณะที่มีความสามารถในการค้นหาเป็นสิ่งสำคัญ - ฉันค้นหาการค้นหาของ MediaWiki มักจะพลาดหน้า อาจเป็นเพียงเรื่องของการเรียนรู้ที่จะค้นหาได้ดีขึ้น (ซึ่งชนิดของการเอาชนะวัตถุประสงค์ของการมีวิธีที่ง่ายสำหรับคนอื่น ๆ ที่จะทำงานของคุณ)

ตอนนี้เรากำลังพูดถึงการย้ายทุกสิ่งทุกอย่างไปยังMS Sharepointแม้ว่าจะไม่ใช่วิกิของพวกเขา ฉันคิดว่า Sharepoint สามารถทำการค้นหาเอกสารแบบเต็มในลักษณะที่ขัดแย้งกับข้อได้เปรียบบางอย่างของวิกิดังนั้นเราจะเห็นว่าสิ่งนี้จะเกิดขึ้นที่ใด

(ไม่ได้รอกระบวนการโอนย้ายเอกสารปัจจุบันทั้งหมดของเราแม้ว่า :))

เรากำลังใช้วิกิ แน่นอนว่าไวยากรณ์ใช้เวลาเล็กน้อยในการทำความคุ้นเคย แต่สิ่งที่เราใช้ (twiki) เก็บข้อมูลทั้งหมดเป็นไฟล์ข้อความ สิ่งนี้ช่วยให้เราสามารถอ่านพวกเขาได้อย่างง่ายดายในกรณีที่เกิดภัยพิบัติเนื่องจากเราสามารถกู้คืนได้ทุกที่และค้นหาจากบรรทัดคำสั่งผ่าน grep และอ่านในโปรแกรมแก้ไขข้อความใด ๆ ที่เราชอบ

เซิร์ฟเวอร์ทุกเครื่องมีหน้าพร้อมคอลเลกชันมาตรฐานของหน้าย่อยสำหรับข้อมูลการจัดการการเปลี่ยนแปลงการเริ่มต้น / ปิดเครื่องและหมายเหตุการกำหนดค่ารวมถึง dns, ไฟร์วอลล์และข้อมูลสินทรัพย์

เราพร้อมที่จะย้ายไปใช้บริการ Sharepoint บางเวอร์ชันเพื่อให้เราได้รับการเผยแพร่เอกสารคำที่มีอยู่ในเซิร์ฟเวอร์ทั้งสามและใครจะรู้ว่ามีโฟลเดอร์กี่โฟลเดอร์ ขณะนี้เรามีสเปรดชีต excel ขนาดใหญ่ที่มีไฮเปอร์ลิงก์ไปยังเอกสารที่อธิบายไว้ในนั้น

ไม่ใช่วิธีที่ดีที่สุดที่จะทำ แต่เมื่อ บริษัท เริ่มต้นพวกเขาไม่เคยวางแผนว่าจะจัดการกับเอกสารภายในและปล่อยให้แต่ละกลุ่มตัดสินใจว่าจะเรียงลำดับและจัดเก็บเอกสารของตนเองได้อย่างไร ตอนนี้เรากำลังพยายามรวมเข้ากับระบบแบบครบวงจรซึ่งจะเป็นหนึ่งในข้อเสนอของ Sharepoint

ในองค์กรพัฒนาเอกชนที่ซึ่งฉันทำงานเราแค่ใช้ไฟล์ข้อความที่วางไว้ในโฟลเดอร์สำหรับกระบวนการที่สำคัญ โดยส่วนตัวในฐานะผู้ดูแลระบบ / นักพัฒนาเว็บไฮบริดฉันใช้ฐานความรู้ของไฟล์ข้อความที่กระจัดกระจายอยู่ในไดเรกทอรีต้นไม้นั่นคือMemexของฉันและฉันเขียนทุกอย่างลงในนั้น (ส่วนตัวทำงาน ฯลฯ ) รูปแบบนี้ง่ายต่อการจัดการโดยใช้Jeditมีดสวิสกองทัพจริงสำหรับการประมวลผลข้อความฉันได้พบปลั๊กอินเค้าร่างการพับโค้ดและคุณลักษณะไฮเปอร์สเปเซอร์ที่ขาดไม่ได้ ทั้งหมดนี้สำรองอย่างปลอดภัยโดย rsync ไปยังเซิร์ฟเวอร์ระยะไกลที่เชื่อถือได้ ssh

เชื่อมโยงกับMakelink Firefox Extensionและคุณมีโปรแกรมจัดการบุ๊คมาร์คที่สมบูรณ์แบบ

เราใช้flexwikiซึ่งเป็น dotnet และโอเพ่นซอร์ส

เอ่อ ... แล้ว Fogbugz ล่ะ? :)

เรากำลังใช้ ScrewTurn สำหรับเนื้อหาและ SharePoint เพื่อจัดเก็บเอกสาร / ภาพ

มีบางสิ่งที่น่าสนใจที่นี่ - ฉันชอบสิ่งหนึ่งเกี่ยวกับรหัสผ่านในที่ปลอดภัย

เราใช้ไฟล์ข้อความร่วมกันเพื่อค้นหาอย่างรวดเร็วด้วย grep และ SharePoint สำหรับชุดเอกสารเชิงลึกที่จัดระเบียบมากขึ้น (Visio diagrams, ฯลฯ )

ในฐานะลูกค้า Google Apps (Enterprise) เราใช้ heck out จาก Google Sites - wiki "รส" ใช้งานง่ายและเรามีการยอมรับที่ดีจากผู้ดูแลระบบและนักพัฒนา

ฉันไม่เห็นคำถามนี้ก่อนที่จะตอบคำถามอื่นแต่เราไปกันเลย

เราใช้เครื่องมือและวิธีการมากมาย

• ข้อกำหนดการใช้งานสำหรับส่วนประกอบโครงสร้างพื้นฐานและซอฟต์แวร์
• สองบรรจบ Wikis หนึ่งสำหรับเอกสารภายในองค์กร (นโยบายขั้นตอนโครงสร้างพื้นฐานภายในและไอที ฯลฯ ) และอีกหนึ่งสำหรับผลิตภัณฑ์ซอฟต์แวร์โอเพนซอร์ซของเรา
• การทดสอบRSpecและแตงกวา ซอฟต์แวร์ของเราส่วนใหญ่เขียนใน Ruby และเราฝึกฝนBDD / TDDดังนั้นการทดสอบข้อมูลจำเพาะทำให้เกิดรหัสจริงและเอกสารเช่นกัน
• เอกสารประกอบ Inline code เราใช้มาร์กอัปRDocในการแสดงความคิดเห็นรหัส
• การจัดการการกำหนดค่าที่สำแดง ( Chef ) เซิร์ฟเวอร์ทั้งหมดของเราได้รับการจัดการโดย Chef ซึ่ง "จัดทำเอกสารด้วยตนเอง" ผ่านทรัพยากรที่มีการแปลในสูตรอาหารและตำราอาหาร

เราต้องการที่บรรจบกันเพราะมันเป็นอย่างมากที่มีความยืดหยุ่นและมีประสิทธิภาพและคุณลักษณะที่สมบูรณ์รวมทั้งจะผูกเป็นซอฟต์แวร์การจัดการตั๋วที่เราชอบ, จิระ

ใน บริษัท ก่อนหน้านี้ที่ฉันเคยทำงานฉันใช้เครื่องมือและวิธีการที่หลากหลายและหลายคนพยายามที่จะอยู่กับทรัพยากรที่จับเดียว (เช่น Wiki) สำหรับทุกสิ่ง ปัญหาที่มีการบันทึกหัวข้อต่างๆด้วยเครื่องมือเดียวที่ไม่เหมาะกับการครอบคลุมหัวข้อนั้นหมายความว่าหลายสิ่งจะไม่ได้รับการบันทึกเลยเพราะเป็นการยากที่จะย้ายข้อมูล ในฐานะที่เป็น Unix / Linux geek ฉันเชื่อว่าแต่ละงานต้องใช้เครื่องมือเฉพาะและเครื่องมือนั้นควรเหมาะสมกับงานนั้นเป็นอย่างดี

คำถามนี้เป็นคำถามที่ดีมากซ้ำกับคนนี้และผมย้ายคำตอบของฉันมี

ฉันทำเอกสารส่วนใหญ่สำหรับ บริษัท ของฉันและรูปแบบที่ก่อตั้งขึ้นเมื่อฉันเริ่มทำงานที่นี่คือ MS Word สำหรับต้นฉบับที่แก้ไขได้ส่งออกเป็น PDF สำหรับรุ่นทั่วไปที่อ่านได้อย่างเดียว มันใช้งานได้ดีสำหรับโครงการที่มีคนเพียงคนเดียวที่กำลังอัปเดตเอกสารและเนื่องจากคนคนนั้นมักจะเป็นฉันการจัดการจึงไม่จำเป็นต้องเปลี่ยน

เราได้เริ่มทำเอกสารข้อบกพร่องและงานที่จะเกิดขึ้นกับTracในขณะที่ใช้ส่วนขยาย "Peer Review" เพื่อตรวจสอบโค้ด สิ่งนี้ได้รับการยอมรับอย่างมากจากทีมงานของเราเพราะเป็นเรื่องง่ายที่จะทำงานร่วมกันและใช้งานง่าย สมาชิกในทีมอีกสองสามคนแสดงความปรารถนาที่จะเริ่มทำงานร่วมกันมากขึ้นด้วยข้อมูลจำเพาะขั้นตอนการทดสอบและคู่มือดังนั้นเราจึงมองหา DocBook / XML ที่ส่งออกเป็น PDF สำหรับเอกสารสาธารณะเช่นคู่มือและหน้า Trac WIKI สำหรับเอกสารภายในเช่นข้อกำหนดและ ขั้นตอนการทดสอบ

ในใจของฉันปัญหาที่ใหญ่ที่สุดเมื่อเลือกรูปแบบเอกสารคือ:

1. มันง่ายที่จะสร้าง?
2. ดูแลรักษาง่ายไหม
3. มันง่ายต่อการดูแลหรือไม่ถ้ามีคนเขียนมัน?
4. สามารถส่งออก / แปลงเป็นรูปแบบอื่น ๆ ได้โดยไม่ต้องยุ่งยากอะไรมาก?

1-3 ทำให้ชีวิตของฉันง่ายขึ้นและมีความสำคัญต่อการผลิตเอกสารอย่างรวดเร็วโดยไม่ต้องเสียสติ ฉันคิดว่าอันที่สี่สำคัญที่สุดสำหรับลูกค้าเพราะรูปแบบจะเปลี่ยนไปอย่างต่อเนื่อง รูปแบบ Microsoft Word 2003 จะไม่คงอยู่ตลอดไปและการใช้งาน PDF ในปัจจุบันของเรา ฉันต้องการตรวจสอบให้แน่ใจว่าลูกค้าของเราทุกคนสามารถอ่านเอกสารของเราได้ไม่ว่าระบบปฏิบัติการหรือตัวอ่านเอกสารที่พวกเขาเลือกจะเป็นอะไร

เราใช้ MediaWiki กับปลั๊กอินต่าง ๆ รวมถึง SemanticMediaWiki SMW เป็นสิ่งที่ดีเพราะเปลี่ยนการติดตั้ง MediaWiki ของเราเป็นฐานข้อมูลเชิงสัมพันธ์แบบฟรีฟอร์มขนาดใหญ่ที่สามารถสอบถามได้ตามต้องการ ต้องการทราบว่าเว็บไซต์ใดอยู่บนเซิร์ฟเวอร์ ไปที่หน้าของมัน ต้องการทราบว่าเว็บไซต์ใดบ้างที่โฮสต์อยู่บนเซิร์ฟเวอร์ เรียกใช้แบบสอบถามและจะเลือกชื่อหน้าตามแท็กที่เหมาะสมในแต่ละหน้าของเว็บไซต์

ฉันจะตอบไม่ใช่ด้วยระบบเอกสารที่ฉันเคยใช้ แต่มีบางอย่างที่ฉันเคยเห็นใช้แล้วซึ่งฉันพบว่าดีมาก: http://stackexchange.com/

stackexchange เป็นแพลตฟอร์มถาม - ตอบที่ทำงานภายใต้ serverfault (ในทางเทคนิคแล้วมันไม่เหมือนกันทุกประการ แต่สำหรับจุดประสงค์ของเราที่นี่เราสามารถถือว่ามันเหมือนกัน)

Fogbugz ใช้มัน

มีโพสต์บล็อกที่น่าสนใจจากพนักงาน Fogbugz ที่ฉันพบคำพูดเหล่านี้:

สำหรับวัตถุประสงค์ทั้งหมดนอกเหนือจากรายละเอียดผลิตภัณฑ์ฉันคิดว่าวิกิขององค์กรและรูปแบบการสนทนาได้รับการจัดการที่รุนแรง

...

เนื่องจากเราเริ่มใช้ FogBugz.StackExchange.com เป็นแพลตฟอร์มสนับสนุนของเราฉันไม่เคยตอบคำถามเดียวกันสองครั้ง เรายังมีเซิร์ฟเวอร์ SE ภายในที่เราใช้สำหรับถาม - ตอบแบบไม่เปิดเผยต่อสาธารณะและใช้หลักการเดียวกันกับที่นั่น

พวกเขาใช้ stackexchange สำหรับฐานความรู้ของลูกค้าและฐานความรู้ภายใน

ฉันสนใจที่จะดูว่าแพลตฟอร์มถามตอบแลกเปลี่ยนความรู้ดังกล่าวจะแทนที่วิกิขององค์กรหรือไม่

ที่นายจ้างคนก่อนหน้าของฉันฉันใช้ไฟล์ Word, Excel และ Visio รวมกันในโฟลเดอร์ สำเนาทุกอย่างถูกเก็บไว้ในแฟ้มในโต๊ะทำงานของฉัน ฉันเป็นคนไอทีคนเดียวดังนั้นจึงไม่มีความจำเป็นที่คนอื่น ๆ จะสามารถเข้าถึงข้อมูลได้

ที่นายจ้างปัจจุบันของฉันเราใช้ Macola ES โดย Exact Software แต่ฉันยังคงต้องการเขียนเอกสารของฉันใน Word และอัปโหลดไปยัง Macola เป็นไฟล์แนบแทนที่จะใช้โปรแกรมแก้ไขเอกสารในตัว

ในที่ทำงานของฉันฉันเอา ScrewTurn Wiki ไปที่เซิร์ฟเวอร์ Windows dev ของเราและเชื่อมต่อกับ SQL Server ของเรา มันใช้งานได้ดีทำงานได้อย่างรวดเร็วและส่วนใหญ่ไม่ได้ใช้วิธีการจัดทำเอกสาร ในอีกสองสัปดาห์นับตั้งแต่มีการนำไปใช้งานเราได้เพิ่มข้อมูลประมาณ 60 หน้าและสำหรับทีมของเราเท่านั้น (ประมาณ 10 คน)

จนถึงตอนนี้เราเก็บข้อมูลเกี่ยวกับโครงการปัจจุบันและโครงการที่ผ่านมาและได้เริ่มเพิ่มข้อมูลเกี่ยวกับแอปพลิเคชันเช่นวิธีการสร้างตั้งแต่เริ่มต้น URL และข้อมูลสำคัญอื่น ๆ สำหรับ dev ใหม่ให้กับทีม

หนึ่งในหน้าโปรดของฉันบนวิกิคือหน้าเครื่องมือและไลบรารี ที่นั่นเราได้เริ่มเพิ่มข้อมูลเกี่ยวกับเครื่องมือเพิ่มประสิทธิภาพการทำงานและไลบรารี่ที่เราใช้บ่อยมากตัวอย่างเช่น grepWin สำหรับการค้นหาข้อความใน Windows

ฉันขอแนะนำอย่างเต็มที่ให้ตรวจสอบขอบเขตทั้งหมดของ wiki ที่มีอยู่และค้นหารายการที่เหมาะสมกับการใช้งานฟังก์ชั่นและสภาพแวดล้อมในการปรับใช้ที่คุณต้องการ ฉันเลือก ScrewTurn เพราะใช้งานง่ายและเรามีห้องว่างมากมายใน WinServer ท้องถิ่นของเรา แต่ YMMV

เราใช้ Confluence เป็น wiki และ sharepoint สำหรับเอกสารในบางกรณี ฉันเชื่อว่ารูปแบบวิกิออนไลน์เป็นรูปแบบที่ต้องการเมื่อคุณต้องการแบ่งปันข้อมูลนี้อย่างกว้างขวางและมีความสำคัญมากกว่าเมื่อเอกสารจะถูกแก้ไขและปรับปรุงบ่อยครั้งมาก ดังนั้นฉันคิดว่าบทความฐานความรู้ควรใส่ไว้ในวิกิ

ขณะนี้เรากำลังย้ายข้อมูลของเราจากเอกสารต่าง ๆ กระจายไปทั่วเครือข่ายไปยังสองแห่ง:

1. wiki มีอยู่ในอินทราเน็ตของเรา
2. สำเนาของข้อมูลที่เกี่ยวข้องกับเซิร์ฟเวอร์เฉพาะในเซิร์ฟเวอร์ / ไดเรกทอรีราก

สำหรับแผนภาพเครือข่าย, Notepad เครือข่าย

นอกจากนี้ในขณะที่บันทึกสิ่งที่จำไว้เพื่อบันทึกว่าทำไมบางสิ่งบางอย่างถูกกำหนดค่าเหมือนมัน สิ่งนี้ช่วยป้องกันความคิดที่ดูเหมือนเป็นความคิดที่ดีไม่ให้เปลี่ยนเป็นความผิดพลาด

เราพบว่า MediaWiki เป็นตัวเริ่มต้นที่ช้า แต่เมื่อคนภายนอก IT ได้รับความสะดวกในการเพิ่มความคิดเห็นการเปลี่ยนแปลงการแก้ไข ฯลฯ มันก็กลายเป็นสิ่งที่ขาดไม่ได้ นักพัฒนากำลังใช้มันสำหรับเอกสารภายในแผนกสิ่งอำนวยความสะดวก สำหรับการโพสต์ประกาศ ฯลฯ มันโตขึ้นกว่าการเป็นแค่เครื่องมือเอกสารไอทีเท่านั้น