"Мотиваторы" со стороны компании? Если человек склонен делиться своим опытом с подчинёнными/коллегами - он поделится, а если нет - то вы его не заставите.

у меня сложилось впечатление, что полемика примерно так выглядит: эй, ребята, у меня есть коробочка, но что в ней, я не покажу, но давайте подумаем вместе, что там может быть такого здоровского. на поверку оказывается, что в коробочке пока ничего нет, но ожидалось, что что-то появится )) это как играть в морской бой и последний однопалубный на своей доске не рисовать до самого последнего хода )) имхо, конечно 🤓

К сожалению, если сразу открыть все клетки, то тогда будут социально-ожидаемые ответы %(

Со стороны компании эти уже "стимуляторы" %)

"Если человек склонен делиться своим опытом " - А откуда берётся эта склонность? Я свою версию высказал (https://t.me/TeamLeadTalks/219782), есть ли другие варианты?

0. У него есть опыт, который имеет смысл передавать другим.
1. Он настроен передавать этот опыт.
2. Его есть кому передавать.
3. Те, кому его можно передать, не вызывают отторжения.

Так вижу.

о новостройка

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

Хорошо, пункты 0, 2,3 - необходимые преусловия.
Самое важное  "настроен передавать этот опыт"   - это тоже самое что " склонен делиться своим опытом"  -, но что лежит в основе настроя ?

а) Мне за это платят.  (есть KPI  на обучение, это зафиксировано в должностной инструкции)
б) Обученному сотруднику я могу делегировать работу и это снимает с меня головняк.
в) Бартер, если я помогаю, то  мне помогают.
г) Я вижу в этом свою миссию в компании
д) Я пишу код и никого не обучаю. (мне платят за написание кода)

eugggh

@dumtest Ромаааааааан

б) или г)  - только не в таком пафосном исполнении, конечно

ты чего?

#язабан

Погоди, мы можем ещё спасти сотни несчастных

Поздна спасать!

Благодарю за ответ!

Всем привет, есть кейс по разделению команд/компонент, интересны мнения коллег

Разработку ведем в кросс-фунциональных "feature teams".
Помимо задачи по нашему основного сервиса нужно доработать несколько потребителей нашего API, незнакомых нам сервисов, БЕЗ ВЛАДЕЛЬЦА.
Т.к. владельца нет, то нужно не просто доработать вызов API, а выкатить его апдейт в продакшен.
Но скоуп задачи ведь разобраться в чужом сервисе и выводить его в прод куда больше, чем доработать вызов АПИ.
Я бы предпочел поднять пулл-реквест, а владелец принял фичу на поддержку.

У меня какой-то дискомфорт от такой модели, такое ощущение, что катишь в прод не пойми что +
Мне кажется, что само по себе отсутствие владельцев кода за конкретные компоненты приводит код в хаос, качество страдает.
Т.к. сервисов под сотню, то никто не будет улучшать конкретные сервисы, а просто закидывать свои фичи и "бежать" дальше.

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

Как вы относитесь к такой модели разработки? Может все норм и это мой личный таракан? 🙂

Солидарен с тобой, но бизнесу виднее каким образом решать свои задачи))

Кто то такой процесс продал, кто то купил. Жизнь очень разнообразна в своих проявлениях.