Сколько информации сохраняется во время сброса мозга [закрыто]

Никто не может сказать вам , чему вы можете научиться. Это гораздо больше зависит от вашего стиля обучения и опыта, чем от обстоятельств.

Обучение на практике намного эффективнее, чем обучение на слух. Таким образом, лучшее, что вы можете сделать, это заставить новых людей попытаться поработать над этим, пока старый человек все еще там, чтобы ответить на их вопросы.

Второе лучшее, что вы можете сделать, это делать заметки и снимать на видео любой «сброс», чтобы вы могли вернуться к нему позже.

Конечно, оглядываясь назад, фирма должна была потратить время на то, чтобы иметь достаточно внутренней документации, чтобы избежать этой проблемы в первую очередь.

Так вы пытаетесь получить дамп мозгов от кого-то, кто месяц назад получил дамп мозгов от реальной команды?

На протяжении многих лет я руководил командами, которые занимались рядом проектов/систем. Исходя из опыта, я бы предположил, что человек посередине сохранит только те вещи, с которыми ему приходилось иметь дело напрямую (например, любые производственные проблемы, изменения / новая работа и т. д.). Что касается всего остального, я бы сказал, что если это не было задокументировано первоначальными разработчиками, лучше считать это потерянными знаниями.

Я бы попросил посредника начать обрисовывать и документировать все, что он может, и искать любые большие пробелы, как только вы можете, прежде чем они уйдут.

Это одна из причин, почему важна полная и актуальная документация по каждому аспекту проекта. Если процесс документирования становится частью жизненного цикла проекта, а не очередной рутиной, количество информации, потерянной при подобном переходе, сводится к минимуму. Многие компании рассматривают эту документацию как трату времени, которая стоит денег, а члены команды рассматривают ее как дополнительную задачу, на которую часто никогда не смотрят. По этой причине документация проекта часто сводится к тому, что требуется для завершения проекта. Но это ошибка.

Акт документирования дает время подумать и выявить сбои до того, как работа будет начата, а исправление обойдется дороже. А с хорошей документацией гораздо проще привлечь нового члена команды для расширения или замены существующего персонала. Каждый раз, когда кто-то уходит, происходит потеря знаний о проекте. Но чем лучше проект был задокументирован, тем меньше этих знаний было полностью потеряно, и тем больше их можно было легко передать и с большей вероятностью сохранить новые сотрудники.

Проделав это несколько раз (как при передаче, так и при получении), я могу сказать, что для того, чтобы сделать это гладко, требуется некоторое планирование, а также такт.

Как указал ReallyTired, полностью задокументированные процессы и системы жизненно важны, но это то, что необходимо делать постоянно на протяжении всего жизненного цикла проектов. Торопиться в двухнедельный отъезд - пустая трата времени и слишком поздно. Более того, оставшиеся 2 недели гораздо лучше потратить на общение с уходящим человеком, чем на то, чтобы он безостановочно писал документы в своем кубе.

Я нашел несколько эффективных вещей:

• Назначьте кого-то, кто будет «следить» за уходящим человеком. Попросите их научить выполнять основные повседневные задачи способного и целеустремленного человека, который будет задавать хорошие вопросы и не откажется практиковаться даже в самых простых вещах, просто чтобы прочувствовать их.

• Если работа требует некоторых относительно простых повторяющихся задач, попросите человека, который уходит, запечатлеть эти задачи в скринкастах. Рассказываемый скринкаст может передать гораздо больше нюансов, связанных с усилиями, чем словесный документ об основных рабочих вещах.

• Признайте, что не все будет передано. Если отъезд и трансфер не запланированы заранее на несколько месяцев, это просто невозможно. Вы должны провести сортировку. Сосредоточьтесь на небольшом количестве ключевых навыков, которые нужно передать действительно хорошо, а не на том, чтобы охватить как можно больше.