Егор Бугаенко. Избавляйтесь от экспертов.
HTML-код
- Опубликовано: 26 мар 2018
- Возникновение в командах так называемых Subject Matter Experts несет в себе потенциальную угрозу поддерживаемости и живучести проекта. Чем больше знают и умеют люди, тем меньше знает и умеет проект. Это звучит контр-интуитивно, однако на реальных примерах я покажу как важно не допускать скопления знаний в головах участников проекта.
![TRASH or PASS! Eminem ( Houdini ) [REACTION!!!]](http://i.ytimg.com/vi/cB1WrZcMwMc/mqdefault.jpg)
Зачастую "Эксперт" - это просто человек, который задержался на проекте дольше всех, а остальные давно уволились...
You all probably dont give a shit but does any of you know of a way to log back into an Instagram account..?
I somehow lost my password. I would love any tricks you can give me!
@Maxim Curtis instablaster ;)
Шикарный доклад, согласен полностью!
15 минут на доклад дали. Для Егора это только разогрев.
Спасибо
Лайк за "no meetings". Митинги это всегда непродуктивно и потеря времени.
Да, лучше через реквесты общаться, согласен. Бесит такое, очень.
В моей распределённой команде автоматизиторов:
Нет митингов.
Нет кодревью.
Нет счастья.
@@cracoh А все потому что кодревью нет. Оно нужно, а митинги не нужны :)
Согласимся
Идеальный мир без дейли
Тому кто создал ревью ему нужно решить, а ревьюеру до лампочки. Он вообще не отвечает.
спасибо
После просмотра многих роликов с участием Егора это первый, в которм я с ним полностью согласен.
Он выходец из СНГ. Программисты из СНГ не умеют работать в командах, их раздражают митинги итд. Итог то какой: Егор боится размывания и перераспределения ответственности. То что для работника, привыкшего работать в авторитарной модели явно непривычно и непонятно из-за отсутствующих навыков командной работы. Подпитывается это ещё коротким горизонтом планирования и как следствие отсутствием стратегического мышления и ориентацией на решение тактических задач типа извлечения сиюминутной экономии времени. Все это приводит к тому что якобы мега гениальные/мотивированные инженеры универсальной квалификации, решающие сложные нестандартные уникальные задачи способны только к краткосрочным прорывам, что в инновационном секторе конечно по идее должно цениться, вот только не ценится в силу того что из этих прорывов не сделать крупносерийное производство стандартизированного продукта, который купят в итоге люди. Егор просто затрахался принимать на работу инженеров без soft skills. Поэтому сделал так чтобы эти ребята не занимались решением формальной рутинной и от того скучной проблемы типа коммуникации команды. С одной стороны верные выводы, вот только высоких результатов таким макаром тоже не достичь. Придет к финишу тот первым кто пускай и шел медленно и терял время, но шел в правильном направлении.
@@AnalyzeDesire что ты высрал?) зачем ты оправдываешься?)
Сколько текста исходящего из Лондона посыла, что он выходец из СНГ!
@@AnalyzeDesire ты бы точно не подошёл под такую систему, так как судя по этому полотну, ты не умеешь выражать свои мысли письменно.
@@kingcchultz3366 кто-то просто не умеет читать
26:24 ахахахха жиза так же отвечаю Хелоу 😅
Это просто несколько глав из книги Проджект Феникс. Во всех командах есть свой Брэт и задача руководителя - смасштабировать этого Брэта
Вот только непонятно, почему считается, что по умолчанию эксперты не пишут документацию, не делают Knowledge Transfer и борются за то, чтобы никто кроме них этими знаниями не овладел. Все это можно встроить в процесс разработки даже, например, сторя должна быть закрыта только если код разработан, протестирован и задокументирован.
это не "считается" так. это факт. опыт.
Так они работают быстрее, а постоянно есть какие то важные задачи, которые нельзя отложить, а документацию сколько угодно можно откладывать, пока не клюнет
@@eugene_fed Это может быть только ваш личный опыт, у меня он другой - на проекте раз в 2 недели есть Knowledge Transfer, раз в 2 месяца организовываются внутренние конференции, есть также и внешние, Lead обновляет онбординг документы для будущих сотрудников, на проекте используется BDD, есть тест-кейсы, матрица покрытия требований, Wiki страницы для каждого проекта. Опять же это типичный способ борьбы с bus фактором и он работает, лиды приходили и уходили, на какой-то момент не оставалось ни одного сотрудника из изначальной команды, но проект работает, знания переносились на других экспертов. Плюс бизнес в том числе считает риски и планирует эту активности, содержит PTO команду, которая может подключиться и помочь с любым проектом и обычно владеет минимально необходимыми знаниями о каждом компоненте.
Странная логика, если эксперт быстрее и качественнее делает задачи бизнеса, то он выгоден для бизнеса, но не выгоден для докладчика. :) Бизнесу нужно гнать докладчика, а не эксперта. :)
Так для этого и существует код ревью и тим стайл. Чтобы люди в команде читали код и все понимали... Ну и конечно надо документировать...
Да брехня эти код ревью(Я про пул реквесты и апрувы)
Обычно это обязаловка, когда уты просто вынужден заревьювить, и в таком режиме максимум что можно углядеть, это код стайл не соответствует, ковычки не те
@@pseudouser55 не согласен - люди должны проверить, есть ли у тебя тесты и какого качества код. А то зальешь в ветку без пул реквеста и люди прикола не поймут
@@goose896 кому должны? на практике как раз ревью и проходит по сути для стайла, максимум тех ошибок крайних значений, БЛ никто не проверяет на корректность и правильность
Время, потраченное на код-ревью, в зачёт не идёт, как бы. Это такое как бы теневое время, которое как бы должно быть потрачено, как бы... Потому люди часто тупо ставят аппрув. Плюс если будешь постоянно бузить в кодревью, то это почва для конфликтов. А жто нужно только конфликтным людям. Потому проще тот же аппрув нажать. Методов разрешения таких конфликтов обычно в организациях нет - типа сами разберутся. Вот они и разбираются аппрувами - так проще. И в большинстве организаций тебя будут мягко принуждать нажать аппрув, ведь решение создано и код рулы оно проходит, и надо типа идти на компромисс. Это вот реалии, имхо.
@@AndreiDikun ну так в нормальных компаниях или каких нибудь сильных командах от этого отходят. Точно также с ТДД. Только всякие желторотики пренебрегают им
!
а как у джуна спрашивают как дела, тоже через тикет?)
Сначала создал баг, потом в процессе как дела?)
Лучше чем через чат
Архитектор узкое звено же, не платим разрабам но ему занесем 😊
Это все хорошо .. только Егор не учел .. никто не любит читать .. все любят и хотят чтобы ему рассказали как это работает ..
123
Егору хочется сделать из программистов винтики, легко заменяемые, одинаковые, выполняющие ровно то, что от них ждут. Но забывается, что под абстрактным словом "программист" скрывается, в первую очередь, человек.
Касаемо документации я уверен что она не нужна. Просто потому что она всегда отстаёт от реальности(кода), требует много усилий и никто потом ее читать и не будет, кстати. Пиши нормально и документация не нужна. Если речь идёт о документации для внешнего потребителя, то это отдельная работа и ее могут делать вообще другие люди - технические писатели, например.
Звериный оскал капитализма. Более людоедского отношения к людям я ещё не видел.
Избавляйтесь от Егора Бугаенко, он иКсперт во всём... Эксперты - лучшие из лучших. Если они не делятся информацией, значит Вы создали для них такие условия, при которых им выгоднее делать что-то другое.