Berbagi pengetahuan perusahaan?


20

Saya baru-baru ini membaca artikel ini tentang berbagi pengetahuan dan segera mengenali masalah yang sama dalam organisasi saya sendiri. Tujuan utama saya sekarang adalah untuk 'membunuh kolaborasi peer-to-peer' sebagai metode komunikasi standar untuk diskusi non-privat, terkait sistem. Kalau tidak, Anda berakhir dengan semua pengetahuan sejarah yang hidup di kepala individu, atau hilang dalam sistem email besar-besaran.

Pertanyaan saya untuk grup adalah sebagai berikut:

  • Metode / perangkat lunak apa yang Anda gunakan untuk mendorong lebih banyak diskusi 'publik' di antara pengembang Anda?

Beberapa ide awal yang saya miliki .. setiap umpan balik akan sangat bagus:

  • Grup berita internal
  • perangkat lunak wiki 'lebih baik' (menggunakan Sharepoint sekarang)
  • Papan pesan

(Saya ingin sekali memiliki instance internal StackExchange, tetapi jangan berpikir itu adalah pilihan!)

Catatan: Seperti yang dinyatakan di atas, kami sudah memiliki wiki, tapi saya tidak suka ide wiki karena hal-hal biasanya hanya ditambahkan ke wiki setelah fakta, jika sama sekali .

Terima kasih!


7
Pertanyaan bagus Kami memiliki masalah yang sama. Kami menyebutnya sindrom "bagaimana jika <insert-name> tertabrak bus". Terima kasih telah menanyakan ini.
DevSolo

1
Atau dikenal sebagai "nomor truk".
Frank Shearar

Berdasarkan jawaban sejauh ini, saya menganggap bahwa kebanyakan orang menggunakan wiki dan email dengan beberapa keberhasilan. Mungkin saya hanya bermimpi ketika saya berpikir pasti ada cara yang lebih baik untuk melakukan ini. : |
mpeterson

1
Kuncinya bukan pada teknologi, tetapi pada manusia. Seperti yang saya lihat di tempat kerja saya, memiliki wiki tidak menyiratkan bahwa orang akan menggunakannya. Jika itu cara yang Anda inginkan, daripada mendorongnya. Saya yakin ada tempat-tempat yang tidak memerlukan alat kolaborasi untuk berkomunikasi secara efektif, karena orang-orang terus berbicara satu sama lain tentang apa yang mereka lakukan. Wiki dll. Harus ada di sana untuk membantu merampingkan berbagi pengetahuan, bukan membuatnya.
Michael K

Kamu benar sekali, Michael! Saya mencoba mengubah 'budaya' berbagi informasi dalam tim pengembangan saya. Teknologi ini tidak sepenting pola pikir.
mpeterson

Jawaban:


3

Kami memiliki situs Sharepoint internal yang besar dan situs dukungan yang menghadap pelanggan, yang mengambil banyak dokumen dari situs Sharepoint internal. Ini kurang tentang detail implementasi dan lebih banyak tentang dukungan yang diakui, tetapi karena saya bekerja sebagian besar dalam kapasitas dukungan kita perlu akses ke banyak informasi implementasi dan akhirnya kami menjadi pendorong bagi tim teknik untuk mendokumentasikan apa yang mereka lakukan dan mengapa. Sistem pelacakan bug terperinci juga berharga untuk menindaklanjuti bagaimana masalah diselesaikan.

Di perusahaan kami, sebagian karena kami memiliki pengembangan yang tersebar di beberapa lokasi, banyak diskusi tentang fitur baru dan masalah dukungan akhirnya terjadi melalui email. Alih-alih mencoba mengubahnya, pendekatan termudah adalah sistem pengarsipan email yang membuat diskusi dapat dicari dan dilacak - secara efektif pendekatan tipe newsgroup. Kami dapat melakukan ini melalui Sharepoint, meskipun kita harus menyadari batas ukuran daftar karena meskipun akan tumbuh menjadi jutaan item Anda tidak dapat benar-benar melakukan banyak hal dalam hal menyortir daftar yang sangat besar atau mengedit tampilan pada mereka tanpa itu hancur secara dramatis.


Ah .. kami punya banyak tugas pendukung juga, dan didistribusikan secara geografis. Email yang diarsipkan / dicari melalui Sharepoint cukup menarik. Itu mungkin kompromi yang tepat ...
mpeterson

Apa yang kami pikir akan berhasil adalah untuk membagi arsip email menjadi potongan tiga bulan sehingga ukuran daftar tetap dapat dikelola. Jelas rentang waktunya akan bervariasi berdasarkan bulan dan kami telah menggunakan SP2007 - mungkin 2010 menangani daftar yang lebih besar dengan lebih baik.
glenatron

1
Saya sangat mempertimbangkan ini. Pasangan ini dengan lebih menekankan pada menggunakan sistem pelacakan bug kami dan mengisi lebih banyak wiki sehingga kami mencapai 'titik kritis' dalam konten, saya pikir ini adalah jawaban terbaik untuk pertanyaan saya.
mpeterson

1
Jika Anda menggunakan Wiki pastikan itu bukan bawaan di Sharepoint satu - saya pikir ada beberapa add-ons yang cukup bagus yang melakukan pekerjaan yang sama dan tidak payah ...
glenatron

4

StackOverFlow untuk perusahaan seperti dijelaskan dalam artikel yang Anda sebutkan?

IMHO itu ide yang buruk .

Ini akan memperkuat kompetisi alih-alih kolaborasi .

Anda perlu kolaborasi lintas divisi / departemen, bukan meningkatkan persaingan mereka.

Juga bayangkan dampak negatif yang sangat tinggi dari downvoting oleh rekan Anda (di depan orang lain) dapat berdampak pada kesehatan psikis Anda.

Jangan mencampur semuanya.

Namun, kotak ide lebih banyak uservoice.com di mana karyawan dapat memposting ide (secara anonim) dan karyawan lain yang memperbaikinya (juga apa pun) akan memiliki dampak positif. Saya mengembangkan platform semacam itu beberapa tahun yang lalu untuk lembaga perbankan yang sangat besar, dan itu membantu para eksekutif untuk mengidentifikasi apa yang harus ditingkatkan dalam prioritas.


1
@Pierre, bagaimana cara melihat persaingan alih-alih kolaborasi? Saya menghargai pandangan Anda, tetapi saya sejujurnya tidak melihatnya. Saya penasaran.
DevSolo

poin = persaingan. Persaingan karena ada peringkat.

Mungkin saya harus lebih jelas ... Saya tidak ingin sistem poin / pemungutan suara. (Saya setuju itu bisa sedikit tegang)
mpeterson

Mpeterson, mungkin saya lebih membalas orang di artikel yang Anda sebutkan. Tetapi saya menyarankan sebuah ide dalam jawaban saya yang bekerja dengan baik di perusahaan global besar.

Bagaimana kotak ide Anda dengan pemungutan suara berbeda dari platform StackExchange?
Robert Harvey

2

Saya sangat menyukai ide wiki, tetapi Anda benar-sulit untuk membuat orang berkontribusi. Dan tanpa kontribusi, tidak ada yang benar-benar akan menggunakannya karena tidak memiliki informasi yang cukup. Namun ada "titik kritis" di mana jika Anda bisa membuat orang memposting (mungkin melalui proses bisnis yang diperlukan) di beberapa titik, wiki hanya akan lepas landas karena itu akan menjadi gudang informasi yang hebat ini.


Kami memiliki masalah di perusahaan saya. Namun, perlahan-lahan semakin banyak orang yang menggunakan wiki, dan manajer saya mendorong orang untuk mencari di sana dan memposting sesuatu. Dia telah menugaskan banyak orang pada waktu-waktu tertentu untuk meletakkan hal-hal tertentu pada wiki yang dia inginkan mudah diakses - saya pikir itu telah membantu.
Michael K

Kami melakukan ini juga, tetapi masih terasa rumit. Mungkin kita belum mencapai titik kritis?
mpeterson

1

Pair Programming adalah cara yang bagus untuk menyebarkan pengetahuan diam-diam.

Masalah dengan pengetahuan diam-diam adalah bahwa hal itu dapat cukup banyak dengan definisi tidak ditulis atau diajarkan, hanya dialami. Pairing programming (khusus Promiscuous Pairing) menyediakan itu.


1

Pengetahuan yang penting bagi perusahaan harus membuatnya menjadi proyek itu sendiri, dalam bentuk kode yang ditulis dengan baik, komentar tingkat tinggi tentang arsitektur, dan dokumentasi luar biasa tentang tujuan proyek dan bagaimana mereka dicapai dengan teknologi.

Saya tidak bisa tidak setuju dengan kesimpulan penulis yang ditautkan. Mendorong penangkapan pengetahuan dengan mengecilkan kolaborasi tim? Maaf, tapi itu bukan cara kerjanya. Ini adalah kolaborasi itu sendiri yang menghasilkan kekayaan pengetahuan, bukan mengasingkan insinyur di bilik.


Saya menganggap bahwa penulis hanya mencoba untuk mencegah kolaborasi 1-ke-1 secara pribadi, bukan sepenuhnya?
mpeterson

Juga +1 untuk komentar tentang pengetahuan yang menjadi proyeknya sendiri. Itu sepertinya selalu menjadi aset yang terlupakan dalam membangun banyak proyek internal. : |
mpeterson

1
mpeterson: Dalam pengalaman saya, sebagian besar kolaborasi tim asli dan pengembangan pengetahuan kreatif terjadi satu lawan satu, dalam cara ad-hoc, informal, bukan dalam rapat.
Robert Harvey

0

Perusahaan saya memiliki beberapa papan diskusi internal. Mereka digunakan sangat jarang. Sebagian besar, pengetahuan yang kita miliki terlalu umum (pertanyaan / topik teknologi umum yang dibahas dengan baik di internet) atau terlalu spesifik (hanya berlaku untuk aplikasi kita dan tidak untuk tim aplikasi lain di perusahaan yang sama). Ini bagus karena memberikan tempat bagi orang-orang untuk mengatakan bagaimana saya mencapai xyz di sini tetapi tidak banyak merasakan komunitas.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.