В одно компании проходил через такое заблуждение: Группа инженеров накапливала знания, благодаря опыту и стараниям(командировки, соглашения и контракты с партнерами и т.д.) компании. Знания не систематизировались и не были доступны другим инженерам, монтажникам и прочим работникам. Это влекло к тому, что целое направление не развивалось, были увеличены многократно сроки запусков и тестирования систем, отлаживание систем могло происходить только с привлечением зарубежных специалистов, невозможен онбординг новых специалистов. В целом, казалось, что направление очень «сложное», «специфичное» и «закрытое». Если специалисты пропадут/уйдут, то целое направление компании просто перестанет существовать, потому можно выкручивать руки собственнику компании. В такой парадигме невозможно развивать направление, программную и аппаратную часть.
Такой процесс и произошел через время и мне с одним новым сотрудником пришлось по крупицам информации принимать направление на себя. Я решил пойти другим путем:
Вся документация была собрана в несколько направлений и скрупулезно переписана по госту (по структуре и оформлению) со скриншотами каждого действия;
Вся документация была выдана всем кому она была или могла быть нужна.
Чего добились: Затратив время вначале, разгрузились в конце: сотрудники компании больше не дергали с простыми вопросами, составленная документация превратилась в руководства по эксплуатации, руководства пользователя, документацию для производственного отдела, для заказчика и эксплуатации;
Выявили слабые места: Абсолютно слабых инженеров, которые прикрывались ранее отсутствием документации, отсутствие процесса тестирования и нормальной наладки, а главное - отсутствие доступного тестового стенда, увеличенные сроки запуска и наладки, а значит и командировок на места, непонимание внутренних процессов в системе, невозможность проводить семинары для заказчика и предлагать адекватную техническую поддержку, почти НИКТО НЕ ЧИТАЕТ ДОКУМЕНТАЦИЮ!;
Создали доступный тестовый и наладочный стенд, он же был классом для проведения семинаров - не смотря на наличие документации у заказчика (и наличие спокойствия у него что можно открыть книжицу), начали проводить семинары (экспериментировать на промышленном продакшене никто не хотел), предложили бизнесу несколько вариантов реализации аппаратной части оборудования в соответствии с требованиями существующих и возможных заказчиков, сократили многократно время командировок, запуская системы не по пол года, а за неделю(две с оформлением бумаг), эмулировали нестандартные ситуации для проверки слабых мест, разночтений от разработчиков для адекватных ответов заказчику, готовили готовые конфигурации для запуска систем на местах с инструкциями для младшего инженерного состава, разгрузив себя и позволив им более плотно погружаться в процесс.
В общем, ценность наша была в действии а не в бездействии. А опыт каждый унес с собой - он никуда не делся. Все получили только развитие.
Преимуществ передачи много: - В процессе передачи знаний сотрудник сам может лучше структурировать информацию и глубже понять материал - Обмен знаниями помогает создать культуру обучения и сотрудничества в команде - Передача знаний часто рассматривается как вклад в коллективный успех команды. Это может повысить репутацию сотрудника среди коллег и руководства, открывая возможности для карьерного роста - Если знания работника помогают оптимизировать рабочие процессы или улучшить продуктивность всей команды, это может привести к повышению эффективности работы компании в целом, что также выгодно сотруднику
А какой профит работнику отдавать свои полученные знания компании? Тогда его ценность, как эксперта, существенно ниже
В одно компании проходил через такое заблуждение: Группа инженеров накапливала знания, благодаря опыту и стараниям(командировки, соглашения и контракты с партнерами и т.д.) компании. Знания не систематизировались и не были доступны другим инженерам, монтажникам и прочим работникам.
Это влекло к тому, что целое направление не развивалось, были увеличены многократно сроки запусков и тестирования систем, отлаживание систем могло происходить только с привлечением зарубежных специалистов, невозможен онбординг новых специалистов. В целом, казалось, что направление очень «сложное», «специфичное» и «закрытое». Если специалисты пропадут/уйдут, то целое направление компании просто перестанет существовать, потому можно выкручивать руки собственнику компании. В такой парадигме невозможно развивать направление, программную и аппаратную часть.
Такой процесс и произошел через время и мне с одним новым сотрудником пришлось по крупицам информации принимать направление на себя. Я решил пойти другим путем:
Вся документация была собрана в несколько направлений и скрупулезно переписана по госту (по структуре и оформлению) со скриншотами каждого действия;
Вся документация была выдана всем кому она была или могла быть нужна.
Чего добились:
Затратив время вначале, разгрузились в конце: сотрудники компании больше не дергали с простыми вопросами, составленная документация превратилась в руководства по эксплуатации, руководства пользователя, документацию для производственного отдела, для заказчика и эксплуатации;
Выявили слабые места:
Абсолютно слабых инженеров, которые прикрывались ранее отсутствием документации, отсутствие процесса тестирования и нормальной наладки, а главное - отсутствие доступного тестового стенда, увеличенные сроки запуска и наладки, а значит и командировок на места, непонимание внутренних процессов в системе, невозможность проводить семинары для заказчика и предлагать адекватную техническую поддержку, почти НИКТО НЕ ЧИТАЕТ ДОКУМЕНТАЦИЮ!;
Создали доступный тестовый и наладочный стенд, он же был классом для проведения семинаров - не смотря на наличие документации у заказчика (и наличие спокойствия у него что можно открыть книжицу), начали проводить семинары (экспериментировать на промышленном продакшене никто не хотел), предложили бизнесу несколько вариантов реализации аппаратной части оборудования в соответствии с требованиями существующих и возможных заказчиков, сократили многократно время командировок, запуская системы не по пол года, а за неделю(две с оформлением бумаг), эмулировали нестандартные ситуации для проверки слабых мест, разночтений от разработчиков для адекватных ответов заказчику, готовили готовые конфигурации для запуска систем на местах с инструкциями для младшего инженерного состава, разгрузив себя и позволив им более плотно погружаться в процесс.
В общем, ценность наша была в действии а не в бездействии. А опыт каждый унес с собой - он никуда не делся. Все получили только развитие.
и наоборот, как защититься от того, чтобы уходящий специалист при увольнении не унес уникальные знания крутых экспертов?
Преимуществ передачи много:
- В процессе передачи знаний сотрудник сам может лучше структурировать информацию и глубже понять материал
- Обмен знаниями помогает создать культуру обучения и сотрудничества в команде
- Передача знаний часто рассматривается как вклад в коллективный успех команды. Это может повысить репутацию сотрудника среди коллег и руководства, открывая возможности для карьерного роста
- Если знания работника помогают оптимизировать рабочие процессы или улучшить продуктивность всей команды, это может привести к повышению эффективности работы компании в целом, что также выгодно сотруднику
Работодатели таких любят, вот и думаю, что все должны быть такими