- Главная
- Регламенты по замене специалиста на проекте
Регламенты по замене специалиста на проекте
Когда слаженная команда долгое время работает над проектом и появляется необходимость заменить специалиста, то успех замены будет зависеть от правильно организованной работы на проекте. И если допустить ошибки, то команда испытает серьезные трудности адаптации.
2. Отпуск или болезнь
3. Вынужденный перевод на другой проект (перегорел)
Команда должна быть всегда готова к тому, что она может потерять какого-то из членов команды. Важнее всего обеспечить безболезненное решение данной проблемы. Для этого необходимо выполнять следующие инструкции.
1. Ведите документ small-review
В котором будет описан сам проект и основные изменения в нем. Сильно детализировать этапы проекта не нужно, так как основные задачи по проекту храняться в таск-трекере. Надо вести такой документ, чтобы любой специалист взяв его в руки и прочитав, смог получить максимум информации о нем за минимально короткое время. Этапы проекта описывайте со статусами, которые будут говорить о той команде или группе специалистов, которые занимались этим. Например этап с тестированием необходимо отметить, что он связан с тестированием, а этап с крупным внедрением back-части, должен относится к back-end.
2. Должностные инструкции и правила на проекте
Помимо должностных инструкций и корпоративных стандартов, на проекте могут быть использованы определенные командой правила по написанию кода, тестированию, взаимодействию с репозиториями и т.п. Эти правила, регламенты и инструкции надо обязательно вести и иметь возможность оперативно их предоставить.
Также очень важно следить за актуальностью этих правил, так как в начале проекта вся команда потратила время на разработку этих правил, но потом могут начать ими пренебрегать.
В случае если сотрудник экстренно покидает команду, надо прибегнуть к очень быстрой адаптации нового сотрудника и определенным механизмам. Как говорилось выше, необходимо всегда держать в актуальном состоянии описание проекта, поэтому первым делом специалист должен проверить актуальность информации в документе с описанием проекта. Далее необходимо проверить поставленные задачи и оставить комментарии для нового специалиста. То что может быть очевидно для одного сотрудника, может быть неочевидно для другого. Новый специалист должен в ускоренном режиме изучить проектную документацию и сразу приступить к работе на проекте, при этом необходимо, чтобы минимум 1 день старый сотрудник проработал с новым.
Ввиду этого, очень важно погрузить нового специалиста в предметную область проекта и бизнеса, чтобы специалист понимал как всё работает.
Замена специалиста может происходить по следующим причинам:
1. Увольнение сотрудника2. Отпуск или болезнь
3. Вынужденный перевод на другой проект (перегорел)
Команда должна быть всегда готова к тому, что она может потерять какого-то из членов команды. Важнее всего обеспечить безболезненное решение данной проблемы. Для этого необходимо выполнять следующие инструкции.
1. Ведите документ small-review
В котором будет описан сам проект и основные изменения в нем. Сильно детализировать этапы проекта не нужно, так как основные задачи по проекту храняться в таск-трекере. Надо вести такой документ, чтобы любой специалист взяв его в руки и прочитав, смог получить максимум информации о нем за минимально короткое время. Этапы проекта описывайте со статусами, которые будут говорить о той команде или группе специалистов, которые занимались этим. Например этап с тестированием необходимо отметить, что он связан с тестированием, а этап с крупным внедрением back-части, должен относится к back-end.
2. Должностные инструкции и правила на проекте
Помимо должностных инструкций и корпоративных стандартов, на проекте могут быть использованы определенные командой правила по написанию кода, тестированию, взаимодействию с репозиториями и т.п. Эти правила, регламенты и инструкции надо обязательно вести и иметь возможность оперативно их предоставить.
Также очень важно следить за актуальностью этих правил, так как в начале проекта вся команда потратила время на разработку этих правил, но потом могут начать ими пренебрегать.
Адаптация нового специалиста
Если специалист покидает команду не в срочном порядке, то у руководителя проекта есть время на плавное внедрение нового специалиста и передачу ему задач от старого коллеги. В этом случае достаточно подобрать максимально похожего специалиста (по скилам), потом предоставить ему все правила и регламенты по проекту, а также описание проекта. Обычно на изучение проектной документации уходит 2-5 дней, потом уже в боевом режиме новый специалист начинает свою работу.В случае если сотрудник экстренно покидает команду, надо прибегнуть к очень быстрой адаптации нового сотрудника и определенным механизмам. Как говорилось выше, необходимо всегда держать в актуальном состоянии описание проекта, поэтому первым делом специалист должен проверить актуальность информации в документе с описанием проекта. Далее необходимо проверить поставленные задачи и оставить комментарии для нового специалиста. То что может быть очевидно для одного сотрудника, может быть неочевидно для другого. Новый специалист должен в ускоренном режиме изучить проектную документацию и сразу приступить к работе на проекте, при этом необходимо, чтобы минимум 1 день старый сотрудник проработал с новым.
Знания о предметной области
Чтобы быстро начать работать на проекте и показать отличные результаты - недостаточно быть просто опытным специалистом, надо отлично разбираться в предметной области заказчика. Для примера, если специалиста подключили к проекту “Ставки на спорт”, а специалист совсем не разбирает ни в спорте ни в ставках. Конечно, специалист может делать работу как робот, не понимая что он делает, но при таком формате работы будет крайне низкая эффективность и высока вероятность ошибки.Ввиду этого, очень важно погрузить нового специалиста в предметную область проекта и бизнеса, чтобы специалист понимал как всё работает.
Данную информацию рассматривайте как вводную часть к полноценному регламенту, который скоро появится в данном разделе.