როგორ გავაუმჯობესოთ ცოდნის გაზიარება კომპანიაში ისე, რომ ეს დიდად არ დააზარალებს

საშუალო IT კომპანიას აქვს მოთხოვნები, დავალებების ტრეკერების ისტორია, საწყისი კოდები (შესაძლოა კოდში კომენტარებითაც კი), ინსტრუქციები წარმოების ტიპიური, მნიშვნელოვანი და რთული შემთხვევებისთვის, ბიზნეს პროცესების აღწერა (ონბორდინგიდან „როგორ წავიდეთ შვებულებაში“), კონტაქტები, წვდომის გასაღებები, ადამიანებისა და პროექტების სიები, პასუხისმგებლობის სფეროების აღწერა - და სხვა ცოდნის ერთობლიობა, რომელიც ალბათ დაგვავიწყდა და რომლის შენახვაც ყველაზე მოულოდნელ ადგილებშია შესაძლებელი.

ცოდნა =/= დოკუმენტაცია. მისი ახსნა შეუძლებელია, ის უნდა დაიმახსოვროთ.

როგორ გავაკეთოთ ისე, რომ მათ, ვისაც ამ საკითხიდან რაიმეს ცოდნა სჭირდებათ, გაიგონ, სად და როგორ იპოვონ ის და ყველამ, ვისაც ინდივიდუალური საკითხებისა და შეთანხმებების შესახებ ცოდნა სჭირდება, მყისიერად და ზუსტად გაიგოს მათში ცვლილებების შესახებ.

პოდკასტის „Teamlead Will Call“-ის ბოლო ეპიზოდში, Skyeng-ის ბიჭებმა იგორთან ერთად ცოდნის მართვაზე ისაუბრეს. მაი-კეტი ცუპკო KnowledgeConf-ის პროგრამის კომიტეტის წევრი და ფლანტში „უცნობის დირექტორია“.

სრული ჩანაწერი ხელმისაწვდომია როგორც YouTube ვიდეო, და ქვემოთ ჩვენ შევკრიბეთ რამდენიმე საინტერესო რჩევა და ბმული სასარგებლო მასალებზე, რომლებიც ნახსენები იყო აუდიოში ან აფართოებს მასში არსებულ ინფორმაციას. კარგი იქნება, თუ კომენტარებში თქვენი გუნდის ჰაკებსა და ხრიკებსაც გაგვიზიარებთ.

ჰაკი 1: აღარ გჭირდებათ იცოდეთ, რომელ სისტემაში მოძებნოთ

„მე ავიღე ჩვენი ცოდნის წყაროები და ჩავატარე მათი ზოგადი ძიება: ერთი ფანჯარა ფილტრაციის სისტემით, რათა შემცირებულიყო ძიების არეალი. დიახ, ამავდროულად, თქვენ მაინც გჭირდებათ მისი ხარისხის მონიტორინგი, ცოდნის ბაზების შევსება, დუბლირებისა და არასწორი ინფორმაციის წინააღმდეგ ბრძოლა.“

ერთი კლიპი ამ ყველაფრის საპოვნელად

თუმცა, უკვე Flant-ის ინჟინრების დაახლოებით 60% იყენებს ამ ძიებას დღეში სულ მცირე 1-2-ჯერ - და, როგორც წესი, პასუხებს პირველ ან მეორე პოზიციაზე პოულობს. კონცეფციის დასამტკიცებლად კი არსებობს Google-ის დოკუმენტების ინდექსირება: ყველა დოკუმენტი, საქაღალდე, ერთი დისკი და ა.შ. - ეს ყველაფერი ასევე ადვილად შედის შიდა ძიებაში.

ჰაკი 2: როგორ არ გამოგრჩეთ კრიტიკული ინფორმაცია ჩატების სიმრავლეში

„თუ განაწილებულ გუნდში მუშაობთ, მაშინ, სავარაუდოდ, დღის მნიშვნელოვან ნაწილს Slack-ში ატარებთ - და როდესაც რაღაც ხდება, მიჩვეული ხართ ასეთი რამის გაკეთებას: „@myteam, დახმარება/შეხედვა/შეყვანა საჭირო...“. თუმცა, პრობლემა ინფორმაციის სიუხვესთან დაკავშირებით არსებობს - და სხვა შეტყობინებებს შორის ცალკე ხსენება შეიძლება გამოგრჩეთ.“

Skyeng-ში ჩვენ გვყავს ბოტი, რომელიც საშუალებას გაძლევთ დაწეროთ შეტყობინება და მონიშნოთ ნებისმიერი რაოდენობის ადამიანი ან ჯგუფი. ჩვენ მას ვიყენებთ იმ შემთხვევებში, როდესაც ადამიანებისთვის წაკითხვა ან რეაგირება ნამდვილად მნიშვნელოვანია: ის დაუსრულებლად გამოჩნდება მანამ, სანამ არ დააჭერთ ღილაკს „წავიკითხე“ — თქვენ არ შეგიძლიათ მისი გამოტოვება ან იგნორირება.

რთული კითხვა: რა უნდა გავაკეთოთ დოკუმენტაციასთან?

„ბევრი ცოდნა ტექნიკოსებისგან მოდის, მაგრამ ყველას არ შეუძლია მისი კარგად აღწერა.“
ბოლოს და ბოლოს, თქვენ არ გაქვთ არც კომპილატორი და არც ლინტერი, რომელიც გეტყვით, სწორად აკეთებთ თუ არა ამას - და ხშირად გამომავალი ტექსტი გაუგებარი, ცუდად ფორმატირებული და არასრული ტექსტია. რა თქმა უნდა, ეს სწორად არ უნდა გააკეთოთ იმიტომ, რომ ვიღაც მოვიდა და თქვა „აუცილებელია“ - თქვენ თვითონ კარგად აკეთებთ ამას: ერთ ან ორ თვეში წაიკითხავთ და გაიგებთ. და სხვა ადამიანი, დოკუმენტის გახსნისას, მაშინვე არ დახურავს მას სამუდამოდ, იმის გაცნობიერებით, რომ ის უსარგებლოა.

პოდკასტის ნაწილი, რომელიც ეძღვნება კითხვას „რამდენი ადამიანია საჭირო კარგი დოკუმენტაციის დასაწერად ან კარგი დემო ვერსიის შესაქმნელად“

მაგრამ კითხვა კვლავ რჩება: რამდენი დრო უნდა გამოიყოს ამისთვის და როგორ შეიძლება ამის ეფექტურად გაკეთება?
და თუ ამ კითხვაზე გულწრფელი პასუხი არსებობს, თუ ბიზნესმენები არ იქნებიან ჩართულნი და თუ ისინი ემპირიულად არ იგრძნობენ კარგი დოკუმენტაციის სარგებელს, არსებობს რისკი, რომ ძალისხმევა მცირე სარგებელს მოიტანს. ეს უფრო კულტურის შეცვლის ისტორიაა.

სხვა შემთხვევაში, გამოცდილება და მენტორობა გიშველით. აქ შეიძლება შესაფერისი იყოს წყვილებში პროგრამირების, პროგრესის თვალყურის დევნებისა და კოდის მიმოხილვის ანალოგები - საუკეთესო პრაქტიკის ჩვენება, შეცდომების გამოკვეთა და, საბოლოო ჯამში, მოსაწყენი.“

ბონუსი: „აჰ, მოდი, ასე ვეტყვი მათ და გაიგებენ“.

კითხვა „რამდენი დრო დავხარჯოთ ამაზე და რა დონეზე გავაკეთოთ“ მნიშვნელოვანია არა მხოლოდ დოკუმენტაციის ფარგლებში, არამედ ზოგადად ნებისმიერი ცოდნის გადაცემისთვის. დემო ვერსიები ასევე ინფორმაციის გაცვლის შესანიშნავი მაგალითია. თუმცა, არსებობს ნიუანსები: მაგალითად, როგორ გავაკეთოთ ეს მინიმალური დროის დაკავებით.

ცოდნის გაზიარების არხი განვითარების გუნდს შორის: შიდა ანგარიშები, სასარგებლო წიგნები, სტატიები და ა.შ. სტრუქტურირებული შეჯამება ასევე ინახება Notion-ში.

ეს პრობლემები ნაწილობრივ მოგვარებულია შიდა ანგარიშების პრაქტიკით. კვირაში ერთხელ, არც თუ ისე დატვირთულ დროს, 40-60 წუთი ეთმობა - და ბიჭები სხვადასხვა პროექტების კოლეგებისთვის ვიდეო ანგარიშს ამზადებენ. ძირითადი პროდუქტის - Vimbox-ის - ფრონტენდ გუნდი განუცხადა მათი UI ნაკრების შესახებ, რომლის თემაც შეიძლება იყოს ნებისმიერი სხვა პროექტისთვის. მარკეტინგის განვითარების გუნდი - მოთხოვნების თვალყურის დევნებისა და ჟურნალირების ბიბლიოთეკის შესახებ, რომელმაც მაშინვე რამდენიმე სხვა პროექტი დააინტერესა. პროექტ „მათემატიკის“ გუნდმა გააზიარა REST API-დან GraphQL-ზე გადასვლის გამოცდილება. ჯგუფური გაკვეთილების გუნდი ფიქრობს მოყვეს, თუ როგორ გადავიდნენ ისინი პირველები PHP 7.4-ზე. და ა.შ.

სია 2018 წლის მაისიდან შედგენილია და 120-ზე მეტ ჩანაწერს შეიცავს.

ყველა შეხვედრა იწყება კორპორატიული Google Meet-ის საშუალებით, იწერება და 1.5 საათის განმავლობაში ინახება საერთო Google Drive-ის საქაღალდეში, ხოლო ჩანაწერებზე ბმულები დუბლირებულია იმავე Slack-ში. ანუ, თუ გეჩქარებათ, არ გჭირდებათ მოსვლა და შემდეგ მისი ყურება 20 სიჩქარით - როგორც წესი, თავად პრეზენტაცია XNUMX წუთამდე გრძელდება, ხოლო დისკუსია - როგორც ირკვევა. თუმცა, ჩვენ ერთ საათზე მეტს არ ვაგრძელებთ)

PS რა გამოგივიდათ და რა არა?

სასარგებლო ბმულები:

• როდიონ ნაგორნოვი Kaspersky Lab-დან საუბრობს რა არის ცოდნის მენეჯმენტი და რატომ არ არის ეს დოკუმენტაცია (მადლობა იგორის არხის ბმულისთვის) „მყუდრო IT დარბაზი“, კიდევ ბევრი ასეთი რამ არსებობს).

• იგორ ცუპკო ფლანტიდან დაახლოებით როგორ განვახორციელოთ ცოდნის მენეჯმენტი ჩემს კომპანიაში

• ალექსეი კატაევი Skyeng-დან იმის შესახებ, თუ როგორ უნდა აკონტროლოთ და გაათანაბროთ ბასის ფაქტორი (ცოდნის ხარვეზები ტექნოლოგიებსა და კონკრეტულ სფეროებში) განაწილებულ გუნდში.

• სერგეი გონჩარუკი ფლანტიდან ინფორმაციის მიწოდებაზე — როგორ გავიგოთ, როდის და ვის ვკითხოთ, თუ განაწილებულ გუნდში პრობლემას წააწყდებით.

წყარო: www.habr.com