Адаптация в команде есть? А если найду?

[Cheater]

новый сотрудник делает задачу, считает её готовой, закрывает тикет и идёт дальше наносить добро проекту. Но при этом не идёт к QA

Странная проблема. Обычно по первому багфиксу нового разработчика ведут за ручку от и до.

[dalerank]

Одно время ~2016 было поветрие все делать через конфлюенс. Я застал момент, когда нужно было писать таски-опросники для новеньких и делать мини-проекты для онбординга, так что нет, не ведут. Да и недавний опыт с мобильной компанией, тоже показывает, что не ведут.

[Jijiki]

по моему личному мнению, зависит от структуры звёзд на небе и позиций планет, до, от коллектива и прочее, команда на то и команда.

это как с движком, вам нужен работник, который специалист и понимает, что он делает, но инфраструктура движка - велосипеда разрослась, банально придётся выделить время, чтобы показать человеку, что где, даже если оно всё "бюрокрастически" задокументированно в брайзере, а обучать движку, который разрабатывает студия, это как повышение базы для своих же сотрудников, так и получается, что наименьший делитель, это ходовые известные сертифицированные, стандартизированные продукты, чтобы на входе сказать, что этот продукт известен всему миру, и это уже как требование), но шаг в сторону, и вот уже покажи-покажи поидее, потомучто любой велосипед требует адаптации )

кароче это про управление в долгую, не про управление как должность и цель, а баланс между обучением/вводом нового сотрудника.

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

[Kromster80]

А ещё, приход нового человека в команду это прекрасная возможность для "коридорного тестирования" внутренних процессов. Да, "у нас так принято", но если все регулярно собирают одни и те же грабли, проблема вероятно не только в них. Все вот эти неявные знания, личные договорённости итп надо переодически проверять и переносить в процессы, так, чтобы накосячить было сложнее (или невозможно).

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

[dalerank]

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

[onets]

«В гости со своим самоваром не ходят» 😀

[LeVoN_CCCP]

“подожди неделю само отвалится”. … а простому терпению. Способности подождать чтобы человек сам понял, что он чего-то не знает, и тогда уже подойти и помочь.

Тоже к этому пришёл, вот только регулярно бывают проблемы с этим, потому что:

1. я смотрю на этот цирк неделю, хотя можно за 30 минут сделать (ну ок не царь, не развалюсь, хотя моральный дискомфорт силён)

2. всё это время ошибки копятся, а если есть зависимости, то начинаются косяки и в них

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

В итоге чисто математически, то что можно было сделать неделю назад за 30 минут мы получаем за 4 часа и неделю недовольства от тех кто пользуется. С другой стороны, если ты не хочешь опять подтирать за кем-то, ты обозначаешь проблему, а дальше она почему-то перестаёт быть твоей пока к тебе не придут с этой просьбой и менеджер не подтвердит необходимость твоего действия. Но при таком подходе все счастливы, возможно, кроме тебя самого.