Jak dokumentujesz swoją pracę, procesy i środowisko?

Czy używasz formatu wiki? Jeśli tak, to który produkt? (MediaWiki, Confluence, Sharepoint itp.)

Czy stworzyłeś bazę wiedzy? (Dokumenty zorientowane na problem / rozwiązanie).

Jakie wyzwania wiążą się z tworzeniem dokumentacji, która działa, więc nie odbierasz połączenia, gdy jesteś na wakacjach?

Uważam, że często jest pewna „bezwładność” organizacyjna związana z przygotowaniem dokumentacji. Wydaje się, że jest to inny rodzaj osoby, która może wykonać zadanie, a następnie pomyśl o tym , jak wykonał to zadanie, i opisz je, aby ktoś inny mógł to zrobić - rodzaj siły, aby „przejść do meta” i nie każdy robi to wygodnie.

Aktualizacja

Odpowiedzi do tej pory obejmują

• Zbieg
• Flexwiki
• Fogbugz
• Mediawiki (z wtyczkami takimi jak fckeditor)
• Sharepoint
• TWiki
• Dokumenty Word / Excel / Visio
• Udokumentowane skrypty

Edycja: Czy nie udokumentujesz niejawnie swojej sieci za pomocą systemu monitorowania? Nagios zawsze zachęcani do korzystania z rodzicami dyrektywy odzwierciedlać strukturę swojej sieci, a notes_url dyrektywa ma na celu umożliwienie Ci link do wiki lub innej dokumentacji przeglądarki internetowej. Tak więc „dokumentacja” jest podzielona na „żywy dokument” systemu monitorowania i bardziej szczegółową dokumentację offline na wiki. Ponieważ spędzam dużo czasu, wpatrując się w Nagios, sensowne jest włożenie wysiłku, aby uczynić go jak najbardziej pouczającym.

Komentowanie oprzyrządowania.

Wypróbowaliśmy wiki wiki, ale znaleźliśmy szereg ograniczeń, które mogą być osobistym gustem, ale obejmują strukturę dokumentu i, co najważniejsze, muszą być podłączone do serwera dokumentacji.

Bycie połączonym jest poważnym problemem, jeśli jesteś offline lub na miejscu (oczywiście możesz złagodzić sytuację na miejscu za pomocą bezpiecznego połączenia SSL i innych).

Nasz obecny proces dokumentacji to:

• statyczny generator HTML
• składnia przeceny
• rozproszony system wersjonowania

Mamy „formalny” układ dokumentacji, który zapewnia strukturę menu (i powiązany CSS do stylizacji wizualnej itp.)

Generator statyczny HTML

Używamy w domu generator HTML statyczne w oparciu o cubictemp oraz szereg innych narzędzi: pygments , docutils .

Wygenerowane strony są (nie?) Oczywiście brzydkie, ponieważ większość z nas / naszych administratorów / programistów wie, co jest estetycznie piękne, ale brakuje im koordynacji w tworzeniu takich.

Ale umożliwia / dołączmy pliki konfiguracyjne, przykładowe skrypty, pdf itp., Bez konieczności martwienia się o to, że formatowanie html zepsuje go lub nie zastanawiamy się, gdzie go znaleźć na „serwerze” do pobrania.

Jeśli nie jest to HTML, po prostu upuść go w folderze i dodaj do niego link URL.

HTML zapewnia „potencjalną” strukturę układu, a także krytycznie zapewnia „łączenie” elementów wiedzy / treści (a także podstawowych mechanizmów struktury, takich jak możliwość tworzenia menu, spisu treści itp.) Dzięki HTML, każdy użytkownik może teraz uruchom mały serwer WWW na swoim komputerze, bez względu na to, czy używasz lighttpd, czy czegoś małego, czy po prostu korzystasz z Apache lub IIS.

Wszystkie nasze maszyny mają pomost do podstawowej obsługi HTML i działają dla nas wystarczająco dobrze.

Składnia MARKDOWN.

Korzystamy z bastardowej wersji MARKDOWN, Textish i lub reStructuredTEXT, aby umożliwić naszym „kreatywnym” sokom pisanie dokumentacji bez martwienia się o HTML.

Oznacza to również, że każdy może używać swojego ulubionego edytora (używam Scintilla na Windows i * Nix), podczas gdy inni tutaj używają vi / vim.

Rozproszony system kontroli wersji.

Używamy Git do „rozpowszechniania” dokumentacji między użytkownikami. Aha, używamy też jego możliwości wersjonowania.

Kluczową zaletą dla nas jest to, że wszyscy możemy pracować nad aktualizacją dokumentacji bez konieczności łączenia się z serwerem i bez publikowania „ukończonych” prac. Wszyscy możemy pracować nad tymi samymi częściami dokumentacji, różnymi częściami lub po prostu zużywać informacje.

Osobiście nie lubię być przywiązany do serwera, aby aktualizować blogi, nie mówiąc już o wiki. Git działa dla nas dobrze.

Komentowanie przepływu pracy

Wiki wydają się być „modą” do rozpowszechniania / kodyfikacji wiedzy, ale jak komentowano gdzie indziej, wszystkie procesy stają się trudne do utrzymania, a znalezienie zestawu narzędzi, które najlepiej wspierają potrzeby twojego zespołu i są trwałe, zajmie trochę czasu.

Lepsze rozwiązania po prostu zostają odkryte i nie są obowiązkowe.

Zaczęliśmy używać DokuWiki tam, gdzie pracuję.

Ze strony internetowej Dokuwiki:

DokuWiki to zgodna ze standardami, prosta w obsłudze Wiki, której głównym celem jest tworzenie dokumentacji dowolnego rodzaju. Jest skierowany do zespołów programistów, grup roboczych i małych firm. Ma prostą, ale potężną składnię, która zapewnia, że ​​pliki danych pozostają czytelne poza Wiki i ułatwia tworzenie tekstów strukturalnych. Wszystkie dane są przechowywane w plikach tekstowych - nie jest wymagana baza danych.

Uznałem, że Dokuwiki jest najłatwiejszy do wdrożenia, ponieważ nie wymaga bazy danych i był łatwy w konfiguracji. Były też moduły dodatków, które umożliwiły korzystanie z moich istniejących kont kont Active Directory, zamiast konieczności tworzenia kont dla wszystkich, co było ogromną zaletą w stosunku do większości innych systemów wiki, które znalazłem. ma także typową kontrolę wersji, dzięki której można zobaczyć, kto co opublikował, i może w razie potrzeby łatwo przywrócić poprzednią wersję. Obejmują one także dostosowywaną stronę główną, na której możesz łatwo zmienić zawartość, która najlepiej pasuje do Twojego środowiska.

Doku Wiki lub Sharepoint dla innych rzeczy, które pasują do wykresu.

Szybko przyzwyczajasz się do publikowania postów na wiki, a składnia nie jest tak skomplikowana. Bardzo łatwo jest uporządkować informacje i ułatwić ich późniejsze odnalezienie przez kogoś innego.

Używam Visio do tworzenia wykresów w celu uzyskania jaśniejszych wyjaśnień (eksport jako JPEG).

Używamy wiki. W rzeczywistości korzystamy z MediaWiki. Oprócz MediaWiki mamy zainstalowane rozszerzenie Semantic Mediawiki , które faktycznie zamienia nasze MediaWiki w coś w rodzaju luźnej bazy danych, którą możemy wyszukiwać za pomocą kategorii, tytułu, zawartości itp.

Załóżmy na przykład, że chcę zobaczyć wszystkie nazwy sieciowe, które prowadzą przez klaster F. Wystarczy, że użyję strony Special: Ask, aby wykonać zapytanie [[Category: cname]] [[destination ::uster_f]] .. . i zwróci wszystkie strony, które są skategoryzowane jako nazwa z miejscem docelowym jako klaster_f.

Obsługujemy kilkuset bardzo odmiennych klientów, więc posiadanie tej dokumentacji w centralnym miejscu (i krzyżowanie jej w taki sposób, aby specjalne przypadki pozostały udokumentowane i powiązane w całość) jest ogromną poręczną rzeczą. Oczywiście nasza dokumentacja musi być utrzymywana, ale możesz przyjąć bardziej „ogrodnicze” podejście do konserwacji, ponieważ zestaw narzędzi mediawiki do utrzymywania aktualności dużego zbioru danych jest już dość dojrzały.

Dzięki odpowiednim wtyczkom Trac może stać się połączonym systemem biletów i systemu wiki. Ułatwia to twojemu biletowi link do artykułów wiki i odwrotnie.

Kilka wtyczek, które lubię:

• Wtyczka Private Tickets . Trac jest zbudowany jako baza błędów, w której wszystkie bilety i ich odpowiedzi są publiczne. To nie jest odpowiednie dla systemu biletów IT, ale ta wtyczka to rozwiązuje.
• Wtyczka Trac WYSIWYG . Spójrzmy prawdzie w oczy, większość ludzi nie uczy się wikisyntax, aby cię uszczęśliwić. To daje im edytor „to, co widzisz”, zarówno dla biletów, jak i stron wiki.

Istnieje wiele innych dostosowań Trac. Konfiguracja i dostosowanie systemu Trac do własnych potrzeb nie jest trudne!

W mojej poprzedniej pracy korzystałem z Twiki. Działa całkiem dobrze.

Oprócz tego mam tendencję do automatyzacji większości zadań i dokumentowania skryptów (nie zawsze z wielkim entuzjazmem, ale nadal ...). Dokumentowanie skryptów jest łatwe do wykonania w trakcie ich projektowania, więc nie ma prawdziwych kosztów ogólnych ...

Kombinacja obu (i użycie kontroli wersji dla skryptów) całkiem nieźle sobie poradziła.

Mieszanka dokumentów JIRA, Confluence i Word.

Instytucjonalizacja wiedzy

Zaczęliśmy od dokumentów. Następnie zapisaliśmy niektóre z nich w bibliotekach Sharepoint. Niedawno przenieśliśmy się na wiki Sharepoint. Lubię podejście Wiki o niskim współczynniku tarcia w szybkim aktualizowaniu rzeczy, chociaż wiki Sharepoint pozostawiają pewne rzeczy do życzenia w zakresie obsługi grafiki i formatowania dla takich rzeczy jak tabele. Jest w porządku dla tekstu, a wbudowany edytor pozwala na podstawowe formatowanie HTML i uporządkowane / nieuporządkowane listy. Istnieją inne tanie alternatywy dla Sharepoint.

Mamy również rodzaj nieformalnej bazy wiedzy na temat naszych biletów pomocy technicznej w naszym oprogramowaniu pomocy technicznej, Numara's Track-It. To nie jest idealne, ale działa.

Przekonanie personelu do korzystania ze zinstytucjonalizowanej wiedzy

Zgadzam się z twoją oceną, że zinstytucjonalizowanie wiedzy to tylko jedna część bitwy. Jeśli twoja organizacja i ludzie nie są przyzwyczajeni do „badań najpierw, pytaj po drugie”, to przekonasz się, że dominuje stary sposób: wszyscy nadal będą szukać formalnych i nieformalnych guru w poszukiwaniu odpowiedzi, a dla niektórych osób zawsze będzie łatwiej zapytać osoba obok ciebie, niż szukać na własną rękę.

Radzenie sobie z tym będzie wymagało pewnego zarządzania zmianami; podobnie jak większość udanych inicjatyw zmian wpływających nie tylko na mały zespół, pomoże uzyskać wsparcie menedżerskie i wsparcie. Naprawdę musisz wykuć nowe zachowanie w dwóch kierunkach; ktoś musi zdobyć wiedzę, a ludzie muszą z niej skorzystać. Jeszcze trudniejsze jest to, że ludzie muszą również aktualizować te dane.

Tylko kilka pomysłów: prawdopodobnie będzie trzeba zachęcić w formie formalnej polityki stwierdzającej, że rozwiązane zgłoszenia i problemy muszą być udokumentowane w bazie wiedzy lub na wiki, zanim będą mogły zostać uznane za zamknięte. Ponadto liderzy wiedzy, którzy zwykle zadają pytania, nie zawsze powinni po prostu udzielać odpowiedzi na żądanie; muszą wskazywać ludziom strony wiki i przyzwyczaić ich do sprawdzania ich w pierwszej kolejności. Inną rzeczą byłoby udostępnienie danych użytkownikom w celu samopomocy, aby problem mógł zostać rozwiązany, zanim stanie się on kolejnym elementem, z którym pracownicy techniczni będą musieli pogodzić się.

Byłoby miło, gdyby nasz system pomocy miał system podobny do StackOverflow i ServerFault: podczas wpisywania pytania wyszukiwarka znajduje podobne przedmioty i oferuje je, aby użytkownicy mogli je obejrzeć nawet przed przesłaniem pytania.

W moich dwóch ostatnich miejscach pracy korzystałem z Wiki Sharepoint, oprócz biblioteki dokumentów, która zawierała pewne dokumenty (takie jak DRP i jednorazowe plany aktualizacji), których nie można łatwo utworzyć jako dokumenty Wiki. Dokumenty te miały linki z Wiki. Wiki ma wiele zalet w tym obszarze, ponieważ wiele osób może go edytować, wbudowana wersja, łatwe do przeszukiwania i dostępne itp. Do szybkiego zapisywania notatek lub pomysłów użyłbym OneNote lub tablicy.

Tworzyłem już niektóre bazy wiedzy w formacie forum (zarówno w Lotus Notes, jak i MS Sharepoint), ale muszę powiedzieć, że tylko rzadko ludzie szukają ich, aby sprawdzić, czy jakiś problem został już rozwiązany. Takie rozwiązanie musi pochodzić od pierwszego dnia z bardzo silną i skuteczną wyszukiwarką.

Jeśli chcesz stworzyć dokumenty, z których będziesz mógł korzystać podczas wakacji, napisz je tak, jakbyś poinstruował jednego z rodziców. To nie jest w 100% głupie, ale czasem pomaga. Zależy, kto to czyta.

Sharepoint jest fajny.

Funkcje wyszukiwania umożliwiają indeksowanie niemal każdego rodzaju dokumentu, dzięki czemu wyszukiwanie dokumentacji jest naprawdę łatwe.

Może również tworzyć szablony, co może ułatwić, jeśli na przykład masz standardowy arkusz informacyjny dla każdego budowanego serwera.

Może także aktualizować twoje dokumenty, dzięki czemu masz historię audytu zmian w dokumentacji.

Do plików zawartych w bibliotekach dokumentów można uzyskać dostęp przez Internet, w programie Outlook lub poprzez udostępnianie unc od razu po wyjęciu z pudełka.

Używamy MediaWiki (z fckeditor) od kilku lat, chociaż muszę powiedzieć, że byłoby miło, gdyby obsługa obrazów (tj. Zrzutów ekranu) była łatwiejsza. I chociaż umiejętność wyszukiwania jest niezbędna - uważam, że wyszukiwanie w MediaWiki często pomija strony. Być może jest to tylko kwestia uczenia się lepszego wyszukiwania (co tego rodzaju pokonuje cel polegający na prostym sposobie wykonywania pracy przez innych)

Obecnie rozmawiamy o przeniesieniu wszystkiego do MS Sharepoint , choć niekoniecznie na ich wiki. Myślę, że Sharepoint jest w stanie przeprowadzić pełne wyszukiwanie dokumentów w sposób, który neguje niektóre zalety wiki, więc zobaczymy, dokąd to zmierza.

(nie mogę się doczekać procesu przenoszenia całej naszej obecnej dokumentacji :))

Używamy wiki. Oczywiście przyzwyczajenie się do składni zajęło trochę czasu, ale ten, którego używamy (twiki), przechowuje swoje dane w całości jako pliki tekstowe. Pozwala nam to łatwo odczytać je w razie katastrofy, ponieważ możemy przywrócić je w dowolnym miejscu, przeszukać je z wiersza poleceń za pomocą grep i odczytać w dowolnym edytorze tekstu, który nam się podoba.

Każdy serwer ma stronę ze standardową kolekcją podstron dla informacji o zarządzaniu zmianami, uruchamianiu / zamykaniu i uwagach konfiguracyjnych, a także dns, zapora ogniowa i informacje o zasobach.

Przygotowujemy się do przejścia na jakąś wersję usługi Sharepoint, aby spróbować wyciągnąć nas z mieszanki dokumentów tekstowych rozmieszczonych na trzech serwerach i kto wie, ile folderów. Obecnie mamy ogromny arkusz kalkulacyjny programu Excel, który zawiera hiperłącza do dokumentów w nim opisanych.

Nie jest to najlepszy sposób, aby to zrobić, ale kiedy firma rozpoczęła działalność, nigdy nie planowali obsługi wewnętrznej dokumentacji i pozostawili każdej grupie decyzję, w jaki sposób posortować i przechowywać własną dokumentację według własnego uznania. Teraz staramy się połączyć w zunifikowany system, który będzie obejmował jedną z ofert Sharepoint.

W organizacji pozarządowej, w której pracuję, używamy plików tekstowych umieszczonych w folderze do krytycznych procedur. Osobiście jako hybryda administratora systemu / webmastera korzystam z bazy wiedzy plików tekstowych rozproszonych w katalogu drzewa, to jest mój Memex i zapisuję na nim prawie wszystko (osobiste, zawodowe itp.). Ten schemat jest bardzo łatwy w zarządzaniu przy użyciu prawdziwego szwajcarskiego noża wojskowego Jedit do przetwarzania tekstu. Uważam , że jego wtyczka do konturu, zwijanie kodu i funkcje hiperszukiwania są nieodzowne. Wszystko to bezpiecznie jest zabezpieczone przez rsync na zdalnym serwerze dostępnym ssh.

Połącz to z Makelink Firefox Extension i masz idealnego menedżera zakładek.

Używamy flexwiki , który jest dotnet i open source.

Eee ... a co z Fogbugzem? :)

Używamy ScrewTurn do zawartości i SharePoint do przechowywania dokumentów / obrazów.

Istnieje kilka ciekawych rzeczy tutaj - i jak ten temat haseł w bezpieczny.

Używamy kombinacji plików tekstowych do szybkiego wyszukiwania za pomocą grep. I SharePoint dla bardziej zorganizowanego zbioru szczegółowej dokumentacji (diagramy Visio itp.).

Jako klienci Google Apps (Enterprise) używamy cholernie Witryn Google - ich „smaku” wiki. Łatwy w użyciu i bardzo dobrze przyjęliśmy go od administratorów i programistów.

Nie widziałem tego pytania, zanim odpowiedziałem na inne pytanie , ale proszę bardzo.

Używamy wielu narzędzi i metod.

• Specyfikacje funkcjonalne komponentów infrastruktury i oprogramowania.
• Dwie wiki o zbieżności . Jeden do wewnętrznej dokumentacji korporacyjnej (zasady, procedury, wewnętrzna infrastruktura i IT itp.), A drugi do naszych produktów oprogramowania typu open source.
• Testy RSpec i Ogórek . Nasze oprogramowanie jest napisane głównie w języku Ruby i ćwiczymy BDD / TDD , więc testy specyfikacji sterują samym kodem i dokumentem.
• Dokumentacja kodu wbudowanego. Używamy znaczników RDoc w komentarzach do kodu.
• Deklaratywne zarządzanie konfiguracją ( Chef ). Wszystkimi naszymi serwerami zarządza Chef, który „samodzielnie dokumentuje” poprzez delcaratywne zasoby w przepisach i książkach kucharskich.

Lubimy Confluence, ponieważ jest bardzo elastyczny, wydajny i kompletny, a ponadto łączy się z oprogramowaniem do zarządzania biletami, które lubimy, Jira .

W poprzednich firmach, w których pracowałem, korzystałem z różnych narzędzi i metod, a wiele próbowało pozostać przy jednym zasobie typu catch-all (jak Wiki) na wszystko. Problem z tym polega na dokumentowaniu różnych tematów za pomocą jednego narzędzia, które nie jest specjalnie przystosowane do omawiania tego tematu, co oznacza, że ​​wiele rzeczy w ogóle nie zostanie udokumentowanych, ponieważ migracja informacji jest trudna. Jako maniak Uniksa / Linuksa uważam, że każde zadanie wymaga określonego narzędzia, które powinno doskonale pasować do tego zadania.

To pytanie bardzo dobrze jest duplikatem tego pytania i tam przeniosłem swoją odpowiedź.

Robię większość dokumentacji dla mojej firmy, a formatem, który został ustalony, kiedy zacząłem tu pracować, był MS Word dla edytowalnych oryginałów, wyeksportowany do formatu PDF dla ogólnych wersji tylko do odczytu. Działa dość dobrze w projektach, w których tylko jedna osoba aktualizuje dokument, a ponieważ ta osoba jest zwykle mną, zarząd nie widział potrzeby zmiany.

Zaczęliśmy dokumentować nasze błędy i nadchodzące zadania za pomocą Traca , jednocześnie korzystając z rozszerzenia „Peer Review” do recenzji kodu. To spotkało się z dużą akceptacją ze strony naszego zespołu, ponieważ łatwo jest współpracować i jest łatwy w nawigacji. Kilku innych członków zespołu wyraziło chęć dalszej współpracy ze specyfikacjami, procedurami testowymi i podręcznikami, dlatego szukamy DocBook / XML wyeksportowanego do formatu PDF w celu uzyskania publicznej dokumentacji, takiej jak instrukcje, oraz stron Trac WIKI dla wewnętrznych dokumentów, takich jak specyfikacje i Procedury testowe.

Moim zdaniem największe problemy przy wyborze formatu dokumentacji to:

1. Czy łatwo to stworzyć?
2. Czy to jest łatwe w utrzymaniu?
3. Czy łatwo go utrzymać, jeśli ktoś go napisał?
4. Czy można go eksportować / konwertować do innych formatów bez większych problemów?

1-3 ułatwiają mi życie i są ważne dla szybkiego tworzenia dokumentacji bez szaleństwa. Myślę, że czwarty jest najważniejszy po stronie klienta, ponieważ formaty ciągle się zmieniają. Format Microsoft Word 2003 nie będzie dostępny na zawsze, podobnie jak nasza obecna implementacja formatu PDF. Muszę upewnić się, że wszyscy nasi klienci mogą czytać nasze dokumenty, bez względu na ich system operacyjny lub czytnik dokumentów.

Używamy MediaWiki z różnymi wtyczkami, w tym SemanticMediaWiki. SMW jest fajny, ponieważ zamienia naszą instalację MediaWiki w dużą, relacyjną bazę danych o dowolnej formie, którą można dowolnie przeszukiwać. Chcesz wiedzieć, na którym serwerze znajduje się strona internetowa? Wejdź na jego stronę. Chcesz wiedzieć, jakie witryny są hostowane na serwerze? Uruchom zapytanie, a wybierze nazwy stron na podstawie odpowiedniego znacznika na stronie każdej witryny.

Odpowiem nie za pomocą systemu dokumentacji, z którego korzystałem, ale za pomocą czegoś, co widziałem i które uważam za bardzo dobre: http://stackexchange.com/

stackexchange to platforma pytań i odpowiedzi działająca pod błędem serwera (technicznie nie jest dokładnie taka sama, ale w naszym celu możemy założyć, że jest taka sama).

Fogbugz używa go .

Istnieje ciekawy wpis na blogu od pracownika Fogbugz, w którym znalazłem te cytaty:

Wydaje mi się, że do wszystkich celów poza specyfikacjami produktów śmiertelne ciosy korporacyjnych wiki i formularzy dyskusyjnych.

...

Odkąd zaczęliśmy używać FogBugz.StackExchange.com jako naszej platformy wsparcia, nigdy nie odpowiedziałem dwa razy na to samo pytanie. Mamy nawet wewnętrzny serwer SE, którego używamy do niepublicznych pytań i odpowiedzi, i obowiązują tam te same zasady.

Używają wymiany stosów do bazy wiedzy skierowanej do klienta i wewnętrznej bazy wiedzy.

Interesuje mnie, czy taka platforma wymiany wiedzy i odpowiedzi zastąpi korporacyjne wiki.

U mojego poprzedniego pracodawcy korzystałem z plików Word, Excel i Visio zebranych razem w folderze. Egzemplarz wszystkiego był przechowywany w segregatorze na moim biurku. Byłem jedyną informatyką, więc nikomu nie było potrzeby dostępu do informacji.

U mojego obecnego pracodawcy korzystamy z Macola ES firmy Exact Software, ale nadal wolę pisać moją dokumentację w programie Word i przesyłać ją do Macoli jako załącznik, niż używać wbudowanego edytora dokumentów.

W moim miejscu pracy umieściłem Wiki ScrewTurn na jednym z naszych serwerów deweloperskich Windows i podłączyłem go do naszego SQL Server. Działa naprawdę dobrze, działa szybko i głównie nie przeszkadza nam w dokumentacji. W ciągu dwóch tygodni od wdrożenia dodaliśmy już około 60 stron informacji, i to tylko dla naszego zespołu (~ 10 osób).

Jak dotąd przechowujemy informacje o obecnych i przeszłych projektach i zaczęliśmy dodawać informacje o aplikacjach, takie jak sposób ich tworzenia od zera, adresy URL i inne ważne informacje dla deweloperów w zespole.

Jedną z moich ulubionych stron na wiki była strona narzędzi i bibliotek. Tam zaczęliśmy dodawać informacje o naszych ulubionych narzędziach wydajnościowych i bibliotekach, z których często korzystamy, czego przykładem jest grepWin do wyszukiwania tekstu w systemie Windows.

W pełni polecam sprawdzenie pełnej gamy dostępnych wiki i znalezienie takiej, która będzie pasować do zamierzonego użycia, funkcjonalności i środowiska wdrażania. Wybrałem ScrewTurn, ponieważ jest łatwy w użyciu i mieliśmy mnóstwo wolnego miejsca na naszym lokalnym WinServer, ale YMMV.

W niektórych przypadkach używamy Confluence jako wiki i sharepoint do dokumentów. Uważam, że format wiki online jest preferowany, gdy trzeba bardzo szeroko udostępniać te informacje, a co ważniejsze, gdy dokumenty będą edytowane i często aktualizowane. Myślę więc, że w artykułach z bazy wiedzy lepiej umieścić na wiki.

Obecnie przenosimy nasze informacje z różnych dokumentów rozsianych po sieci do dwóch lokalizacji:

1. Wiki dostępne w naszym intranecie
2. Kopia informacji związanych z określonym serwerem w tym katalogu server / root.

W przypadku diagramów sieciowych, Notatnik sieciowy .

Ponadto, nagrywając co, pamiętaj, aby zapisać, dlaczego coś jest tak skonfigurowane. Pomaga to zapobiec zamienianiu się pomysłów, które wydają się dobrym pomysłem.

Odkryliśmy, że MediaWiki jest powolnym starterem, ale gdy ludzie spoza IT zrozumieli, jak łatwo można dodawać komentarze, zmiany, edycje itp., Staje się niezbędny. Deweloperzy używają go do wewnętrznej dokumentacji, działu urządzeń. do publikowania ogłoszeń itp. Wykracza poza zwykłe narzędzie do dokumentacji IT.