- 10
- 0
Поделитесь с друзьями
Когда новый сотрудник приходит на проект, насколько просто его ввести в курс дела? Как быстро он сможет начать делать первые самостоятельные шаги, а его работа приносить пользу? А теперь представьте, что к вам пришёл новый сотрудник, которому вы должны рассказать не о какой-то части проекта, а вообще обо всём. И так, чтобы это всё он смог поддерживать и развивать полностью самостоятельно, без вашего участия. Звучит сложно? А теперь представьте себя на месте такого сотрудника. Именно о таком уровне сложности следует говорить, когда дело касается приёмки чужого проекта.
***
Тема для меня близка по нескольким причинам. С одной стороны, я сталкивался с этим много раз в разных разных ролях; был как на стороне передающего, так и на стороне принимающего. С другой, недавно мне пришлось принимать проект у стороннего подрядчика и прошелся по всем этапам. В итоге я решил обобщить и поделиться накопленным опытом.
Поскольку брать ответственность сложней, чем отказываться от нее, основной акцент будет делаться на процессе приёмки. Для полноты картины рассмотрю общие моменты, но основную часть доклада хотел бы посвятить техническим аспектам, а не управленческим. Проблемы, вопросы, задачи, на которые должен найти ответ техлид, программист, инженер. В каком порядке и что нужно делать; что точно не нужно делать и т.д.
Краткое содержание:
* Мотивация сторон - какие проблемы могут возникнуть еще до начала передачи, что нужно учесть, как действовать.
* Плавная передача - как минимизировать потерю темпа разработки, сохранить накопленный опыт и избежать вынужденного переписывания legacy-кода.
* Состав новой команды - что следует учесть при формировании принимающей команды, каков должен быть уровень участников.
* Сроки передачи - как дать правильный ответ до начала приемки, особенно если вы ничего не знаете о проекте.
* Возможные проблемы - как правильно выявлять и классифицировать проблемы принимаемого проекта.
* Основные действия и базовые критерии успеха - минимум, который нужно сделать на техническом и организационном уровне.
* Выравнивание проекта - что делать инженерам в первую очередь и почему это нужно делать.
***
Тема для меня близка по нескольким причинам. С одной стороны, я сталкивался с этим много раз в разных разных ролях; был как на стороне передающего, так и на стороне принимающего. С другой, недавно мне пришлось принимать проект у стороннего подрядчика и прошелся по всем этапам. В итоге я решил обобщить и поделиться накопленным опытом.
Поскольку брать ответственность сложней, чем отказываться от нее, основной акцент будет делаться на процессе приёмки. Для полноты картины рассмотрю общие моменты, но основную часть доклада хотел бы посвятить техническим аспектам, а не управленческим. Проблемы, вопросы, задачи, на которые должен найти ответ техлид, программист, инженер. В каком порядке и что нужно делать; что точно не нужно делать и т.д.
Краткое содержание:
* Мотивация сторон - какие проблемы могут возникнуть еще до начала передачи, что нужно учесть, как действовать.
* Плавная передача - как минимизировать потерю темпа разработки, сохранить накопленный опыт и избежать вынужденного переписывания legacy-кода.
* Состав новой команды - что следует учесть при формировании принимающей команды, каков должен быть уровень участников.
* Сроки передачи - как дать правильный ответ до начала приемки, особенно если вы ничего не знаете о проекте.
* Возможные проблемы - как правильно выявлять и классифицировать проблемы принимаемого проекта.
* Основные действия и базовые критерии успеха - минимум, который нужно сделать на техническом и организационном уровне.
* Выравнивание проекта - что делать инженерам в первую очередь и почему это нужно делать.
UWDC 2026, секция Бэкенд
Время доклада ещё не назначено

Комментариев ещё нет — будьте первым!