Просечната ИТ компанија има барања, историја на тракери на задачи, извори (можеби дури и со коментари во кодот), инструкции за типични, важни и сложени случаи во производството, опис на деловните процеси (од влез во авион до „како да се оди на одмор ”), контакти, клучеви за пристап, списоци на луѓе и проекти, описи на области на одговорност - и куп други знаења на кои веројатно заборавивме и кои можат да се складираат на најневеројатните места.
Знаење =/= документација. Ова не може да се објасни, мора да се запомни
Како да бидете сигурни дека оние кои треба да знаат нешто од ова да разберат каде и како да го најдат, а секој што треба да биде свесен за поединечни работи и договори може веднаш и точно да дознае за промените во нив.
Во последната епизода од подкастот „Team Lead Will Call“, момците од Skyeng разговараа за управување со знаење со Игор Цупко е лице во програмскиот комитет KnowledgeConf и „директор на непознатото“ во Флант.
Целосната снимка е достапна како , а подолу собравме неколку интересни совети и линкови до корисни материјали кои беа споменати во аудиото или проширете ги информациите од него. Би било одлично ако ги споделите и хаковите и триковите на вашиот тим во коментарите.
Прво хакирање: повеќе не треба да знаете во кој систем да погледнете
„Ги зедов нашите извори на знаење и направив општо пребарување за нив: единствен прозорец со систем за филтрирање за да се намали областа за пребарување. Да, во исто време, сè уште треба да го следите неговиот квалитет, да ја надополнувате базата на знаење и да се борите против дуплирањето и погрешните информации.
Едно парче хартија за да се најде тоа е сè
Но, веќе, околу 60% од инженерите на Flant го користат ова пребарување најмалку 1-2 пати на ден - и обично наоѓаат одговори на првата или втората позиција. И во форма на доказ за концепт е индексирањето на документите на Google: сите докси, папки, комби-погони и така натаму - сето тоа исто така лесно се внесува во внатрешното пребарување“.
Второ хакирање: како да не пропуштите критично важни работи во еден куп разговори
„Ако работите во дистрибуиран тим, тогаш веројатно поминувате значителен дел од вашиот ден во Slack - и ако нешто се случи, сте навикнати да правите нешто вакво: „@myteam, помогнете/погледнете/внесете го вистинскиот.. .” Но, има проблем со изобилството на информации - и може да се пропушти посебно спомнување меѓу другите пораки.
Во Skyeng ни помага бот преку кој можете да напишете порака и да означите кој било број луѓе или групи. Го користиме во случаи кога е навистина важно луѓето да читаат или да реагираат: ќе ѕирка бескрајно додека не го притиснете копчето „Читам“ - нема да можете да го прескокнете или игнорирате“.
Прашање за одговор: што да се прави со документацијата?
„Многу знаење доаѓа од техничари, но не секој знае добро да го опише.
На крајот на краиштата, немате компајлер или линтер што ќе ви каже дали го правите тоа правилно или не - и честопати излезот што го имаме е неразбирлив, слабо форматиран и нецелосен текст. Се разбира, треба да го правите тоа нормално, не затоа што некој дојде и рече „потребно е“ - добро го правите тоа за себе: за месец или два ќе го прочитате и разберете. И друго лице, отворајќи документ, нема веднаш да го затвори засекогаш, сфаќајќи дека е бескорисен.
Дел од подкастот посветен на прашањето „Колку луѓе се потребни за да се напише добра документација или да се направи нормално демо“
Но, останува прашањето: колку време да се одвои за ова и како да се направи ефикасно?
И ако овде има искрен одговор: освен ако не се вклучени деловни луѓе и доколку емпириски не го искусат влијанието на добрата документација, постои ризик дека напорите ќе донесат мал поврат. Ова е повеќе приказна за промена на културата.
За останатото, искуството и менторството ќе ве спасат. Овде може да се погодни аналози на програмирање во пар, следење на напредокот и прегледи на кодови - прикажување на најдобри практики, навлегување во грешки и досадно на крајот“.
Бонус: „Во ред, ќе им кажам вака, тие ќе разберат“
Прашањето „колку време да се потроши на ова и на кое ниво да се направи“ е важно не само во рамките на документацијата, туку воопшто за пренос на какво било знаење. Демото е исто така одличен пример за споделување информации. Но, постојат нијанси: на пример, како да се осигурате дека заземаат минимално време.
Канал за споделување знаење меѓу развојот: внатрешни извештаи, корисни книги, статии итн. Структурираниот екстракт е зачуван и во Notion.
Делумно, овие проблеми можат да се решат со практикување на внатрешни извештаи. Еднаш неделно се земаат 40-60 минути во помалку зафатено време - а момците прават видео-извештај за колегите од различни проекти. Frontend тим на клучниот производ - Vimbox - за вашиот комплет за кориснички интерфејс, кој може да биде тематски за кој било друг проект. Тимот за развој на маркетинг зборуваше за библиотека за барања за следење и евидентирање, што веднаш го привлече интересот на неколку други проекти. Проектниот тим Математика го сподели своето искуство за префрлување од REST API на GraphQL. Тимот за групни часови размислува да сподели како тие први се префрлија на PHP 7.4. И така натаму.
Списокот се одржува од мај 2018 година и има над 120 записи
Сите состаноци се започнуваат преку корпоративниот Google Meet, се снимаат и во рок од 1.5 часа се појавуваат во папка на споделен Google Drive, а линковите до снимките се дуплираат во истиот Slack. Односно, не мора да доаѓате ако има итен случај, но гледајте го подоцна со 20 брзина - обично самиот извештај трае до XNUMX минути, а дискусијата - како излегува. Но, ние не одиме подалеку од час)
PS Што работеше, а што не работеше за вас?
Корисни врски:
- Родион Нагорнов од Kaspersky Lab за и зошто ова не е документација (благодарност до каналот на Игор за врската , има уште многу такви).
- За тоа Игор Цупко од Флан во мое друштво
- Алексеј Катаев од Скајенг (јазот во знаењето во технологиите и специфичните области) во дистрибуиран тим.
- Сергеј Гончарук од Флант за пренесување информации - , ако наидете на проблем во дистрибуиран тим.
Извор: www.habr.com
