А на это кстати есть известные приемлимые ответы, как заготовка?

Такое бывает, но узнать мнение лида о том, как такое разрешать всё равно стоит. Попадаются такие, которые сразу уволить готовы, без разбора

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

@focusshifter Есть опасения что эта инфа станет просто очередной страничкой в вики. Как часто вы ее актуализирете?

Про между командами - у убера хорошая практика межкомандного взаимодействия, она не всем подходит, но если становится частью инженерной культуры, то безумно выручает в поиске корней того или иного решения - https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/

команды должны понимать, зачем это вообще в принципе, и за отклонениями от процесса должны следить коллеги in a non-violent way, тогда не станет

актуализация:
- вынесение проблемных случаев на alldev-обсуждение (вынести может кто угодно)
- proposal по результатам обсуждения
- голосование по нем
- по результатам голосования (если да) - дата энфорсмента обновленного документа

предупрежден - вооружен

Это вот и может стать проблемой, можно позвать людей с авторитетом и рассказать про инженерную культуру и тд. Но может подскажете еще каикие-нибудь способы мотивации?

Мы с коллегой какой-то момент систематизировали наши цели и практики ревью, он собрал эту в готовую для применения статью (и понемногу её обновляет). Там есть про "зачем мы это делаем вообще"
https://medium.com/@pstepchenko/pull-requests-and-code-review-30abde0c98d3

Обычно хватает подробных объяснений о "что приобретаем/что теряем" с Q&A, показывающего, что это не ААА БЮРОКРАТИЯ. Ну и документы должны приниматься и модифицироваться коллективно, их можно (и стоит) держать отдельной репой. Можно посмотреть, как гитлаб это делает - https://gitlab.com/gitlab-com/www-gitlab-com/tree/master/source/handbook.

А со случаями сопротивления нужно работать индивидуально.

Класс, спасбо большое за ссылку и за советы!

🤘

Что такое коробка?

Коробочные версии методологий процессных.
Скрам (лесс туда же)
Канбан

Ааа

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

Накидал список вопросов, думаю вы сможете дополнить: предыдущий опыт
(В общих чертах)

стек. на случай если у заказчика специфические требования или сторонний проект - кого можно кинуть на сторонний проект.

специфические задачи из опыта

конкретная специализация сейчас

есть ли чтото что ты бы хотел улучшить, мб чтото мешает или напрягает, чтото неудобно

кто ты в команде, по твоей оценке (может он работает за всех, а никто об этом не знает (: )

Буду рад услышать критику

Что тебе мешает\нужно что бы расти?

hardskills или softskills тебе важнее?

Да вроде не. А чем он смущает?