Кращий спосіб навчання нових наймань [закрито]

Команда, в якій я зараз є частиною досвіду досить високого обороту, учасники зазвичай переходять до різних проектів в одній компанії. В даний час наше "навчання" для нових членів полягає в поєднанні їх з основним контактом (як правило, найсвіжіша людина, яка завершить навчання), яка надасть їм практичний досвід і попросить більше старших розробників, якщо нові наймачі запитають щось у наставника не знає. Це дає шанс новому найманому працеві швидко долучитися до роботи та викличе наставнику також покращити його розуміння системи.

Однак, як ви можете собі уявити, такий стиль навчання дуже трудомісткий і не забезпечує дуже хорошого перенесення знань (помилкові уявлення поширюються, розриви розширюються).

Мені доручено створити документацію та навчальні матеріали для наших нових майбутніх найм. Я вже займаюся технічним написанням періодично, але це для кінцевого користувача і є дуже специфічним з великою кількістю скріншотів і вимагає великої кількості часу для його завершення.

Створення нової документації для нових наймань вважається низьким пріоритетом, і я працюю над цим лише 40 годин. Документування системи поточним способом, як я пишу технічну документацію, ледь не подряпає поверхню за 40 годин. Особливо враховуючи, що мені доведеться документувати не лише про базу коду, але й про розгортання та підтримку.

Як я можу швидко написати документацію, щоб якнайшвидше оновлювати нові роботи, не вкладаючи значних витрат часу на написання документації?

Додаткова інформація: На
даний момент у нас є і вікі, і деяка навчальна документація, однак обидві є рідкісними.

Хороше питання. Навчання на програмістів на роботі дуже рідко сприймається серйозно, і про нього не говорять часто.

Деякі ідеї, які я бачив, добре працюють:

• У своїй вікі маєте новий прокатний пакет (той, який ви пишете). У цьому документі опишіть завдання, які новий прокат буде виконувати протягом перших 1-2 тижнів. Там, де я працюю, є багато знань, починаючи від роботи, від внутрішнього програмного забезпечення / інструментів, до процесів, до локацій певних типів інформації. редагувати> у нас є такі інструкції, як "встановити x, y, z по порядку" із скріншотами для конфігурації тощо. Отже, налаштування системи або ферми (віртуальних машин) за допомогою Win Server, SQL Server, SharePoint, BizTalk, наше програмне забезпечення не так просто, як це звуки. Це стосується інших версій тих програм, які ми підтримуємо.
• Практикуйте проблеми. Де я є, у нас є продукт, який розкриває API з великими результатами. Тому нам завжди вигідно пройти власну документацію на продукцію для написання (заздалегідь визначених) розширень так, як це роблять наші клієнти / клієнти. Отже, якщо у вас була бібліотека з математики як частина API вашого продукту, виникла проблема з практикою: "написати калькулятор за допомогою нашого API" або щось подібне.
• Наставники хороші. Зберігайте їх. Ми робимо це і тут, і це не тільки хороший спосіб зустріти людей / подружитися, але вони є неоціненним джерелом навчання. Я рекомендую не закінчувати навчання останнім часом, оскільки у них немає історії корпоративних знань, яку може зробити хтось інший. Нехай усі роблять це на ротації.
• Ми проводимо (приблизно) щотижневі презентації / технічні бесіди. Нехай нові наймачі виберуть щось із вашого товару (або призначте його) та проведіть презентацію після їх 3-го тижня. Переконайтеся, що вони знають, що в них є можливість помилятися, і команда може виправити їх, якщо вони щось підкажуть у презентації.
• Попросіть нових наймачів працювати над документацією при їх запуску. Це змушує їх читати.

Як зазначає Ден МакГрат, корисно заохочувати нових наймачів для покращення вікі для них.

По-перше, я б запропонував, що вам не доведеться робити свій новий навчальний документ з наймання так ретельно, як щось, що ви написали б для клієнта. Він повинен бути достатньо технічним, щоб новий розробник міг використовувати його як путівник, але не настільки детальний, щоб він окреслював кожну дрібницю. Вони зможуть поговорити з командою, якщо у них все-таки виникнуть запитання.

Які 10 найкращих речей, які повинен знати новий прокат, щоб бути корисним вашій команді? Концентруйтеся на цих речах. Створіть їх своїм списком хітів, щоб новому розробнику вистачило зробити і достатньо інформації, щоб продовжувати їх працювати. Якщо у вас занадто багато речей у списку, запитайте себе, чи будуть вони це робити протягом перших двох-трьох тижнів. Якщо в цей час вони щось не роблять, можливо, це не повинно бути в посібнику з посадки.

У кожному розділі вашого путівника переконайтеся, що вгорі вгорі виділена особа, яка переходить до людини. Таким чином, якщо у нового найманого питання є якісь питання, вони знають, до кого звернутися за допомогою. Крім того, переконайтеся, що один член команди не є людиною, яка переходить на занадто багато розділів. Ви не хочете забирати час однієї людини новими питаннями про наймання, якщо вони не є наставником.

Не витрачайте цілий тиждень на цей документ. Залиште собі час, щоб відрегулювати його після того, як ви дозволите хоча б один новий прокат пройти його. Подивіться, що добре працює, а що ні, і виправте.

Нещодавно я почав працювати над аналогічним документом за місцем роботи, з подібними часовими обмеженнями. Я співчуваю, що легко хотіти писати це на дуже детальному рівні, як це робилося спочатку, але це може бути насправді контрпродуктивним.

Якщо хтось новий починає свою роль, вони, ймовірно, затоплені інформацією протягом перших кількох тижнів. Після того, як їх початкова підготовка буде мозковим демпфером розробника, який вже кілька років працює в компанії, на мій погляд, набагато складніше буде те, що хтось повинен знати протягом своїх перших кількох місяців або навіть року на цій посаді. Тримайте це на високому рівні, намагайтеся використовувати стандартний жаргон та концепції, а потім розширюйте їх на основі специфіки процесів компанії.

Для мене перша ітерація цього документу - це лише контур SDLC, який ми використовуємо за місцем роботи, зі списком ролей, пов’язаних у кожному кроці, кількома прикладами людей, які виконують ці ролі, та конкретними контрольними списками, пов’язаними з кожен крок життєвого циклу. Я особисто вважаю контрольні списки незамінними в навчальних цілях, але також майже в усьому, чим я займаюся на роботі. Наприклад:

• Керівник проекту (Джо) призначає вам завдання в Джирі.
• Встановіть орієнтовний час виконання завдання на основі формули x.
• Встановіть квиток як "незавершений", коли ви почнете роботу над ним.
• Створіть гілку з git, натисніть посилання, щоб переглянути 30 секундне відео про цей прогрес.
• Запишіть одиничні тести на основі обмежень у проектному документі, див. На сторінці y для умовних позначень умовних імен.
• Встановіть квиток на огляд та подайте код до системи огляду .. 'тощо.

Ваш новий працівник, сподіваємось, повинен бути знайомий з більшістю концепцій, а тепер мати покрокове керівництво, як процеси застосовуються в компанії. Я також швидко демонструю процес від початку до кінця, використовуючи реальні документи з проектів, які, на мою думку, були добре виконані.

Як уже згадувалося, його також є живим документом, тому розділи можна розширити, оскільки буде виявлено, що їм потрібна додаткова інформація. Весь колектив повинен брати участь у його оновленні. Це може бути вікі, документ OneNote, що завгодно, але щось, що всі люди можуть редагувати та переглядати, а потім починати залучати інших людей до вдосконалення його, коли у них тут і там є вільна година. Таким чином, одна людина не робить цього і поширює свою власну спіну на цьому процесі для всіх нових наймань.

Після того, як вони переглянули процес, запропонуйте їм ознайомитись з невеликою функцією / виправленням помилок у проекті, що не належить до критичної місії, і запропонуйте їм задати питання, які документ не стосується. Запишіть, що це за запитання, адже вони, ймовірно, повинні бути першими, що ви додасте до документа наступного разу, коли ви будете над ним працювати.

Ви не можете поєднати щось подібне, не витрачаючи часу. Принаймні, якщо ви хочете зробити це самостійно. Ви повинні запитати себе, чи дійсно потрібно документувати це так точно, як ви намагаєтесь?

Єдиною альтернативою було б дозволити новим наймантам робити основну роботу. Нехай вони напишуть деякі частини. Час, який ви витратите на їх виправлення (у формі зворотного зв'язку), буде меншим, ніж у ваших поточних ситуаціях. Надайте кілька хороших шаблонів, і вам не доведеться турбуватися про розкладку.

Я вважаю, ви вже знаєте, що вони поставили перед вами завдання неможливою. Як письменник ви, напевно, вже знайомі з цитатою Марка Твена:

Якби у мене було більше часу, я б писав менше.

Враховуючи фактично відсутні ресурси, мабуть, найкраще, що ви можете зробити, - це отримати файловий кабінет і попросити всіх зробити копію того, що вони вже є, і поставити копію у файловий кабінет. Таким чином, ви можете принаймні сказати новому прокату: "Якщо ви хочете знайти щось про систему, то місце для початку - у шафі файлів".

Гарне написання вимагає часу, періоду. Далі його потрібно адаптувати до цільової аудиторії. Що працює для кінцевих користувачів, це не те, що потрібно програмісту.

Не кажучи вже про те, що хороша підготовка не обмежується письмовими матеріалами, вона передбачає повний гамбіт освітніх ресурсів, включаючи он-лайн, аудиторію, мультимедіа тощо.

Як кажуть, "Якщо ви вважаєте, що освіта дорога, спробуйте вартість незнання".

Далі, само собою зрозуміло, що розгляд документації як щось, що потрібно зробити після факту, а не зробити його невід'ємною частиною процесу з першого дня є свідченням системної організаційної проблеми.