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