Як передавати справи під час звільнення
Я - керівник відділу розробки 1С. У моєму підпорядкуванні 4 розробники та 3 спеціалісти підтримки. Зірки склалися так, що я вирішив піти з компанії. Підписав заяву, домовився про два тижні відпрацювання. HR напружився, кинувся шукати заміну, але швидше за все за 2 тижні нікого вони знайти не зможуть і в мене постало питання, що потрібно зробити, щоб піти «красиво», так, щоб людина, яка замінить мене змогла якомога безболісно увійти в курс справ. Роздуми вилилися в такий список. 1. Створіть основу знань. Навіть якщо в компанії немає програми, в якій можна звести докупи всі знання, які зберігаються в головах твоїх розробників і найголовніше - у вашій - встановіть таку програму. Я вибрав Confluence, купив його за свої гроші (ліцензія на 10 користувачів коштує лише 600 рублів). Які дані необхідно помістити до бази знань:
• Список баз даних. Так, очевидно, що всі програмісти в компанії знають усі бази протилежно і це завдання здається марним, навіщо описувати те, що і так всі знають, проте ваш наступник швидше за все хоча б раз скаже вам спасибі прийшовши в перший день на «ваше» робоче місце і не проводячи зайвих розпитувань, отримає загальну картину про те, що є в компанії. Програмісти не люблять змін, зміна керівника для них стрес, новий начальник, який розпочав свою кар'єру в компанії з нескінченних питань «а це що за база? А хто власник? А який у неї бізнес-сенс?» викличе якщо не відторгнення, то як мінімум – приховане невдоволення.
• Список програм. Якщо в компанії використовується більше, ніж одна програма і немає однозначного зв'язку між ним і базою даних, то обов'язково має бути список – який додаток за що відповідає, хто в ньому працює, хто є бізнес-власником програми, якакритичність програми (можливий простий протягом 1 хвилини, протягом 1 години, протягом 1 дня тощо)
• Список ліцензій. Чомусь у невеликих компаніях ставлення до ліцензій досить халатне, головне – купити, а що буде далі, відділ розробки зовсім не цікавить. Я вважаю це порочною практикою, як правило, дані за ліцензіями (у кого куплені, коли, скільки коштували, на яку юридичну особу оформлені) потрібні в невідповідний момент, наприклад при оформленні підписки на ІТС (1С-ники мене зрозуміють) або не дай бог з появою людей масках. Програмісти люблять скидати це завдання на відділ системного адміністрування, адже закупівлею часто займаються саме сисадміни, а ті, у свою чергу, виконавши поставлене завдання (закупивши та встановивши ПЗ) вважають свою місію завершеною. Навіщо ускладнювати вашому наступнику і таке нелегке завдання?
• Схеми обміну між різними програмами. У невеликих компаніях обмін часто пишеться «на коліні», як то кажуть «…, …, і продакшн». До опису форматів, граничних умов навіть до частоти обміну справи не доходить. Проте великий стрес для нового керівника отримати о 9-й ранку дзвінок від фінансового директора «У нас тут не працює, а завжди працювало, розберись». Обміни - велика проблема в компанії з десятком різношерстних, іноді самописних систем. Описані схеми обміну допоможуть новій людині хоча б розпочати аналіз причини збою.
• Основні бізнес-процеси. Це банально. Це очевидно. Однак я не пам'ятаю, щоб у базі знань зберігалися найголовніші, що виробляються по 10 разів на день бізнес-процеси. Описуються процеси, що виконуються один раз на півроку, описуються процеси, що не виконуються ніколи. Але ті самі процеси, про які знають усі, надходження товару, розрахунок собівартості, встановлення цін – їхні. Навіщо описувати те, що знають і так? Повірте на слово, ваш наступник точно не скаже «навіщо він це зробив? Це ж і так усім зрозуміло!
2. Заведіть систему трекінгу завдань. Так-так, є компанії, де його немає. Так, таких компаній багато. Завдання надходять різними шляхами, поштою, дзвінком від безпосереднього керівника, від інших користувачів, програмісти самі вигадують собі завдання. Їх можна пам'ятати у своїй голові, в Excel-файлі, в Outlook. Я вважаю, що це неправильно, але моя думка може не співпадати з вашою. Але якщо ви вирішили залишити компанію – приведіть список завдань до ладу. Це нудно, але це необхідно. Я використовую Jira, але є велика кількість і безкоштовних рішень. Не обов'язково докладно описувати завдання, для нової людини в будь-якому випадку цього буде недостатньо, достатньо таких пунктів:
• Коротка назва завдання. • Замовник • Виконавець (якщо завданням вже хтось займається) • Пріоритет • Потрібен термін вирішення задачі
3. Підвищіть зарплату програмістам. Якщо у вашій компанії немає планового підвищення зарплати, наприклад, раз на рік – доклади всіх зусиль, щоб підняти зарплату розробникам до поточного ринкового рівня.