Kurumsal bilgi paylaşımı?


20

Kısa süre önce bilgi paylaşımı hakkındaki bu makaleyi okudum ve aynı sorunu kendi kuruluşumda hemen tanıdım . Şimdi asıl amacım, özel olmayan, sistemle ilgili tartışmalar için varsayılan iletişim yöntemi olarak 'eşler arası işbirliğini öldürmek'. Aksi takdirde, bireylerin kafalarında yaşayan veya büyük bir e-posta sisteminde kaybolan tüm tarihsel bilgilerle sonuçlanırsınız.

Grup için sorum şu:

  • Geliştiricileriniz arasında daha fazla 'genel' tartışmayı teşvik etmek için hangi yöntemleri / yazılımları kullandınız?

Bazı ilk fikirler vardı .. herhangi bir geri bildirim harika olurdu:

  • Dahili haber grubu
  • 'daha iyi' wiki yazılımı (Sharepoint'i şimdi kullanıyor)
  • Mesaj panosu

(StackExchange'in dahili bir örneğine sahip olmak isterdim, ancak bunun bir seçenek olduğunu düşünmeyin!)

Not: Yukarıda belirtildiği gibi, zaten bir wiki'miz var, ancak wiki fikrinden hoşlanmıyorum, çünkü işler genellikle wiki'ye gerçeklerden sonra eklenir, eğer varsa .

Teşekkürler!


7
Harika bir soru. Aynı sorunlarımız var. Biz buna "<insert-name> bir otobüs tarafından vurulursa" sendromu diyoruz. Bunu sorduğun için teşekkürler.
DevSolo

1
Aksi takdirde "kamyon numarası" olarak bilinir.
Frank Shearar

Şimdiye kadarki cevaplara dayanarak, çoğu insanın wikileri ve e-postayı başarılı bir şekilde kullandığını düşünüyorum. Belki de bunu yapmanın daha iyi bir yolu olması gerektiğini düşündüğümde rüya görüyordum. : |
mpeterson

1
Anahtar teknolojide değil, insanlarda. İşyerimde gördüğüm gibi, bir wiki'ye sahip olmak insanların onu kullanacağı anlamına gelmez. Eğer gitmek istediğiniz yol buysa, teşvik edin. Eminim, etkili bir şekilde iletişim kurmak için işbirliği araçlarına ihtiyaç duymayan yerler vardır, çünkü insanlar sürekli birbirleriyle ne yaptıklarından bahsediyorlar. Wikis vs., bilgi paylaşımını yaratmak için değil, kolaylaştırmak için orada olmalıdır.
Michael K

Kesinlikle haklısın, Michael! Geliştirme ekibimde bilgi paylaşımının 'kültürünü' değiştirmeye çalışıyorum. Teknoloji zihniyet kadar önemli değil.
mpeterson

Yanıtlar:


3

Dahili Sharepoint sitesinden çok sayıda belge alan büyük bir dahili Sharepoint sitemiz ve müşteriye dönük bir destek sitemiz var. Bu, uygulama ayrıntısıyla daha az ve kuşkusuz destekle ilgili daha fazladır, ancak büyük ölçüde bir destek kapasitesinde çalışırken, birçok uygulama bilgisine erişmemiz gerekiyor ve bu nedenle mühendislik ekibinin ne yaptığını ve nedenini belgelemeleri için sürücüler haline geliyoruz. Ayrıntılı bir hata izleme sistemi de sorunların nasıl çözüldüğünü takip etmek için değerlidir.

Şirketimizde, kısmen birkaç yere yayılmış bir gelişme gösterdiğimiz için, yeni özellikler ve destek sorunları hakkında e-posta üzerinden birçok tartışma yaşanıyor. Bunu değiştirmeye çalışmak yerine, en kolay yaklaşım, tartışmaları aranabilir ve izlenebilir hale getiren bir e-posta arşivleme sistemidir - etkin bir haber grubu türü yaklaşımıdır. Liste boyutundaki sınırların farkında olması gerekse de, Sharepoint aracılığıyla bunu yapabiliyoruz, ancak çok büyük listeleri sıralamak veya bunlar üzerindeki görünümleri düzenlemek açısından çok fazla yapamayacağınız milyonlarca öğeye büyüyecek gibi dramatik bir şekilde çöküyor.


Ah ... birçok destek görevimiz de var ve coğrafi olarak dağıtılıyor. Sharepoint aracılığıyla arşivlenen / aranabilir e-postalar oldukça ilginç. Bu uygun uzlaşma olabilir ...
mpeterson

İşe yarayacağını düşündüğümüz şey, liste boyutlarının yönetilebilir kalması için e-posta arşivlerini üç aylık parçalara bölmektir. Açıkçası zaman aralığı aya göre değişecek ve SP2007'yi kullandık - 2010'un daha büyük listeleri daha iyi ele alması olabilir.
glenatron

1
Bunu çok düşünüyorum. Hata izleme sistemimizi kullanmaya ve wiki'nin daha fazlasını doldurmaya daha fazla vurgu yaparak bunu bir araya getirerek içerikteki 'devrilme noktasına' ulaşacağımızı düşünüyorum, bu sorumun en iyi cevabı olduğunu düşünüyorum.
mpeterson

1
Wiki kullanıyorsanız, Sharepoint'te yerleşik olmadığından emin olun - Aynı işi yapan ve
emmeyen

4

Bahsettiğiniz makalede açıklanan gibi kurumsal için StackOverFlow?

IMHO korkunç bir fikir .

İşbirliği yerine rekabeti güçlendirecektir .

Rekabetlerini artırmamak için çapraz bölüm / departman işbirliğine ihtiyacınız var.

Ayrıca (başkalarının önünde) iş arkadaşınız tarafından reddedilmenin son derece yüksek olumsuz etkisinin psişik sağlığınız üzerinde olabileceğini hayal edin.

Her şeyi karıştırmayın.

Bununla birlikte, çalışanların fikirlerini (anonim olarak) gönderebileceği ve diğer çalışanların onları (anonom olarak da) onaylayabileceği çok daha fazla uservoice.com olumlu bir etki yaratacaktır. Birkaç yıl önce çok büyük bir bankacılık kurumu için böyle bir platform geliştirdim ve yöneticilere neyin öncelikli olarak neyin geliştirileceğini belirlemelerine yardımcı oldu.


1
@Pierre, işbirliği yerine rekabeti nasıl görüyor? Senin görüşüne saygı duyuyorum, ama dürüstçe görmüyorum. Merak ediyorum.
DevSolo

puan = rekabet. Rekabet çünkü bir sıralama var.

Belki daha açık olmalıyım ... Bir puan / oylama sistemi istemiyorum. (Bu biraz gergin olabilir kabul ediyorum)
mpeterson

Mpeterson, belki de bahsettiğiniz makaledeki adama daha çok cevap veriyordum. Ama cevabımda büyük bir küresel şirkette iyi çalışan bir fikir önerdim.

Oylamaya sahip fikir kutunuzun StackExchange platformundan farkı nedir?
Robert Harvey

2

Wiki fikrini de çok seviyorum, ama haklısın - insanların katkıda bulunmasını sağlamak zor. Ve katkı olmadan, hiç kimse gerçekten kullanamaz çünkü yeterli bilgiye sahip değildir. Bir "devrilme noktası" ancak hangi (belki de gerekli bir iş süreci aracılığıyla) insanların bir noktada göndermek için alabilir eğer wiki sadece bu büyük bilgi deposu olarak çıkarmak olacaktır.


Şirketimde bu sorun var. Bununla birlikte, yavaş yavaş daha fazla kişi wiki'yi kullanıyor ve yöneticim insanları oraya bakmaya ve bir şeyler göndermeye teşvik ediyor. Kolayca erişilebilir olmasını istediği wiki'ye belirli şeyler koymak için zaman zaman çeşitli insanlar görevlendirdi - bence bu yardımcı oldu.
Michael K

Bunu da yapıyoruz, ama yine de hantal geliyor. Belki henüz devrilme noktasına gelmedik?
mpeterson

1

İkili Programlama, örtük bilgiyi yaymanın harika bir yoludur.

Örtük bilgi ile ilgili sorun, tanım gereği sadece yazılıp öğretilemeyen, sadece deneyimli olabilmesidir. Çift programlama (özellikle Karışık Eşleştirme) bunu sağlar.


1

İşletme için önemli olan bilgi, projeyi, iyi yazılmış bir kod, mimari hakkında üst düzey yorumlar ve projenin hedefleri ve teknoloji ile nasıl gerçekleştirildiği hakkında olağanüstü belgeler biçiminde projenin kendisine dönüştürmelidir.

Bağlantılı yazarın sonuçlarıyla daha fazla anlaşamadım. Ekip işbirliğini caydırarak bilgi yakalamayı teşvik etmek mi? Üzgünüm, ama böyle çalışmaz. Mühendisler hücrelere ayırmak değil, bilgi zenginliğini üreten işbirliğinin kendisidir.


Yazarın sadece özel olarak bire bir işbirliğini caydırmaya çalıştığını aldım, tamamen değil mi?
mpeterson

Ayrıca, bilginin kendi projesi olduğu hakkındaki yorum için +1. Bu her zaman birçok iç projenin yapımında unutulmuş bir varlık gibi görünüyor. : |
mpeterson

1
mpeterson: Deneyimlerime göre, en gerçek ekip işbirliği ve yaratıcı bilgi oluşturma toplantılarda değil, ad hoc, gayri resmi bir şekilde bire bir gerçekleşir.
Robert Harvey

0

Şirketimin bazı dahili tartışma panoları var. Çok nadiren kullanılırlar. Çoğunlukla, sahip olduğumuz bilgi ya çok geneldir (internette iyi tartışılan genel teknoloji soruları / konuları) ya da çok özeldir (aynı şirketteki diğer uygulama ekipleri için değil, sadece başvurumuz için geçerlidir). İnsanların burada xyz'i nasıl başarabileceğimi söyleyecekleri bir yer vermesi iyidir, ancak bu bir topluluk hissi değildir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.