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

Я начал смотреть с 5ой минуты примерно и подумал сначала что это стендап. Смеялся над шутками.... оказалось это не шутки.

@matthewthaddeus6673

2 жыл бұрын

i guess im asking the wrong place but does anybody know a method to log back into an Instagram account? I was dumb forgot my login password. I would love any help you can offer me!

@a.p.8469

2 жыл бұрын

Даже таким же тоном излагает

Классный доклад! И остроумный, спасибо!

Саша, спасибо! Очень даже здорово!

«Я не дружить сюда пришёл, а работать» - это нормальный заход и это правда. Если вас уволят или вы уйдёте, бывшие коллеги плюнут, разотрут и забудут о вас. Так какого хрена с ними дружить? Это не дружба, это временное сотрудничество. Вещи надо называть своими именами. Это я про третий пункт доклада.

Браво, Саша!

Очень годно! Спасибо.

Доклад супер просто, спасибо Александре.

Взгляд со стороны разработчика. Посмотрел доклад 2 раза. Первый раз меня бомбануло после первого же совета. Второй раз посмотрел боле вдумчиво. В целом, дело говорит, но такое впечатление, что речь скорее о симптомах, а не сути проблем. Что меня бомбануло в первом совете. Если его перевернуть, то получается что лиды не нужны, а должна быть плоская структура команды. И вобщем-то видно, что автор ратует за подобные сруктуры. Тут вознакают такие вопросы, как архитектура, стандарты и качество кода, выбор технологий и подходов, рефакторинг, найм людей в конце концов. Исходя из логики этих плоских структур решение по данным вопросам должна принимать команда... ЧТО??? 2 человека примерно одинакового уровня могут между собой договориться по поводу стандартов и архитектуры. А что делать если в команде человек 10 и среди них есть и джуны и сеньоры? Или рефакторинг. Я как разработчк открываю код, и вижу там помойку, понимаю, что нужно сделать рефакториг. В нормальной ситуации я обсуждаю это со своим лидом, который понимает о чем речь. Здесь же я должен продать рефакториг руководству, которое разбирает в коде примерно как свинья в апельсинах. Руководство живет в мире бизнес идей разработчик живет в мире кода и технологий. Это совершенно разные миры, совершенно разное мышление, и разные способности к коммуникации. Как минимум они не понимают друг друга. В лучшем случае разработчик приходит с митингов послушав о том, как космические корабли бороздят просторы Большого театра, жалея потраченное время, возращается к поддержке легаси. С наймом людей в плоских командах особое веселье. В нормальной ситуации нанимаясь на работу, я общаюсь со своим непосредственным руководителем. Я вижу его уровень и требования к навыкам. Я могу, хотя бы, предположить в какую команду я попаду. Я в конце концов, смогу предположить комфортно ли мне будет работать этим конретно руководителем и он тоже может. В плоской структуре меня на работу принимает человек, который ни за что не отвечает, например разработчик из другой команды. И на вопросы типа, а как это у вас устроено, я получаю ответ: "Зависит от команды в которую попадете". Работал я в командах без лидов, это было ужасно. Я вовсе не призываю навесить всю возможную ответсвенность на одного человека. Но есть руководящие роли и должен быть человек за эти роли ответсвенный. И 2 лида в команде из 6-ти человек это, порой, более чем нормально. Если один ответсвенный за коммуникацию, мотивацию, командное взаимодейстие и рост. А второй за архитектуру, инфраструктуру и технологии, при этом второй лид может быть пишущим. Вот почему-то у строителей не возникает мысли о том, чтобы сделать бригады без прорабов. А из мега одаренных мененеджеров в разработке ПО эти идеи просто бьют ключом.

@anton-tkachenko

2 жыл бұрын

я вообще не понял, почему кейс компании на 18 человек как-то обобщается в паттерны :) Если надо сидеть с командой по 2 дня - а команд три, то что делать?

@user-gk6mq8fk3k

2 жыл бұрын

Вы очень радикально подходите к пониманию плоской структуры команды. Отсутствие формальных ответственных по какому-то направлению не означает, что данная роль в команде пустует или распределена на всех. И тем более это не означает отсутствие ответственности за принятые решение. Плоская структура - это всего лишь отсутствие формализации, которое призвано обеспечивать комфортную среду, где все необходимые роли и компетенции в команде будут развиваться естественным образом. Пример в двух словах: формально в команде нет ответственных за архитектуру продукта, но есть Вася и Петя, которым очень интересно прокачать себя в этой области, и они готовы поэкспериментировать и взять на себя такую ответственность, предоставив команде целых двух специалистов для закрытия роли. Само собой, такой подход не панацея, и его можно очень легко приготовить неправильно (банально, достаточно никак не мотивировать сотрудников принимать на себя какие-то роли и совершенно не собирать долгосрочные метрики), но, по моему субъективному опыту, такая организация работы обеспечивает буст роста у junior/middle (а иногда может оказаться привлекательной даже для senior-разработчиков, желающих попробовать себя в чём-то новом с подстраховкой). Аналогии - от лукавого, но про тех же строителей - на рынке полно бригад, работающих без прорабов; они не строят небоскрёбов, но вполне себе бодро могут собрать каркасник, построить баню или сделать ремонт в квартире. Каждой задаче - свой инструмент :)

@EshkinKot1980

2 жыл бұрын

@@user-gk6mq8fk3k Может быть, в теории это и выглядит как хорошая идея, но то, что я видел напрактике, было весьма печально. Как отстутсвие формализации добавляет комфорта и кому? Мне, как разработчику, это добавляет только напрягов и работы, которой программист не должен заниматься. Безусловно у меня растут скилы смежные с программерскими, но больше денег мне это не приносит. А кому точно становиться комфортнее, так это менеджерам, которые не умеют и не хотят ничего делать. Для меня лично формализация это порядок, её отсутсвие - бардак. Всякая аналогия ложна, я в курсе. Мне нужно сделать ремонт в новой квартире, а я работаю - мне некогда. Мне намного удобнее договариваться с одним человеком, который потом будет контролировать рабочих. В случае бригады без прораба, мне придется общаться со всеми рабочими и самому ими управлять (в противном случае, у меня в квартире будет Артнувел). Другими словами, лично я не могу всерьез рассматривать бригаду без прораба, хотя речь идет о достаточно банальном ремонте квартиры. Вася и Петя решили взять на себя ответсвенность... А в чем эта ответсвенность заключается? В худшем случае они уволятся и найдут себе работу с повышением. Причем, именно уволятся, так как уволить сотрудника по статье в РФ почти нереально. Если Вася и Петя работают в интернет магазине, для которого тысяча заказов в месяц, это хороший месяц. Даже если они вообще не разбирались в архитектуре на момент начала "прокачки", наверняка, от этого все только выиграют. Но если для магазина тысяча заказов в минуту это норма (не пиковое значение), то убытки компании от такой "прокачки" могут составить их зарплату за несколько лет. И это интернет магазин, далеко не самая сложная предметная область, более того, область подробно описанная.

@user-gk6mq8fk3k

2 жыл бұрын

​@@EshkinKot1980 я понимаю, что вы получили негативный опыт в таком подходе, и прекрасно понимаю, как это могло произойти и насколько это было болезненно. Мой субъективный опыт в качестве разработчика говорит о том, что может быть по-другому, чем я и хотел бы с вами поделится :) Само собой, возможна ситуация, когда данный подход применяется (как вы точно заметили) "лениво и некомпетентно", тогда результат будет очевидно плачевным. Использование плоской структуры требует плотного включения руководства в жизнь команды и рабочий процесс каждого её участника. Рост скиллов члена команды в смежных областях несомненно должен монитизироваться и поощряться, дополнительные обязанности должны быть полностью добровольными, любая инициатива должна иметь метрики и конечные цели. Например, если вам приходится общаться с заказчиками и проводить аналитику когда вы к этому совсем не готовы - это неправильно и инструмент используется неверно. Если же вы готовы общаться с заказчиками - менеджмент должен обеспечить вам такую возможность и установить метрики, по которым будет оцениваться успех вашего развития в этом направлении. В любое время по инициативе любой из сторон инициатива может быть заморожена. Роль может быть взята другим членом команды или непосредственно менеджментом. Некоторые инициативы и роли требуют выделения других инициатив и ролей. Как вы верно заметили, неопытные архитекторы в долгосрочной перспективе способны убить продукт, потому им в любом случае потребуется менторство, а также контроль со стороны аналитики и QA (валидация архитектуры согласно плана развития продукта и нагрузочное тестирование, как минимум). Конечно же, этот подход не подойдёт в поддержке "дорогих" продуктов, но он вполне подходит для запуска MVP, внутренних продуктов или при отсутствии продуктовой команды вообще. И, само собой, возможна очень нехорошая ситуация, когда иницативу по той или иной роли в команде не хочет на себя брать никто, но, боюсь, это просто говорит о том, что команда в таком виде существовать в принципе не может, и формальные роли мало что изменили бы.

@EshkinKot1980

2 жыл бұрын

@@user-gk6mq8fk3k Мне кажется, что вы описываете несколько идеалистическую картину мира. В реальной жизни так не бывает! На галере, где клепаются более-менее однотипные продукты, особенно, если всё разбито на микросервисы, такой подход может работать. И мидлу крайне интересно понять весь цикл разработки ПО. Собственно говоря, поняв его и набив опыт в 4-5 лет, он автоматом становится сеньёром. Но эта система имеет два серьезных недостатка: 1. Завышенный набор требований к джуну. 2. На галерах мало платят. И как только сеньор осознает себя сеньором, он валит в дорогую и сложную разработку, где разница в зп с лихвой перекрывает монетизацию смежных навыков на галере. А кроме галеры (веб студии или другой заказной разработки), я с трудом смогу представить, где этот подход будет работать. Может быть в стартапах, но стартап это безумно удорожает и слегка замедляет.

Для себя не открывал ничего нового, но думаю, что многим людям есть над чем задуматься.

круто, спасибо!

Спасибо

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

Чорт, как это все знакомо! Может тоже стать agile coach :)

Благодарю! Отличнейший доклад.

Всё супер, посыл понятен.

Как спикер - просто божественно👍👍👍 юмор, интонации, жесты, паузы))

Великолепнейший доклад, спасибо.

Очень напоминает бизнес тренеров и продажу успешного успеха. Парень правильно спросил. Только сформулировать не успел

Доклад был про как угробить команду, а в итоге такой же как и тысячи других одинаковый и как по букварю

Хм,.. НЕТ сразу с первого примера как-то непродумано

Это че доклад про вредные советы? Какого хера менеджеру надо тратить время рассказывать про его обязанности каким-то разрабам джунам? Какое их дело по сути, и как команда из 6 человек проживет без Лида??? Они же полный балаган устроят без субординации елементарного код ревью стандарта не будет без Лида.

По стилю изложения: нудный тон, слова паразиты "крутой", "супер",...