it-swarm-pt.tech

Como você está documentando seu trabalho, processos e ambiente?

Você está usando um formato wiki? Em caso afirmativo, qual produto? (MediaWiki, Confluence, Sharepoint etc.)

Você criou uma base de conhecimento? (Documentos curtos orientados a problemas/soluções.)

Que desafios você encontra na criação de documentação que funcione, para que você não seja atendido quando sair de férias?

Para mim, acho que muitas vezes há uma certa inércia organizacional envolvida na realização da documentação. Parece ser um tipo diferente de pessoa que pode executar uma tarefa, depois pense em como eles executaram a tarefa e a descrevem para que outra pessoa possa fazer - tipo de força para você "seguir meta" e nem todo mundo está confortável fazendo isso.

Atualizar

As respostas até agora incluem

  • Confluência
  • Flexwiki
  • Fogbugz
  • Mediawiki (com plugins como o fckeditor)
  • Sharepoint
  • TWiki
  • Documentos do Word/Excel/Visio
  • Scripts documentados

Editar: Você não está documentando implicitamente sua rede com seu sistema de monitoramento? O Nagios sempre incentivou o uso da diretiva pais para refletir a estrutura da sua rede, e a diretiva notes_url foi projetada para permitir que você vincule a um wiki ou outra documentação baseada em navegador . Portanto, aqui a "documentação" é dividida entre o "documento ativo" do sistema de monitoramento e a documentação offline mais detalhada em um wiki. Como passo muito tempo olhando Nagios, faz sentido esforçar-se para torná-lo o mais informativo possível.

48
Cawflands

Comentando sobre as ferramentas.

Tentamos wiki online, mas encontramos várias limitações, que podem ter gosto pessoal, mas incluem a estrutura do documento e, mais importante, a conexão ao servidor de documentação.

Estar conectado é um problema sério se você estiver offline ou no local (obviamente, você pode atenuar o local com uma conexão SSL segura etc.)

Nosso processo de documentação atual é:

  • gerador de html estático
  • sintaxe de remarcação
  • sistema de versão distribuído

Temos um layout 'formal' para a documentação e que fornece a estrutura para os menus (e o CSS associado para estilo visual etc.)

Gerador estático de HTML

Utilizamos um gerador de html estático interno baseado em cubictemp e várias outras ferramentas: pigmentos , docutils .

As páginas geradas são (não?) Obviamente feias, já que a maioria de nós/nossos administradores de sistemas/programadores sabe o que é esteticamente bonito, mas tem uma total falta de coordenação para construí-lo.

Mas ele permite/vamos incluir arquivos de configuração, scripts de amostra, pdf, etc, sem ter que se preocupar com a formatação html estragando tudo ou se preocupar com onde encontrá-lo no 'servidor' para download.

Se não for HTML, basta soltá-lo na pasta e adicionar um link de URL.

O HTML fornece uma estrutura 'potencial' para o layout e também fornece 'links' críticos entre itens de conhecimento/conteúdo (além de mecanismos de estrutura de base, como a possibilidade de criar menus, tabelas de conteúdo etc.) Com o HTML, cada usuário agora pode execute um pequeno servidor da Web em sua máquina, seja o lighttpd ou algo pequeno, ou simplesmente se torne um dos principais no Apache ou no IIS.

Todas as nossas máquinas têm o problema de servir html básico e funcionam bem o suficiente para nós.

Sintaxe de MARKDOWN.

Usamos uma versão bastardizada de MARKDOWN, Textish e ou reStructuredTEXT para permitir que nossos sucos 'criativos' escrevam documentação sem ter que se preocupar com HTML.

Isso também significa que todos podem usar seu editor favorito (eu uso o Scintilla no Windows e * Nix), enquanto os outros aqui usam o vi/vim.

Sistema de controle de versão distribuído.

Usamos Git para 'distribuir' a documentação entre os usuários. Ah, e também usamos sua capacidade de versão.

A principal vantagem para nós é que todos podemos trabalhar na atualização da documentação sem precisar estar conectado ao servidor e sem ter que publicar trabalhos 'concluídos'. Todos nós podemos trabalhar nas mesmas partes da documentação, ou em partes diferentes, ou apenas consumir as informações.

Pessoalmente, eu odeio estar vinculado a um servidor para atualizar blogs e muito menos wiki. Git funciona bem para nós.

Comentando sobre o fluxo de trabalho

Os wiki parecem ser a "moda" para a disseminação/codificação de conhecimento, mas, como comentado em outros lugares, todos os processos se tornam difíceis de sustentar, e encontrar a mistura de ferramentas que melhor suporta as necessidades de sua equipe e é sustentável levará tempo.

As melhores soluções acabam sendo descobertas e não obrigatórias.

8
samt

Começamos a usar DokuWiki onde trabalho.

No site do Dokuwiki:

O DokuWiki é um Wiki compatível com os padrões, simples de usar, destinado principalmente à criação de documentação de qualquer tipo. É direcionado a equipes de desenvolvedores, grupos de trabalho e pequenas empresas. Ele possui uma sintaxe simples, porém poderosa, que garante que os arquivos de dados permaneçam legíveis fora do Wiki e facilita a criação de textos estruturados. Todos os dados são armazenados em arquivos de texto sem formatação - nenhum banco de dados é necessário.

Eu achei o Dokuwiki o mais fácil de implementar porque não requer banco de dados e era fácil de configurar. Também havia módulos suplementares que permitiam usar meus logons de contas do Active Directory em vez de criar contas para todos, o que foi uma grande vantagem em relação a muitos outros sistemas wiki que encontrei. ele também possui o controle de versão típico, onde você pode ver quem postou o que onde e tem a capacidade de reverter para uma versão anterior com facilidade, se necessário. Eles também incluem uma página inicial personalizável, na qual é possível alterar facilmente qualquer tipo de conteúdo que melhor se adapte ao seu ambiente.

7
mrTomahawk

Com os plugins certos, Trac pode se tornar um sistema combinado de tíquetes e wiki. Isso facilita a vinculação de seus tickets a artigos da wiki e vice-versa.

Alguns plugins que eu gosto:

  • plugin de tickets privados . O Trac é construído como uma base de erros, onde todos os tickets e suas respostas são públicos. Isso não é apropriado para um sistema de ticket de TI, mas esse plugin corrige isso.
  • plugin Trac WYSIWYG . Vamos ser sinceros, a maioria das pessoas não vai aprender wikisyntax para fazer você feliz. Isso fornece a eles um editor de 'o que você vê é o que você obtém' para tickets e páginas da wiki.

Existem algumas mais personalizações para o Trac. Não é difícil configurar e personalizar um sistema Trac ao seu gosto!

6
quux

Doku Wiki ou Sharepoint para outras coisas que se encaixam em um gráfico.

Você se acostuma rapidamente a postar em um wiki e a sintaxe não é tão complexa. É muito fácil organizar informações e encontrá-las mais tarde por outra pessoa.

Eu uso o visio para criar gráficos para explicações mais claras (exportar como JPEG).

6
Antoine Benkemoun

Estamos usando um wiki. De fato, estamos usando o MediaWiki. No topo do MediaWiki, temos o extensão Semantic Mediawiki instalado, que na verdade transforma nosso MediaWiki em algo como um banco de dados de tipo vagamente digitado que podemos consultar com Categoria, título, conteúdo, etc.

Por exemplo, digamos que eu queira ver todos os nomes de rede que são roteados pelo Cluster F. Tudo o que preciso fazer é usar a página Special: Ask para consultar [[Category: cname]] [[destination :: cluster_f]] .. e retornará todas as páginas que são categorizadas como um cname com o destino como cluster_f.

Damos suporte a algumas centenas de clientes muito diferentes, portanto, ter essa documentação em um local central (e tê-la reticulada para que os casos especiais fiquem documentados e vinculados ao todo) é uma coisa muito útil. Obviamente, nossa documentação precisa ser mantida, mas você pode adotar uma abordagem mais 'jardineira' para a manutenção, porque o kit de ferramentas do mediawiki para manter um grande conjunto de dados atualizado já está bastante maduro.

6
Karl Katzke

No meu trabalho anterior, usei o Twiki. Funcionou razoavelmente bem.

Além disso, costumo automatizar a maioria das tarefas e documentar os scripts (nem sempre com muito entusiasmo, mas ainda assim ...). A documentação de scripts é feita facilmente no processo de projetá-los, portanto, não há sobrecarga real ...

A combinação de ambos (e usando o controle de versão para os scripts) fez o truque bastante bem.

5
Vincent De Baere

Uma mistura de documentos JIRA, Confluence e Word.

5
Andrew

Institucionalização do conhecimento

Começamos com documentos. Em seguida, armazenamos alguns deles nas bibliotecas do Sharepoint. Recentemente, fomos para o wiki do Sharepoint. Eu gosto da abordagem de baixo atrito do wiki em atualizar rapidamente as coisas, embora as wikis do Sharepoint deixem algumas coisas a serem desejadas no suporte a gráficos e na formatação de itens como tabelas. É bom para o texto e o editor interno permite alguma formatação HTML básica e listas ordenadas/não ordenadas. Existem outras alternativas de baixo custo para o Sharepoint.

Também temos uma base de conhecimento informal para nossos tickets de suporte em nosso software de help desk, o Track-It da Numara. Não é perfeito, mas funciona.

Conseguir que a equipe use conhecimento institucionalizado

Concordo com a sua avaliação de que a obtenção de conhecimento institucionalizado é apenas uma parte da batalha. Se sua organização e seu pessoal não estão acostumados a "pesquisar primeiro, pergunte em segundo lugar", você descobrirá que a maneira antiga prevalece: todos ainda procuram respostas nos gurus formais e informais, e para algumas pessoas sempre será mais fácil perguntar a pessoa ao seu lado do que pesquisar por conta própria.

Lidar com isso envolverá algum gerenciamento de mudanças; como as iniciativas de mudança mais bem-sucedidas que afetam mais do que apenas uma equipe pequena, ajudará a ter apoio e apoio gerencial. Você realmente precisa forjar um novo comportamento em duas direções; alguém precisa capturar o conhecimento e as pessoas precisam usá-lo. Ainda mais difícil é que as pessoas também precisam manter esses dados atualizados.

Apenas algumas idéias: provavelmente será necessário encorajar na forma de uma política formal, afirmando que tickets e problemas resolvidos precisam ser documentados na base de conhecimento ou wiki antes que possam ser considerados fechados. Além disso, os líderes do conhecimento que normalmente recebem perguntas nem sempre devem oferecer respostas a pedido; eles precisam apontar as pessoas para os wikis e acostumar-se a checar lá primeiro. Outra coisa seria disponibilizar dados aos usuários para auto-ajuda, para que o problema pudesse ser resolvido antes de se tornar mais um item que a equipe técnica precisa manipular.

O que seria legal é que nosso sistema de suporte técnico tenha um sistema semelhante ao StackOverflow e ServerFault: ao digitar uma pergunta, o mecanismo de pesquisa encontra itens semelhantes e os oferece, para que os usuários possam vê-los antes mesmo de enviá-los.

5
Bernard Dy

Nos meus últimos dois locais de trabalho, usei o Wiki do Sharepoint, além de uma biblioteca de documentos que continha certos documentos (como DRPs e planos de atualização única) que não podem ser facilmente criados como documentos do Wiki. Esses documentos tinham links de dentro do Wiki. O Wiki tem muitas vantagens nessa área, pois muitas pessoas podem editá-lo, o controle de versão é embutido, facilmente pesquisável e acessível etc. Para escrever notas e idéias rapidamente, eu usaria o OneNote ou um quadro branco.

Eu já havia criado algumas bases de conhecimento antes, em formato de fórum (tanto no Lotus Notes quanto no MS Sharepoint), mas devo dizer que raramente as pessoas as procuram para ver se um determinado problema já foi resolvido. Essa solução deve vir desde o primeiro dia com um mecanismo de pesquisa muito forte e eficaz.

Se você deseja criar documentos que possam ser usados ​​durante as férias, escreva-os como se estivesse tentando instruir um de seus pais. Isso não é 100% infalível, mas às vezes ajuda. Depende de quem está lendo.

4
Moshe

Sharepoint é agradável.

Seus recursos de pesquisa têm a capacidade de indexar quase qualquer tipo de documento, tornando a pesquisa de documentação realmente fácil.

Ele também pode fazer alguns modelos, o que pode facilitar as coisas se, por exemplo, você tiver uma folha de informações padrão para cada servidor que você criar.

Ele também pode versão seus documentos para você, para que você tenha um histórico de auditoria de alterações na documentação.

Além disso, os arquivos contidos nas bibliotecas de documentos podem ser acessados ​​pela Web, no Outlook ou por meio de um compartilhamento não incluso, pronto para uso.

4
Dominic D

Nós usamos MediaWiki (com fckeditor) por vários anos, embora eu deva dizer que seria bom se o manuseio de imagens (por exemplo, capturas de tela) fosse mais fácil. E apesar de ter a capacidade de pesquisar é essencial - acho que a pesquisa do MediaWiki frequentemente perde páginas. Talvez seja apenas uma questão de aprender a pesquisar melhor (o que meio que derrota o propósito de ter uma maneira simples para que outras pessoas façam seu trabalho)

No momento, estamos conversando sobre mudar tudo para MS Sharepoint, embora não seja necessário para o wiki deles. Eu acho que o Sharepoint é capaz de fazer pesquisa completa de documentos de uma maneira que negue algumas das vantagens de um wiki, então vamos ver onde isso vai.

(não estamos ansiosos pelo processo de portar toda a documentação atual :))

3
Brent

Estamos usando um wiki. Claro que a sintaxe demorou um pouco para se acostumar, mas a que estamos usando (twiki) armazena seus dados inteiramente como arquivos de texto. Isso nos permite lê-los facilmente no caso de um desastre, já que podemos restaurá-los para qualquer lugar, pesquisá-los na linha de comando via grep e lê-los em qualquer editor de texto de que gostamos.

Todo servidor possui uma página, com uma coleção padrão de subpáginas para informações sobre gerenciamento de alterações, inicialização/desligamento e notas de configuração, além de informações sobre DNS, firewall e ativos.

3
Laura Thomas

Na ONG em que trabalho, usamos apenas arquivos de texto colocados em uma pasta para procedimentos críticos. Pessoalmente, como um híbrido de Administrador do Sistema/Desenvolvedor da Web, tenho usado uma base de conhecimento de arquivos de texto espalhados em um diretório em árvore, esse é o meu Memex e escrevo quase tudo nele (pessoal, trabalho etc.) ) Esse esquema é muito fácil de gerenciar, usando Jedit um verdadeiro canivete suíço para processamento de texto, eu achei indispensável o plug-in de esboço, o dobramento de código e os recursos de pesquisa em geral. Tudo isso foi feito com segurança pelo rsync em um servidor remoto acessível por ssh.

alt text

Junte isso ao Makelink Firefox Extension e você terá o gerenciador de favoritos perfeito.

2
cgomezsilva

Estamos nos preparando para migrar para uma versão do serviço Sharepoint para tentar nos livrar de uma mistura de documentos do Word espalhados por três servidores e quem sabe quantas pastas. Atualmente, temos uma enorme planilha do Excel que contém hiperlinks para os documentos descritos nela.

Não é a melhor maneira de fazê-lo, mas quando a empresa começou, eles nunca planejaram como lidar com a documentação interna e deixaram para cada grupo decidir como classificar e armazenar sua própria documentação como quisessem. Agora, estamos tentando nos unir a um sistema unificado, que será em torno de uma das ofertas do Sharepoint.

2
user41811

Esta pergunta é muito bem uma duplicata de esta e mudei minha resposta para lá.

1
jtimberman

Eu não vi essa pergunta antes de responder outra pergunta , mas aqui vamos nós.

Usamos várias ferramentas e métodos.

  • Especificações funcionais para componentes e software de infraestrutura.
  • Dois Confluence Wikis . Um para documentação corporativa interna (políticas, procedimentos, infraestrutura interna e TI, etc) e outro para nossos produtos de software de código aberto.
  • RSpec e Pepino testes. Nosso software é principalmente escrito em Ruby, e praticamos BDD / TDD , portanto testes de especificação conduzem o código real e documentam também.
  • Documentação de código embutido. Usamos a marcação RDoc nos comentários do código.
  • Gerenciamento de configuração declarativa ( Chef ). Todos os nossos servidores são gerenciados com o Chef, que "se autodocumenta" através de recursos delcarativos em receitas e livros de receitas.

Nós gostamos do Confluence porque é muito flexível e poderoso e possui recursos completos, além de estar vinculado ao software de gerenciamento de tickets de que gostamos, Jira .

Nas empresas anteriores em que trabalhei, usei uma variedade de ferramentas e métodos e muitos tentaram permanecer com um único recurso abrangente (como um Wiki) para tudo. O problema disso é documentar vários tópicos com uma única ferramenta não adequada para cobrir esse tópico, significa que muitas coisas não serão documentadas, porque é difícil migrar as informações. Como um geek do Unix/Linux, acredito que cada tarefa requer uma ferramenta específica, e essa ferramenta deve se encaixar muito bem nessa tarefa.

1
jtimberman

Estamos usando o ScrewTurn para conteúdo e o SharePoint para armazenar documentos/imagens.

1
Jeff

Existem algumas coisas interessantes aqui - eu gosto da sobre as senhas em um cofre.

1
Preet Sangha

Não responderei com um sistema de documentação que usei, mas com algo que vi usado e que acho muito bom: http: //stackexchange.com/

stackexchange é a plataforma de perguntas e respostas executada sob falha do servidor (bem, tecnicamente, não é exatamente a mesma coisa, mas, para nosso propósito, podemos assumir que é a mesma).

Fogbugz sa .

Existe um interessante postagem no blog de um funcionário do Fogbugz onde encontrei essas citações:

Para todos os fins fora das especificações do produto, acho que os wiki corporativos e os formulários de discussão foram um golpe fatal.

...

Desde que começamos a usar o FogBugz.StackExchange.com como nossa plataforma de suporte, nunca respondi à mesma pergunta duas vezes. Temos até um servidor SE interno que usamos para perguntas e respostas não públicas, e os mesmos princípios se aplicam a ele.

Eles usam stackexchange para a base de conhecimento voltada para o cliente e a base de conhecimento interna.

Estou interessado em ver se essas plataformas de perguntas e respostas sobre troca de conhecimento substituirão os wiki corporativos.

1
Steven

Usamos flexwiki , que é um dotnet e código aberto.

1
James Moore

Erm ... que tal Fogbugz? :)

1
Chopper3

Eu faço a maior parte da documentação da minha empresa, e o formato que foi estabelecido quando comecei a trabalhar aqui foi o MS Word para originais editáveis, exportados para PDF para lançamentos gerais somente leitura. Funciona razoavelmente bem para projetos em que apenas uma pessoa está atualizando o documento e, como essa pessoa geralmente sou eu, a gerência não vê necessidade de mudar.

Começamos a documentar nossos bugs e as próximas tarefas com Trac , enquanto usamos uma extensão "Revisão por pares" para revisões de código. Essa foi uma grande aceitação da nossa equipe, porque é simples colaborar e fácil de navegar. Alguns outros membros da equipe expressaram o desejo de começar a colaborar mais com especificações, procedimentos de teste e manuais, por isso estamos analisando o DocBook/XML exportado para PDF para documentação pública como manuais e Páginas Trac WIKI para documentos internos, como especificações e procedimentos de teste.

Na minha opinião, os maiores problemas ao escolher um formato de documentação são:

  1. É fácil criar?
  2. É fácil de manter?
  3. É fácil manter se alguém o escreveu?
  4. Pode ser exportado/convertido para outros formatos sem muito aborrecimento?

1-3 facilitam minha vida e são importantes para produzir documentação rapidamente, sem enlouquecer. Eu acho que o quarto é o mais importante para o cliente, porque os formatos mudam continuamente. O formato Microsoft Word 2003 não estará disponível para sempre, nem nossa implementação atual de PDF. Preciso garantir que todos os nossos clientes possam ler nossos documentos, independentemente do sistema operacional ou do leitor de documentos escolhido.

1
andrewd18

Usamos uma combinação de arquivos de texto para pesquisa rápida com grep. E o SharePoint para uma coleção mais organizada de documentação detalhada (diagramas do Visio etc.).

1
TCampbell

Como clientes do Google Apps (Enterprise), usamos o Paradiso do Google Sites - seu "sabor" no wiki. Fácil de usar e tivemos uma ótima adoção de administradores e desenvolvedores.

1
Chris_K

Usamos o MediaWiki com vários plugins, incluindo o SemanticMediaWiki. SMW é bom porque transforma nossa instalação do MediaWiki em um grande banco de dados relacional de formato livre que pode ser consultado à vontade. Precisa saber em qual servidor o site está? Visite sua página. Precisa saber quais sites estão hospedados em um servidor? Execute uma consulta e escolherá os nomes das páginas com base na tag apropriada na página de cada site.

1
Karl Katzke

No meu local de trabalho, derrubei o ScrewTurn Wiki em um de nossos servidores de desenvolvimento Windows e o vinculei ao nosso SQL Server. Funciona muito bem, roda rapidamente e principalmente fica fora do nosso caminho para a documentação. Nas duas semanas desde que foi implantado, já adicionamos cerca de 60 páginas de informações, e é apenas para nossa equipe (~ 10 pessoas).

Até o momento, mantemos informações sobre projetos atuais e passados ​​e começamos a adicionar informações sobre os aplicativos, como como construí-los do zero, URLs e outras informações importantes para os desenvolvedores que são novos na equipe.

Uma das minhas páginas favoritas no wiki tem sido a página de ferramentas e bibliotecas. Lá, começamos a adicionar informações sobre nossas ferramentas e bibliotecas favoritas de produtividade que usamos muito, como um exemplo do grepWin para pesquisa de texto no Windows.

Eu recomendaria totalmente verificar toda a gama de wiki disponíveis e encontrar uma que se adapte ao uso, funcionalidade e ambiente de implantação pretendidos. Eu escolhi o ScrewTurn porque é fácil de usar e tínhamos muito espaço livre em nosso WinServer local, mas o YMMV.

0
MattGWagner

Tente Redmine. Eu usei-o para projetos de grupo da faculdade, bem como projetos da indústria.

Inclui suporte para wikis, documentos, notas, svn (acredito que eles estejam trabalhando no git), solicitações de recursos, rastreamento sofisticado de bugs e tudo é automaticamente adicionado aos gráficos de Gantt para monitorar o desenvolvimento.

É uma plataforma MUITO legal, onde você pode adicionar diferentes níveis de usuários (desenvolvedores, observadores, usuários, etc.) e compartilhar muitas informações entre todos.

http://www.redmine.org

0
DarwinSurvivor

Estamos usando o Confluence como wiki e sharepoint para documentos em alguns casos. Eu acredito que o formato wiki online é o preferido quando você precisa compartilhar essas informações amplamente e o que é muito mais importante quando os documentos são editados e atualizados com muita frequência. Então, acho que é melhor colocar os artigos da base de conhecimento no wiki.

0
Leonid Shirmanov

Atualmente, estamos movendo nossas informações de vários documentos espalhados pela rede para dois locais:

  1. Um wiki disponível em nossa intranet
  2. Uma cópia das informações relacionadas a um servidor específico nesse diretório de servidores/raiz.

Para diagramas de rede, Network Notepad .

Além disso, ao gravar o quê, lembre-se de registrar por que algo está configurado como está. Isso ajuda a impedir que idéias que parecem boas sejam transformadas em erros.

0
David

MindTouch Deki (também conhecido como DekiWiki ou "MindTouch") é a minha escolha aqui, por vários motivos:

  • parece e funciona perfeitamente, mas também é facilmente extensível com extensões, scripts ou modelos
  • ele usa um editor WYSIWYG, para que os usuários não possam usar "Não quero aprender wikitext" como uma desculpa para não documentar
  • todos os dados são armazenados em XML, o que significa que todas as páginas podem ser operadas como um serviço da Web XML
  • aPI fácil de usar, operada com REST (verbos HTTP padrão)
  • linguagem de script fantástica, DekiScript , tornando os mashups triviais
  • absolutamente lindo PDF saída usando Prince , o mecanismo HTML/CSS dos autores do CSS

Como eu uso isso? Como uma base de conhecimento completa, dividida em seções para cada departamento, com páginas abaixo para tudo o que possa precisar de informações armazenadas sobre ele!

Em relação aos sistemas de monitoramento de rede, é possível fazer o download de um Zenoss/MindTouch Deki mashup para colocar dados ao vivo de uma instalação do Zenoss nas páginas wiki do MindTouch para itens como notas de configuração e outros possíveis mashups futuros.

A edição de código-fonte aberto é comercializada como "Núcleo", e os recursos adicionais da edição comercial incluem conectores para serviços como SugarCRM e Salesforce, e bancos de dados como Microsoft SQL Server. Os clientes comerciais também têm acesso aos conectores do Windows (Outlook/Word etc) e a um aplicativo dektop para manipulação do wiki.

Instalação em IIS é tão simples quanto instalar o MySQL e depois instalar um MSI. O MSI é tecnicamente apenas para a edição corporativa, mas existem soluções alternativas para usá-lo em ambiente aberto Uma alternativa é instalar o dispositivo VM (especialmente se você já possui uma infraestrutura de servidor VMware)); nesse caso, você realmente não precisa de nenhuma configuração.

0
crb

Descobrimos que o MediaWiki foi um iniciante lento, mas uma vez que as pessoas fora da TI descobriram como era fácil adicionar comentários, alterações, edições etc., tornou-se indispensável. Os desenvolvedores estão usando-o para documentação interna, departamento de instalações. para publicação de avisos etc. Ele cresceu além de ser apenas uma ferramenta de documentação de TI.

0
bren

No meu empregador anterior, usei arquivos do Word, Excel e Visio coletados juntos em uma pasta. Uma cópia impressa de tudo estava guardada em uma pasta na minha mesa. Eu era a única pessoa de TI, então havia pouca necessidade de mais alguém ter acesso às informações.

No meu atual empregador, usamos o Macola ES da Exact Software, mas ainda prefiro escrever minha documentação no Word e carregá-la no Macola como anexo do que usar o editor de documentos embutido.

0
Scott

MediaWiki aqui também. Sou o único suporte de TI da empresa de contabilidade em que trabalho, portanto, neste momento, não preciso me preocupar com a colaboração. Mesmo assim, acho que um wiki funciona incrivelmente bem para o tipo de mudanças rápidas que eu faço regularmente.

O único problema que tenho é que qualquer coisa sensível (por exemplo, senhas) é armazenada fora do Wiki em um armazenamento mais seguro, mas seria bom tê-lo disponível imediatamente.

0
Nic