Pytanie:
W jaki sposób Twoi najbardziej zajęci ludzie przekazują swoją wiedzę?
Reinstate Monica - Goodbye SE
2012-04-13 02:22:23 UTC
view on stackexchange narkive permalink

Niedawno przeprowadziliśmy ankiety wśród użytkowników wiki z całej naszej firmy i odkryliśmy, że istnieją dwie duże grupy użytkowników:

  • osoby z dużą wiedzą , ale (które twierdzą, nie mają) czasu na dokumentowanie
  • ludzi z czasem , ale (którzy twierdzą, że mają) niewystarczającą wiedzą wartą udokumentowania

Każda grupa objęła prawie 50% użytkowników!

Jak Twoje firmy sobie z tym radzą? To znaczy, w jaki sposób zachęcasz swoich najbardziej zapracowanych / posiadających największą wiedzę ludzi do dzielenia się swoją wiedzą?

związany z PM.SE p: [Jak zachęcasz członków projektu do dokumentowania ich pracy przed przekazaniem na koniec projektu?] (http://pm.stackexchange.com/q/799/167)
Osiem odpowiedzi:
Karl Bielefeldt
2012-04-13 02:43:06 UTC
view on stackexchange narkive permalink

Możesz zwrócić uwagę posiadaczy wiedzy, że i tak prawdopodobnie spędzają dużo czasu na zadawaniu pytań. Napisanie wpisu na wiki to krótkoterminowa inwestycja, która opłaca się na dłuższą metę. Jeśli nie nękają ich pytania, prawdopodobnie nie jest to wystarczająco ważne, aby je udokumentować.

Ponadto odbiorcy wiedzy są lepszym wyborem do napisania artykułu na wiki, niż mogłoby się wydawać, ponieważ rozumieją sens widok kogoś, kto musi poznać temat. Pomaga także uporządkować i utrwalić ich myśli. Posiadanie większej ilości czasu na napisanie artykułu przez guru i przesłanie go do recenzji może być bardzo korzystne.

+1 za napisanie tego przez odbiorcę. Czasami posiadacz i odbiorca inaczej rozumieją to samo zdanie.
Zgoda na napisanie tego przez odbiorcę, ale poproś posiadaczy wiedzy / ekspertów, aby przejrzeli go na dwóch frontach: poprawności i kompletności. Dobra dokumentacja wyjaśnia zarówno sposób, jak i * dlaczego *.
+1 Zakładanie, że posiadacze wiedzy również potrafią dobrze dokumentować, jest błędem. Nie wspominając o cennym czasie i dobrej karmie, które zaoszczędzimy, zatrudniając odpowiednich ludzi do pracy.
@voretaq7, właściwie jedną z największych zalet wiki jest edycja. Śmiało i opublikuj to, czego się nauczyłeś, zaznacz części, których nie jesteś pewien, i powiadom MŚP lub * następną * osobę, która musi dowiedzieć się o tej kompilacji.
Zgoda na @MonicaCellio - Wiki to świetne zasoby. Niestety edycja przez społeczność może być również wadą, gdy ktoś edytuje niezrozumiane / niepoprawne informacje i zapomni oznaczyć je jako „niepewne” - ostatecznie Wiki jest tak dobre, jak ludzie, którzy sprawdzają ją pod kątem poprawności :-)
także - odbiorcy mogą napisać część "Q" wiki, a posiadacze mogą napisać "A"
Uważam, że strony wiki po prostu nie są czytane ani edytowane na tyle, aby były warte wysiłku.Widziałem, jak próbowali wielu prac, nigdy nie widziałem jednej pracy.
HLGEM
2012-04-13 03:33:59 UTC
view on stackexchange narkive permalink

Jeden z naszych liderów technicznych ma świetne zasady. Za trzecim razem, gdy otrzymuje to samo pytanie, pisze odpowiedź i wysyła ją e-mailem do osoby, która pyta, oraz do utworzonej przez nas wiki wiedzy. Ponieważ i tak prawdopodobnie zamierzała napisać ten e-mail, jedyną dodatkową pracą jest dodanie adresu Wiki.

Dobra ogólna polityka - jeśli zapytano Cię o to trzy razy, ważne jest, aby to udokumentować. Jako bonus prawdopodobnie pomyślałeś o tym na tyle, aby mieć dobrą, spójną odpowiedź, którą można zamieścić w oficjalnej dokumentacji. (Jest to również zasada, której używam do automatyzacji zadań: za trzecim razem należy to zrobić, należy to zautomatyzować)
@voretaq7, Pomyślałem, że część związana z podłączaniem Wiki do wiadomości e-mail z tematami revie wiki była inspiracją dla mnie. O wiele łatwiej jest udokumentować wiedzę, gdy wszystko, co musisz zrobić, to dodać kolejny adres e-mail do wiadomości e-mail, którą i tak zamierzałeś napisać.
Po co czekać trzy razy, jeśli ktoś zadał pytanie, to istnieje prawdopodobieństwo, że zrobi to ktoś inny, więc udokumentuj to, a następnie wyślij im e-mailem łącze do zaktualizowanych dokumentów. Scott Hanselman mówi o idei oszczędzania naciśnięć klawiszy na swoim blogu tutaj: http://www.hanselman.com/blog/DoTheyDeserveTheGiftOfYourKeystrokes.aspx
@ridecar2 Nie jestem ekspertem, ale powiem ten sam powód, dla którego czekam do trzeciego razu, aby zautomatyzować zadanie: czasami robienie tego samemu jest szybszym / lepszym rozwiązaniem, jeśli ma się to zdarzyć tylko raz, a często nie. wiem, że za pierwszym razem będzie to powtarzalna rzecz. Za trzecim razem zbliżasz się do punktu zwrotnego kosztów i korzyści, w którym oczywiste jest, że zadanie będzie się pojawiać, a dokumentacja lub automatyzacja na pewno się opłaci na dłuższą metę.
Utworzenie posta na blogu w celu wysłania wiadomości e-mail nie wiąże się z dodatkowymi kosztami, więc dlaczego nie zamieścić posta na blogu od razu? Zgadzam się na automatyzację zadań, w których ustawienie tego jest trudne, ale nie o to mi chodziło.
Atif
2012-04-13 02:41:21 UTC
view on stackexchange narkive permalink

Sugeruję nagrywanie screencastów trwających około 45 minut. Zbierz wszystkich razem, a prezenter przygotuje screencast i przekaże wiedzę. Łatwiej i skuteczniej jest pokazać , jak coś zrobić, a potem po prostu napisać dokumentację (która może również obejmować dodatkowy czas na formatowanie itp.)

W jednym miejscu pracowałem , mieli „Lunch n'learn” co tydzień lub co miesiąc. Jeden facet zjada obiad wcześnie i podczas jedzenia robi prezentację dla zespołu. Może to zadziałać, jeśli ludziom brakuje czasu.

+1 świetny pomysł! Mieliśmy podobny pomysł i firma zapewniła lunch, aby zachęcić do udziału.
Lunch i nauka to straszna praktyka.Jeśli szkolenie jest na tyle ważne, powinno się to odbywać w godzinach pracy, a nie podczas przerwy. Pora obiadowa NIGDY nie powinna obejmować pracy.
@HLGEM - Jestem * OGROMNY * * wierzący w Lunch & Learns.Jednak nigdy nie były liczone jako czas przerwy, kiedy byłem zaangażowany. Uważam również, że ekspert merytoryczny w określonej dziedzinie * NIE * powinien być tym, który przeprowadza prezentację.Najlepszą praktyką, jaką widziałem, jest przydzielanie średnim i młodszym pracownikom odpowiedzialnym za przygotowanie prezentacji.Podchodzą do tego z mniejszą liczbą założeń i sprawiają, że jest bardziej przystępny.a kiedy się do tego przygotowują, uczą się tego.
Nie jestem przeciwny tego typu szkoleniom tylko po to, aby nigdy nie odbywały się podczas obiadu, który zwykle nie jest płatny i nie należy do firmy.To jest tak samo złe, jak proszenie mnie o trening po obiedzie.Istnieje dobry powód, dla którego przerwy na lunch są prawnie wymagane w wielu jurysdykcjach.
Mark Booth
2012-04-17 19:14:11 UTC
view on stackexchange narkive permalink

Najlepszym sposobem na transfer wiedzy jest praca z osobami posiadającymi wiedzę.

Osoby posiadające wiedzę mogą nie mieć czasu na pracować nad samodzielnym dokumentowaniem swojej wiedzy, być może już poświęcają część swojego czasu na wyjaśnianie innym, co mają robić i jak to zrobić.

Nawet jeśli dobrze poinformowani ludzie mieli czas na zapisanie swojej wiedzy, niekoniecznie jest tak, że stworzona przez nich dokumentacja byłaby przydatna dla mniej doświadczonych osób. Zaskakująco łatwo jest przeoczyć ważne „ oczywiste ” informacje, próbując przekazać wiedzę.

Poprzez uczynienie transferu wiedzy bardziej jawnym i opartym na współpracy, a użytkownicy dokumentacja napisać to tak, aby mogli to zrozumieć, możesz zarówno zmniejszyć obciążenie znających się na rzeczy ludzi, i uzyskać więcej informacji.

Jeśli posiadający wiedzę ludzie są naprawdę pod presją czasu, możesz poprosić ludzi, którzy potrzebują tej wiedzy, aby napisali to, co rozumieją teraz , a następnie poprosić tych posiadających wiedzę o korektę i poprawienie wszelkich nieporozumień. Może to znacznie przyspieszyć działanie, a także pomóc zidentyfikować obszary, w których brakuje wiedzy.

Jako przykład pracuję nad oprogramowaniem naukowym. Ani ja, ani naukowcy z ośrodka, z którymi pracuję, nie moglibyśmy samodzielnie udokumentować większości oprogramowania, które piszę. Mógłbym wyjaśnić, co robi moje oprogramowanie, a nawet dlaczego robi to w ten sposób, ale to naukowcy zajmujący się placówką muszą napisać dokumentację o tym, dlaczego i jak wizytujący naukowcy powinni go używać.

W istocie jest to dokładnie jedno z rozważanych przez nas rozwiązań; jest podobny do idei * praktyk zawodowych *. Dodatkowo praktykant (który prawdopodobnie ma więcej czasu) może niż dokumentować to, czego się nauczył.
voretaq7
2012-04-13 03:20:54 UTC
view on stackexchange narkive permalink

Moja sugestia jest taka, aby poświęcić czas na dokumentację każdego projektu i uczynić go nieodłączną częścią tego, co robisz. Jeśli nie robiłeś tego przez cały czas, prawdopodobnie będziesz musiał zaplanować "Dni Dokumentacji", aby przyspieszyć rozpoczęcie pracy (na przykład, powiedzmy, że każdy piątek po obiedzie osoby posiadające wiedzę są uwalniane od wszystkich innych projektów i po prostu pracują nad pisaniem dokumentacji). / p>

Wprowadzenie kultury dokumentacji do firmy może być trudne, gdy nigdy wcześniej nie było to częścią tego, co robiono wcześniej, ale korzyści są oczywiste, gdy możesz zatrudnić nową osobę i sprawić, by była na bieżąco i niezależna praca w ciągu tygodnia - na przykład projekt PostgreSQL ma silną kulturę utrzymywania doskonałej dokumentacji. Ich instrukcja jest lepsza niż niektóre produkty komercyjne.

W zasadzie się zgadzam, ale wielokrotnie widziałem, że dokumentacja została pominięta z powodu krótkoterminowego myślenia z terminem realizacji projektu.
@Wikis Zła kultura korporacyjna IMHO. Dokumentacja jest częścią produktu (w moim przypadku dosłownie: międzynarodowe standardy i przepisy federalne wymagają tego od producentów urządzeń medycznych, więc nie muszę się o to zbytnio spierać. Mam szczęście :-)
Karlson
2012-04-13 02:33:21 UTC
view on stackexchange narkive permalink

Z mojego doświadczenia wynika niefortunna tendencja, jeśli chodzi o transfer wiedzy, a jest nią brak zainteresowania ze strony odbiorcy . Możesz poprosić osobę, która zechce zrobić zrzut mózgu komuś innemu, ale jeśli nie jest zainteresowany jego otrzymaniem, po co ekspert miałby to poświęcić?

Kiedy zostawiałem kilka miejsc, w których pracowałem, poproszono mnie o zrobienie tego, ponieważ byłem jedną z nielicznych osób, które rozumiały systemy, które obsługuję, ale kiedy ktoś został mi przydzielony do tego zadania, widziałem w jego zachowaniu, że jest to dla nich uciążliwe i oni nie był tym zainteresowany. Więc moja motywacja do transferu wiedzy została w zasadzie zredukowana do zera.

Więc jedyną rzeczą, jaką mogłem zasugerować na ten temat, jest upewnienie się, że osoba otrzymująca wiedzę jest rzeczywiście zainteresowana tematem. Zniewolona publiczność, która zadaje pytania, czyni cuda, jeśli chodzi o motywację mówcy.

+1 - Jako jedna z „najbardziej zajętych osób” często trudno mi znaleźć czas od * wszystkich innych *, aby odpowiednio ich wyszkolić.
+1 - @voretaq7 - Wiele razy sugerowałem innym, żebym mógł im wyjaśnić, dlaczego lub w jaki sposób coś zrobiłem, i kazałem im powiedzieć, że nie uważają tego za konieczne. Więc może częścią problemu jest posiadanie chętnych odbiorców wiedzy.
@Giliane Brzmi jak osobne, ale ściśle powiązane problemy, które prowadzą do tego samego celu: w moim przypadku odbiorcy wiedzy faktycznie * chcieli * się uczyć, ale albo byli naprawdę zbyt zajęci, kiedy miałem czas na nauczanie, albo ich przełożeni odmówiliby im pozwolenia przestój na szkolenie, ponieważ przełożony nie widział wartości.
Tangurena
2012-04-13 04:59:50 UTC
view on stackexchange narkive permalink

Zawsze staram się założyć wiki, aby dokumentować rzeczy. Wiki są proste i zachęcają do dodawania fragmentów w miarę upływu czasu. W przypadku formalnych systemów dokumentacji czysty papier wydaje się przytłaczający dla użytkowników i w rezultacie zostaje wypełniony dopiero po przyłożeniu broni do głowy. Zwykle chodzę z notatnikiem i wpisuję rzeczy na wiki, aby można je było łatwo zlokalizować - w ten sposób roczne zadania mogą być poprawnie powtarzane, zamiast konieczności ponownego odkrywania, jak miały się odbyć.

Jeden z poprzednich szefów był skłonny zezwolić tylko na „pełne i kompletne dokumenty”, które nigdy nie zostały sporządzone. Zablokował wiki, ponieważ uważał, że zachęcają one do swobodnego myślenia i słabej dokumentacji. Ponieważ wszystkie poprzednie „pełne i kompletne dokumenty” miały ponad 5 lat w momencie, gdy wyjeżdżałem, nie dbał o to, aby zrozumieć, że jego pragnienia stoją w sprzeczności z tym, jak pracował jego personel.

Tylko w najgorszej sytuacji kryzysowej, kiedy odeszła jedna krytyczna osoba, stworzył i nagrał webcast przedstawiający przejście przez kod, który tylko on rozumiał. To był jeden z nielicznych przypadków, kiedy pracownik dał zawiadomienie, że przekazał wiedzę, zamiast pracować nad rzeczami do dnia swojego wyjazdu.

Hi pals
2012-04-13 04:06:32 UTC
view on stackexchange narkive permalink

To naprawdę problem polityczny, a nie motywacyjny. Pracownikom posiadającym krytyczną wiedzę należy dać możliwość i udokumentować to, co powinno być obowiązkowe. Jeśli nie przedstawią obszernej dokumentacji, a ich przełożeni dali im wystarczająco dużo „wolnego” czasu na zrobienie tego, powinni zostać ukarani.

Bez względu na to, ile dana osoba wie lub może osiągnąć, jeśli jest jedyną osobą, która ma taką wiedzę, stanowi dla niej obciążenie. Dokumentacja nie powinna być opcjonalna.

Myślę, że „dyscyplina” jest [prawdopodobnie] złym podejściem - tak długo, jak pracownik (y) pozostają produktywni, karanie ich tylko zachęci ich do odejścia: co zniweczy cel. Zamiast negatywnego wzmocnienia, użyj pozytywnego wzmocnienia - pewnej formy zachęty / korzyści do dostarczenia dokumentacji.


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...