İşinizi, süreçlerinizi ve ortamınızı nasıl belgeliyorsunuz?

Wiki formatı kullanıyor musunuz? Eğer öyleyse, hangi ürün? (MediaWiki, Confluence, Sharepoint vs.)

Bir bilgi tabanı yarattınız mı? (Problem / çözüm odaklı kısa belgeler.)

İşe yarayan belgeler yaratırken ne gibi zorluklarla karşılaşıyorsunuz, bu nedenle tatildeyken arama yapmıyorsunuz?

Benim için, dokümantasyonun yapılmasıyla ilgili belli miktarda örgütsel "atalet" olduğunu görüyorum. Bir görevi yerine getirebilecek, sonra işi nasıl yaptıklarını düşünecek ve başkasının yapabileceği şekilde tanımlayabilecek farklı türde bir insan gibi görünüyor - sizin için "meta" kullanmaya zorlayan türler ve herkes bunu yapmaktan rahat değil.

Güncelleme

Şu ana kadarki cevaplar:

• izdiham
• Flexwiki
• FogBugz
• Mediawiki (fckeditor gibi eklentilerle)
• Paylaşım Noktası
• TWiki
• Word / Excel / Visio Belgeleri
• Belgelenmiş Komut Dosyaları

Düzenleme: Ağınızı gizlice izleme sisteminizle belgelendirmiyor musunuz? Nagios, ağınızın yapısını yansıtmak için ebeveyn direktifinin kullanımını her zaman teşvik etmiştir ve notes_url yönergesi, bir wiki veya başka bir tarayıcı tabanlı belgeye bağlanmanıza izin vermek için tasarlanmıştır. Yani burada "dokümantasyon", izleme sisteminin "canlı dokümanı" ile bir vikideki daha detaylı, çevrimdışı dokümantasyon arasında bölünmüştür. Nagios'a bakarak çok zaman harcadığım için, onu olabildiğince bilgilendirici hale getirmek için çaba sarf etmek mantıklı geliyor.

Takım hakkında yorum yapma.

Çevrimiçi wiki'leri denedik, ancak kişisel zevk alabileceğiniz, ancak belge yapısını içeren ve en önemlisi de dokümantasyon sunucusuyla bağlantı kurmanız gereken birtakım sınırlamalar bulduk.

Bağlantısız olmak, çevrimdışıysanız veya yerinde olsanız da ciddi bir sorundur (açık bir şekilde yerinde güvenli bir SSL bağlantısı ve benzeri bir durumla durumu azaltabilirsiniz).

Mevcut dokümantasyon sürecimiz:

• statik html üreteci
• markdown sözdizimi
• dağıtılmış versiyonlama sistemi

Dokümantasyon için 'resmi' bir düzenimiz var ve bu da menüler için yapı (ve görsel stil için ilgili CSS vb.) Sağlıyor.

Statik HTML Üreticisi

Cubictemp ve diğer çeşitli araçlara dayanan dahili bir statik html üreteci kullanıyoruz : pigmentler , dokümanlar .

Oluşturulan sayfalar (değil mi?) Açıkça çirkin görünüyor, çünkü çoğu / sysadmins / programcılar neyin estetik olarak güzel olduğunu biliyorlar, ancak böyle bir binada toplam koordinasyon eksikliği var.

Ancak bize html formatlama konusunda endişelenmenize gerek kalmadan, dosyaları batırırken veya indirirken 'sunucuda' nerede bulacağınız konusunda endişelenmenize gerek kalmadan yapılandırma dosyaları, örnek komut dosyaları, pdf, vb.

HTML değilse, onu klasöre bırakın ve bir URL bağlantısı ekleyin.

HTML, düzen için 'potansiyel' yapı sağlar ve aynı zamanda kritik olarak bilgi / içerik öğeleri (ayrıca menüler oluşturma, içerik tablosu gibi temel yapı mekanizmaları vb.) Arasında 'bağlantı' sağlar. makinelerinde küçük bir web sunucusu çalıştırın, ister lighttpd ister küçük, ister Apache veya IIS ile tamamen doluysa.

Tüm makinelerimiz temel html sunumu için homurdanıyor ve bizim için yeterince iyi çalışıyor.

MARKDOWN sözdizimi.

'Yaratıcı' meyve sularımızın HTML konusunda endişelenmenize gerek kalmadan dokümantasyon yazmasına izin vermek için MARKDOWN, Textish ve veya reStructuredTEXT'ın bastardleştirilmiş bir versiyonunu kullanıyoruz .

Bu aynı zamanda herkesin favori editörünü kullandığı anlamına gelir (diğerleri Windows'ta Scintilla kullanıyorum ve Nix), burada diğerleri vi / vim kullanıyor.

Dağıtılmış Versiyon Sistemi.

Dokümanları kullanıcılar arasında 'dağıtmak' için Git'i kullanıyoruz . Oh, ve biz de onun versiyonlama kapasitesini kullanıyoruz.

Bizim için en önemli avantaj, sunucuya bağlanmak zorunda kalmadan ve 'tamamlanmış' çalışmaları yayınlamak zorunda kalmadan dokümantasyonu güncelleme konusunda hepimizin çalışabilmesidir. Hepimiz belgelerin aynı kısımlarında veya farklı kısımlarında çalışabilir veya bilgileri tüketebiliriz.

Şahsen, blogları güncellemek için bir sunucuya bağlı kalmaktan nefret ediyorum, wiki bile. Git bizim için iyi çalışıyor.

İş Akışı Üzerine Yorum Yapma

Wiki'nin bilgi yayma / kodlama için "moda" olduğu görülüyor, ancak başka yerlerde de belirtildiği gibi tüm süreçlerin sürdürülmesi zorlaşıyor ve takımlarınızın ihtiyaçlarını en iyi şekilde destekleyen ve sürdürülebilir olan araçların karışımını bulmak zaman alacak.

Daha iyi çözümler keşfedilir ve zorunlu değildir.

Çalıştığım yerde DokuWiki'yi kullanmaya başladık .

Dokuwiki'nin web sitesinden:

DokuWiki, temelde her türlü dökümantasyonu oluşturmayı amaçlayan Wiki kullanımı basit, standartlara uygundur. Geliştirici ekipleri, çalışma grupları ve küçük şirketler hedefleniyor. Veri dosyalarının Wiki dışında okunabilir kalmasını sağlayan ve yapılandırılmış metinlerin oluşturulmasını kolaylaştıran basit ama güçlü bir sözdizimine sahiptir. Tüm veriler düz metin dosyalarında saklanır - veritabanı gerekmez.

Dokuwiki'yi uygulaması en kolay buldum çünkü veritabanı gerektirmiyor ve kurulumu kolaydı. Ayrıca, mevcut Active Directory hesap oturum açma bilgilerimi kullanmamı sağlayan eklenti modülleri de vardı; bunun yerine, herkes için hesaplar oluşturmak zorunda kaldım, bu da bulduğum diğer wiki sistemlerinin çok üzerinde büyük bir artı oldu. Ayrıca, kimin nerede ne gönderdiğini görebileceğiniz tipik sürüm kontrolü vardır ve gerektiğinde kolay eski bir sürüme geri dönme kabiliyetine sahiptir. Ayrıca, ortamınız için en uygun içerik türünü kolayca değiştirebileceğiniz, özelleştirilebilir bir giriş sayfası da içerir.

Grafiğe uyan diğer şeyler için Doku Wiki veya Sharepoint.

Bir wiki'ye göndermeye oldukça hızlı alışırsınız ve sözdizimi gerçekten çok karmaşık değildir. Bilgi düzenlemek ve daha sonra başkaları tarafından daha kolay bulunabilmesi çok kolaydır.

Daha net açıklamalar için grafikler oluşturmak için visio kullanıyorum (JPEG olarak dışa aktarın).

Bir wiki kullanıyoruz. Aslında, MediaWiki'yi kullanıyoruz. MediaWiki üzerine, elimizdeki Semantik Mediawiki uzantısı biz Kategori, başlık, içindekiler, vb ile sorgulayabilir aslında gevşek yazılan veritabanının şey haline bizim MediaWiki'yi döner yüklü,

Örneğin, Küme F üzerinden geçen tüm ağ adlarını görmek istediğimi varsayalım. Tek yapmam gereken, [[Kategori: cname]] [[destination :: cluster_f]] sorgusu için Özel: Sor sayfasını kullanmak. ve hedef olarak cluster_f olarak cname olarak sınıflandırılan tüm sayfaları döndürür.

Birkaç yüz ayrı müşteriyi destekliyoruz, bu nedenle bu belgelerin merkezi bir yerde olması (ve özel vakaların belgelenmesi ve bütünüyle bağlı kalması için çapraz bağlı olması) çok kullanışlı bir şey. Belli ki, dokümantasyonumuzun korunmasına ihtiyaç var, ancak bakım için 'bahçıvan' yaklaşımından daha fazla yararlanabilirsiniz, çünkü büyük bir veri kümesi akımını tutmak için ortam araç seti zaten oldukça olgun.

Doğru eklentilerle, Trac bir kombinasyon bilet ve wiki sistemi olabilir. Bu, biletinizin wiki makalelerine bağlanmasını ve tersini kolaylaştırır.

Sevdiğim birkaç eklenti:

• Özel Bilet eklentisi . Trac, tüm biletlerin ve cevaplarının halka açık olduğu bir hata tabanı olarak inşa edildi. Bu bir BT bilet sistemine uygun değil, ancak bu eklenti bunu düzeltir.
• Trac WYSIWYG eklentisi . Kabul edelim, çoğu insan sizi mutlu etmek için wikisyntax öğrenmeyecek. Bu onlara hem biletler hem de wiki sayfaları için 'ne görüyorsanız onu alırsınız' editörü verir.

Trac için birkaç özelleştirme daha var . Bir Trac sistemini kurmak ve kişiselleştirmek istediğiniz gibi değil!

Önceki çalışmamda Twiki kullandım. Oldukça iyi çalıştı.

Bunun yanında, çoğu görevi otomatikleştirme ve komut dosyalarını belgeleme eğilimindeyim (her zaman çok fazla heyecanla değil, yine de ...). Belgeleri tasarlama sürecinde kolayca belgelenir, bu nedenle gerçek bir ek yükü yoktur ...

Her ikisinin kombinasyonu (ve komut dosyaları için sürüm kontrolünü kullanarak), bu işi oldukça iyi yaptı.

JIRA, Confluence ve Word Belgelerinin bir karışımı.

Kurumsallaşma Bilgisi

Belgelerle başladık. Sonra bazılarını Sharepoint kütüphanelerinde sakladık. Son zamanlarda Sharepoint wiki'sine geçtik. Wiki'nin düşük sürtünmeli yaklaşımını olayları hızlı bir şekilde güncellerken seviyorum, ancak Sharepoint'in wikileri grafik desteği ve tablo gibi şeyler için desteği biçimlendirme konusunda bazı şeyler isteniyor. Metin için sorun yok ve yerleşik düzenleyici, bazı temel HTML biçimlendirmelerine ve sıralı / sıralanmamış listelerine izin veriyor. Sharepoint'in başka düşük maliyetli alternatifleri var.

Ayrıca, Yardım Masası yazılımımız Numara's Track-It'teki destek biletlerimiz için de bir tür gayrı resmi bilgi tabanına sahibiz. Mükemmel değil ama işe yarıyor.

Kurumsal Bilgiyi Kullanmaya Çalışanları Alma

Kurumsallaşan bilgiyi elde etmenin savaşın sadece bir parçası olduğu konusundaki değerlendirmenize katılıyorum. Kurumunuz ve halkınız "önce araştır, ikinci sor" a alışkın değilse, eski yolun geçerli olduğunu göreceksiniz: herkes hala resmi ve gayri resmi gurulara cevap aramaya devam edecek ve bazı insanlar için sormak her zaman daha kolay olacak kendi başınıza aramaktansa yanınızdaki kişi.

Bununla başa çıkmak bazı değişiklik yönetimi içerecektir; Küçük bir ekipten daha fazlasını etkileyen çoğu başarılı değişim girişimi gibi, yönetimsel onay ve destek almanıza da yardımcı olacaktır. Gerçekten iki yönde yeni davranış geliştirmelisin; birinin bilgiyi yakalaması ve insanların onu kullanması gerekir. Daha da zor olanı, insanların bu verileri güncel tutmaları gerektiğidir.

Sadece bazı fikirler: Muhtemelen çözülmüş biletlerin ve konuların kapalı kabul edilmeden önce bilgi tabanında veya wikide belgelenmesi gerektiğini belirten resmi bir politika biçiminde cesaretlendirme gerekecektir. Ayrıca, normalde soru sorulan bilgi liderleri her zaman talep üzerine cevap vermemelidir; insanları vikilere yönlendirmeleri ve ilk önce orayı kontrol etmelerine alışmaları gerekiyor. Bir diğer şey, verilerin kendi kendine yardım için kullanıcılara sunulmasını sağlamaktır, böylece teknik personelin hokkabazlık etmesi gereken başka bir öğe haline gelmeden önce bu sorun potansiyel olarak çözülebilir.

Yardım masası sistemimizin StackOverflow ve ServerFault ile benzer bir sisteme sahip olması iyi olur: bir soru yazarken, arama motoru benzer öğeleri bulur ve bunları sunar, böylece kullanıcılar soruyu göndermeden önce bile onlara bakabilir.

Son iki çalışma yerimde, Sharepoint'in Wiki'sini ve Wiki belgeleri olarak kolayca oluşturulamayacak belli belgeleri (DRP'ler ve bir seferlik yükseltme planları gibi) içeren bir belge kütüphanesinin yanı sıra kullandım. Bu belgelerin Wiki'den bağlantıları vardı. Wiki'nin bu alanda birçok avantajı vardır; birçok insanın düzenleyebildiği, versiyonlama yapılabildiği, kolayca aranabilir ve erişilebilir olduğu vb. Notları veya fikirleri hızla yazmak için OneNote veya beyaz tahta kullanırdım.

Daha önce bazı forumlarda forum formatında (hem Lotus Notes'ta hem de MS Sharepoint'te) yaratmıştım, ancak belirli bir sorunun çözülüp çözülmediğini görmek için nadiren insanların aradıklarını aradıklarını söylemeliyim. Böyle bir çözüm çok güçlü ve etkili bir arama motoru ile ilk günden gelmelidir.

Tatilde iken kullanılabilecek belgeler oluşturmak istiyorsanız, ebeveynlerinizden birine talimat vermeye çalışıyormuşsunuz gibi yazınız. Bu% 100 kusursuz değildir, ancak bazen yardımcı olur. Kimin okuduğuna bağlı.

Sharepoint güzel.

Bu arama özellikleri, neredeyse her tür belgeyi dizine ekleme yeteneğine sahiptir ve arama belgelerini gerçekten kolaylaştırır.

Örneğin, oluşturduğunuz her sunucu için standart bir bilgi sayfasına sahipseniz, bir şeyleri kolaylaştıracak bazı şablonlamalar da yapabilir.

Ayrıca belgelerinizi sizin için sürümlendirebilir, böylece belgelendirme değişikliklerinde denetim geçmişiniz olur.

Ayrıca, belge kitaplıklarında bulunan dosyalara web üzerinden, görünümden veya kutudan çıkardıkları bir unc paylaşımından erişilebilir.

Biz kullandık MediaWiki'yi ben resim (yani ekran görüntüleri) kullanım kolaylaşır olsaydı iyi olurdu söylemeliyim rağmen, birkaç yıldır (FCKeditor ile). Ve arama yapabilme becerisine sahip olmak esastır - MediaWiki'nin araştırmasının sıklıkla sayfaları özlediğini görüyorum. Belki de daha iyi arama yapmayı öğrenme meselesidir (bu, başkalarının işinizi yapması için basit bir yol bulma amacını yitirir)

Şu anda her şeyi MS Sharepoint'e taşıyoruz , her ne kadar wiki'sine olmasa da. Bence Sharepoint, doküman incelemesini bir wiki'nin bazı avantajlarını olumsuz etkileyecek şekilde yapabilir, bu yüzden bunun nereye gittiğini göreceğiz.

(şu anki tüm belgelerimizi taşıma sürecini dört gözle beklemiyorum :))

Bir wiki kullanıyoruz. Sözdiziminin alışması biraz zaman aldı, ancak kullandığımız (twiki) verilerini tamamen metin dosyaları olarak saklar. Bu, onları herhangi bir yere geri yükleyebildiğimiz ve grep yoluyla komut satırından arayabildiğimiz ve istediğimiz herhangi bir metin düzenleyicide okuyabildiğimiz için, bir felaket durumunda onları kolayca okumamıza olanak tanır.

Her sunucu, değişiklik yönetimi bilgileri, başlatma / kapatma ve yapılandırma notlarının yanı sıra dns, güvenlik duvarı ve varlık bilgileri için standart alt sayfa koleksiyonuna sahip bir sayfaya sahiptir.

Bizi üç sunucuya yayılmış ve kaç tane klasörün olduğunu bilen bir Word belgesi karışımından kurtarmaya çalışmak için bir Sharepoint hizmetinin bir versiyonuna geçmeye hazırlanıyoruz. Şu anda, burada açıklanan belgelere köprü içeren çok büyük bir excel elektronik tablomuz var.

Bunu yapmanın en iyi yolu değil, ancak şirket başladığında, hiçbir zaman iç belgelerin nasıl kullanılacağını planlamadılar ve kendi belgelerini uygun gördükleri şekilde nasıl sıralayacakları ve saklayacaklarına karar vermek için her gruba bıraktılar. Şimdi, Sharepoint tekliflerinden birinin etrafında olacak birleşik bir sistemde birleşmeye çalışıyoruz.

Çalıştığım STK'da, kritik prosedürler için sadece bir klasöre yerleştirilmiş metin dosyalarını kullanıyoruz. Şahsen bir Sistem Yöneticisi / Web Geliştirici melezi olarak bir ağaç dizinine dağılmış metin dosyalarının bir bilgi tabanını kullanıyorum, bu benim Memex'im ve neredeyse üzerine her şeyi yazıyorum (kişisel, iş, vb.). Bu program Jedit kullanarak metin işleme için gerçek bir İsviçre çakısı kullanmanın yönetimi çok kolaydır , anahat eklentisini, kod katlamayı ve hipersearch özelliklerini vazgeçilmez buldum. Bütün bunlar güvenli bir şekilde rsync tarafından ssh ile güvenilir bir uzak sunucuya yedeklendi.

Bunu Makelink Firefox Extension ile birleştirin ve mükemmel bir yer imi yöneticisine sahip olun.

Bir dotnet ve açık kaynak olan flexwiki'yi kullanıyoruz .

Erm ... peki Fogbugz? :)

İçerik için ScrewTurn ve dokümanları / görüntüleri depolamak için SharePoint kullanıyoruz.

Burada bazı ilginç şeyler var - şifreleri ile ilgili olanı kasada seviyorum.

Grep ile hızlı arama için metin dosyalarının bir kombinasyonunu kullanıyoruz. Daha ayrıntılı bir dokümantasyon koleksiyonu için VisPoint ve SharePoint (Visio diyagramları, vb.).

Google Apps (Enterprise) müşterileri olarak, Google Sites'ı kullanmıyoruz - onların wiki "tadı". Kullanımı kolay ve yöneticilerden ve geliştiricilerden çok iyi adapte olduk.

Başka bir soruyu cevaplamadan önce bu soruyu görmedim , ama işte başlıyoruz.

Birçok araç ve yöntem kullanıyoruz.

• Altyapı bileşenleri ve yazılım için fonksiyonel özellikler .
• İki Birleşme Hedefi . Bir tanesi kurumsal kurumsal belgeler için (politikalar, prosedürler, iç altyapı ve BT vb.) Ve bir tanesi de açık kaynaklı yazılım ürünlerimiz için.
• RSpec ve Salatalık testleri. Yazılımımız çoğunlukla Ruby'de yazılmıştır ve BDD / TDD kullanıyoruz , bu nedenle spesifikasyon testleri gerçek kodu ve dokümanı yönlendirir.
• Satır içi kod dokümantasyonu. Kod yorumlarında RDoc işaretlemesi kullanıyoruz .
• Declarative konfigürasyon yönetimi ( Şef ). Tüm sunucularımız, tariflerde ve yemek kitaplarında ayrıcalıklı kaynaklar aracılığıyla "kendi kendine belgeler" olan Chef ile yönetilmektedir.

Confluence'ı seviyoruz, çünkü çok esnek ve güçlü ve eksiksiz bir özellik, ayrıca sevdiğimiz bilet yönetimi yazılımına bağlı, Jira .

Daha önce çalıştığım şirketlerde, çeşitli araçlar ve yöntemler kullandım ve birçoğu her şey için tek bir kaynak bulmaya (Wiki gibi) kalmaya çalıştı. Bununla ilgili sorun, çeşitli konuları bu konuyu ele almak için benzersiz şekilde uygun olmayan tek bir araçla belgelemek, birçok şeyin belgelenmeyeceği anlamına gelir, çünkü bilgiyi geçirmek zordur. Bir Unix / Linux meraklısı olarak, her görevin belirli bir araç gerektirdiğine ve bu aracın bu göreve çok iyi uyması gerektiğine inanıyorum.

Bu soru çok iyi bir kopyası bu bir ve orada cevabımı taşındı.

Şirketimin belgelerinin çoğunu yapıyorum ve burada çalışmaya başladığımda oluşturulan biçim, düzenlenebilir orijinaller için MS Word, salt okunur genel sürümler için PDF'ye dışa aktarıldı. Yalnızca bir kişinin belgeyi güncellediği projeler için oldukça iyi çalışıyor ve bu kişi genellikle ben olduğum için, yönetim değişikliği gerekmedi.

Kod incelemeleri için bir "Eş İnceleme" uzantısı kullanırken hatalarımızı ve yaklaşan görevlerimizi Trac ile belgelendirmeye başladık . Bu, ekibimizden büyük bir kabul gördü, çünkü işbirliği yapmak kolay ve gezinmesi kolay. Diğer birkaç ekip üyesi, spesifikasyonlar, test prosedürleri ve kılavuzlarla daha fazla işbirliğine başlamak istediğini belirtti, bu yüzden kılavuzlar gibi kamuya açık belgeler için PDF'ye aktarılan DocBook / XML ve teknik özellikler gibi dahili belgeler için Trac WIKI sayfalarını inceliyoruz. Test prosedürleri

Aklımda, bir dokümantasyon formatı seçerken en büyük sorunlar şunlardır:

1. Oluşturması kolay mı?
2. Bakımı kolay mı?
3. Başkası yazdıysa bakımı kolay mı?
4. Çok fazla uğraş vermeden başka formatlara aktarılabilir / dönüştürülebilir mi?

1-3 hayatımı kolaylaştırıyor ve delirmeden hızlı bir şekilde dokümantasyon oluşturmak için önemlidir. Bence dördüncü müşteri tarafında en önemlisi, çünkü formatlar sürekli değişecek. Microsoft Word 2003 formatı sonsuza kadar sürmeyecek ve şu anki PDF uygulamamız da değil. İşletim sisteminin veya tercih edilen belge okuyucusu ne olursa olsun, tüm müşterilerimizin belgelerimizi okuyabildiğinden emin olmam gerekiyor.

MediaWiki'yi SemanticMediaWiki dahil olmak üzere çeşitli eklentilerle kullanıyoruz. SMW güzeldir, çünkü MediaWiki kurulumumuzu, istenildiği zaman sorgulanabilecek büyük, serbest biçimli bir ilişkisel veritabanına dönüştürür. Bir web sitesinin hangi sunucuda olduğunu bilmeniz mi gerekiyor? Sayfasını ziyaret et. Bir sunucuda hangi web sitelerinin barındırıldığını bilmeniz mi gerekiyor? Bir sorgu çalıştırdığınızda, sayfa adlarını her web sitesinin sayfasındaki uygun etikete göre seçer.

Ben kullandım bir dokümantasyon sistemi ile değil cevap verecektir, ama bir şey ile ben var görüldü kullanılan ve hangi çok iyi bulmak: http://stackexchange.com/

stackexchange serverfault altında çalışan bir soru-cevap platformudur (teknik olarak tam olarak aynı değildir, ancak burada amacımız aynı olduğunu varsayabiliriz).

Fogbugz kullanıyor .

Bu teklifleri bulduğum bir Fogbugz çalışanından ilginç bir blog yazısı var :

Ürün özellikleri dışındaki tüm amaçlar için, kurumsal wiki ve tartışma formlarının ölümcül bir darbe aldığını düşünüyorum.

...

FogBugz.StackExchange.com'u destek platformumuz olarak kullanmaya başladığımızdan beri, aynı soruyu iki kez hiç cevaplamadım. Kamuya açık olmayan bir soru-cevap için kullandığımız dahili bir SE sunucumuz bile var ve aynı prensipler burada da geçerli.

Müşterinin karşılaştığı bilgi tabanı ve iç bilgi tabanı için stackexchange'i kullanırlar.

Bu tür bilgi alışverişi soru-cevap platformlarının şirket wiki'lerinin yerine geçip geçmeyeceğini görmek istiyorum.

Önceki işverenimde bir klasörde toplanan Word, Excel ve Visio dosyalarını kullandım. Her şeyin basılı kopyası masamdaki ciltte tutuldu. Tek BT ​​kişisiydim, bu yüzden başkalarının bilgiye erişmesi için çok az ihtiyaç vardı.

Mevcut işverenimde Exact Software tarafından Macola ES kullanıyoruz, ancak dokümantasyonumu Word'de yazmayı ve yerleşik belge düzenleyiciyi kullanmaktan ziyade ek olarak Macola'ya yüklemeyi tercih ediyorum.

İşyerimde, ScrewTurn Wiki'yi Windows dev sunucularımızdan birine düşürdüm ve SQL Server'ımıza bağladım. Gerçekten iyi çalışıyor, hızlı çalışıyor ve çoğunlukla dokümantasyon için yolumuzdan çıkmıyor. Dağıtılmasından bu yana iki hafta içinde, yaklaşık 60 sayfa bilgi ekledik ve bu sadece ekibimiz için (~ 10 kişi).

Şimdiye kadar, mevcut ve geçmiş projelerle ilgili bilgileri burada tutarız ve uygulamaları sıfırdan, URL'lerden ve ekibin yeniliği için diğer önemli bilgilerden nasıl oluşturacağımız gibi uygulamalar hakkında bilgi eklemeye başladık.

Vikideki favori sayfalarımdan biri araçlar ve kütüphaneler sayfasıydı. Orada, en çok kullandığımız favori verimlilik araçlarımız ve kitaplıklarımız hakkında, örneğin Windows'ta metin arama için grepWin olan bilgiler eklemeye başladık.

Wiki'nin mevcut gamının tamamını kontrol etmenizi ve kullanım amacınıza, işlevselliğinize ve kullanımınıza uygun olanı bulmanızı kesinlikle tavsiye ederim. ScrewTurn'ü seçtim çünkü kullanımı kolay ve yerel WinServer'ımızda bir sürü boş yerimiz vardı, ama YMMV.

Confluence'ı bazı durumlarda belgeler için wiki ve sharepoint olarak kullanıyoruz. Bu bilgiyi gerçekten geniş ölçüde paylaşmanız gerektiğinde ve belgeler çok sık düzenlendiğinde ve güncellendiğinde çok daha önemli olan şeylerin çevrimiçi wiki formatının tercih edilen bir format olduğuna inanıyorum. Bu yüzden bilgi tabanı makalelerinin wiki'ye yazmanın daha iyi olacağını düşünüyorum.

Şu anda bilgilerimizi ağa yayılan çeşitli belgelerden iki konuma taşıyoruz:

1. İntranetimizde mevcut olan bir wiki
2. Bu sunucular / kök dizinindeki belirli bir sunucu ile ilgili bilgilerin bir kopyası.

Ağ diyagramları için, Ağ Not Defteri .

Ayrıca, neyi kaydederken, bir şeyin neden böyle yapılandırıldığını kaydetmeyi de unutmayın. Bu, iyi bir fikir gibi görünen fikirlerin hatalara dönüşmesini önlemeye yardımcı olur.

MediaWiki'nin yavaş bir başlangıç ​​olduğunu bulduk, ancak BT dışındaki insanlar yorum, değişiklik, düzenleme vb. Eklemenin ne kadar kolay olduğu konusunda bir fikir edindiler, vazgeçilmez hale geldi. Geliştiriciler, iç belgeler için kullanıyorlardı. Duyurular, vb. göndermek için. Sadece bir IT dokümantasyon aracı olmanın ötesine geçmiştir.