а кто же пиздить будет?

Пиздить даже hr может, дай волю

это не так воспринимается
пиздить должен кто-то свой, кто воспринимается, как член той же стаи, но чуть выше рангом

В Agile о многом говорят «команда должна договориться». Все мы знаем, как договариваются о дизайне два сеньора с различными взглядами на правильные шаблоны разработки. Долго и дорого, и результат далеко не всегда хорош.

Источником решений может быть Социократия. Недавно ее набор принципов и шаблонов был пересобран с учетом достижений Agile, холакратии, бирюзовых организаций, концепции поток создания ценности и других современных методов, и появилась Социократия 3.0. Авторы утверждают: «В любой организации есть проблемы. Вы можете попробовать отдельные шаблоны социократии для их решения, и если они помогут — применяйте их дальше». Давайте вместе с Максимом Цепковым разбираться в этой теме https://bit.ly/3ytvJi9

✅Встречаемся в Петербурге 16-17 сентября на долгожданном Saint TeamLead Conf 2021. Расписание уже на сайте.👉 https://bit.ly/3rBBacf

Спасибо, он же обновляет свой курс, да?)))

Буквально вчера говорил, что время обновления еще не пришло

то говорит, что не пришло, то через месяц говорит якобы обновит. чему верить-та - вопрооос

это он про повышение до 500

😀

А что нужно сделать чтобы говорил по другому?

Господа, у меня тут, допустим, у друга гипотетическая ситуация. Допустим, в одном департаменте ушел директор и команда делавший сервис А, и допустим техлид достался код и какие-то обрывки документов. И техлид предоставляет компетенцию в виде несколько коротких обзорных документов, что типа проект говно, его надо закрывать и на время надо сделать несколько сервисов, которые будут предоставлять урезанный функционал клиентам. Ну чтобы не стопорить бизнес вообще. Так как проект стоит серьезных денег, ни менеджер, ни тех дир не готовы взять ответственность за какое-либо решение. и технической компетенции им тоже не хватает понять ни домейн, ни имплементации ни проблемы сервиса А. Вместо этого они просят техлида описать проблему, но описание техлида они тоже понять не могут, так как у них нет пониманий домейна. Тех лид тоже особо не стремится что-то пояснять, так как привык работать по требованиям продуктовиков. В общем, проект стопорится и тех лиду предъявляют вполне обоснованно, что он не может нормально коммуницировать, и это ему помешает в дальнейшем повышении грейда. Как здесь поступить техлиду? Брать ответственность, предсказывать возможные продуктовые требования и описывать домейн и уже в рамках такого документа (который хз как еще понятно написать для людей не в теме) проблемы сервиса А? Или дальше забить болт и ждать нормальных требований бизнеса?

Работать вместе с бизнесом, на мой взгляд, и развивать свои софт-скиллы.

В данном проекте тоже нет бизнеса, их тоже уволили, так как они не справились с запуском.

Типа сто не знает домен?

А какой стек, если не секрет?

Да, предыдущий СТО ушел, вот текущий полгода только и конкретно в домейн сервиса А он не въезжает.

за полгода не въехать - это пахнет профнепригодностью...

Ну так я не говорю про РО/СТО, если в контексте бизнеса вы имеете в виду именно их. Я говорю о клиентах.

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