Вы слишком утрируете кейс. Если ПМу сказал Тимлид, что надо рефакторить, а то упадем. Но ПМ его не послушал и все упало - ПМ дурак, ему говорили, не слушал. Если не научится на этой ошибке - гнать такого ПМа в шею. А может ПМ принял решение катится, так как сроки дико поджимали и был риск потерять ключевого клиента и риск вылететь всей компании в трубу. И после выкатки было все ок, так как тимлид перфекционист (и ПМ это понимал) и просто хотел сделать 25-й рефакторинг и так нормального кода (тут уже гнать такого лида :)
Принимать решение о выкатке, естественно, надо компетентному человеку. Конечно, тот кто принимает решение должен обладать многими скилами, как с технической стороны, так и процессной и бизнесовой.
В реальной ситуации, без ответственного человека, всё это работает в утопическом Скраме самоорганизованной команды. А реальности (я такое видел), когда ПМ и Маркетинг говорили, что надо катить скорее, QA лид просил провести очередной регресс, тимлид хотел переписать очередную библиотеку, дизайнер изменить фронт на более классный, в результате ничего никуда не ехало и клиент рвал и метал, так как не понятно было, кто за что отвечает и все давили своим авторитетом и что записано у них в должностной инструкции.
Сори, но не согласен. Любые правила, в том числе и кто за что отвечает - должны быть зафиксированны. Отсутствие таких фиксаций и ведет к конфликтам, так как каждый решает, что это его право/привелегия/обязаность/долг принять решение. На примере, который описан в статье: проджект говорит, что надо катить продукт на прод, а тимлид, что надо рефакторить. Из-за того, что непонятно, кто решает, едет ли релиз и возникает конфликт. А было бы зафиксированно, что (условно) ПМ принимает решение о выкатке релиза на продакшен, то вся ответственность на нём. Он должен выслушать аргументы тимлида на счет рефакторинга, взвесить риски и принять решение - катим или нет. Упадет прод - виноват и отвечать будет ПМ.
Знаешь, знаешь что я заметил? Никто не паникует, когда всё идёт согласно плану... даже если план чудовищен. Если завтра я заявлю прессе, что один из членов банды будет застрелен, если грузовик солдат взлетит на воздух — паники не будет. Потому что всё это — часть плана. Но когда я говорю, что какой-то жалкий мэр умрёт, все вдруг теряют голову. Совсем немного анархии, нарушение установленного порядка — и всё вокруг повергается в хаос. (с)
Плюсую! Благие начала убила накрученная сверху философия, которая позволило превратить обучение 10 страничному гайду в тонный курсов и сложных сертификаций, без которых вы не поймете что такое скрам.
п.с. И только посмейте назвать наш фреймворк ужасным сломов метод/способ/процесс !!!
Как-то уныло вышло. Я люблю понятие экосистемы, но тут явно цена завышена. Характеристики далеко не топ, привязка к экосистеме, расхваленный звук все равно будет хуже самого дешевого внешнего. Просто телек на 65 дюймов с внешним саундбаром будет раза в 2 дешевле чем от яндекса. Ну а какой-нибудь кинопаб даст фору всей экосистеме.
Очень тригернуло "Не хотите делать — отдайте другому" - спорный приём. А по планированию, ничего лучше, чем Тайм-Драйв от Г. Архангельского, пока не написали, за последние 15 лет.
ну он и сейчас прорывной, если сравнивать с imessage/whatsapp/viber
ой, дублированный комент отправил
Вы слишком утрируете кейс.
Если ПМу сказал Тимлид, что надо рефакторить, а то упадем. Но ПМ его не послушал и все упало - ПМ дурак, ему говорили, не слушал. Если не научится на этой ошибке - гнать такого ПМа в шею.
А может ПМ принял решение катится, так как сроки дико поджимали и был риск потерять ключевого клиента и риск вылететь всей компании в трубу. И после выкатки было все ок, так как тимлид перфекционист (и ПМ это понимал) и просто хотел сделать 25-й рефакторинг и так нормального кода (тут уже гнать такого лида :)
Принимать решение о выкатке, естественно, надо компетентному человеку. Конечно, тот кто принимает решение должен обладать многими скилами, как с технической стороны, так и процессной и бизнесовой.
В реальной ситуации, без ответственного человека, всё это работает в утопическом Скраме самоорганизованной команды. А реальности (я такое видел), когда ПМ и Маркетинг говорили, что надо катить скорее, QA лид просил провести очередной регресс, тимлид хотел переписать очередную библиотеку, дизайнер изменить фронт на более классный, в результате ничего никуда не ехало и клиент рвал и метал, так как не понятно было, кто за что отвечает и все давили своим авторитетом и что записано у них в должностной инструкции.
Сори, но не согласен. Любые правила, в том числе и кто за что отвечает - должны быть зафиксированны. Отсутствие таких фиксаций и ведет к конфликтам, так как каждый решает, что это его право/привелегия/обязаность/долг принять решение.
На примере, который описан в статье: проджект говорит, что надо катить продукт на прод, а тимлид, что надо рефакторить. Из-за того, что непонятно, кто решает, едет ли релиз и возникает конфликт. А было бы зафиксированно, что (условно) ПМ принимает решение о выкатке релиза на продакшен, то вся ответственность на нём. Он должен выслушать аргументы тимлида на счет рефакторинга, взвесить риски и принять решение - катим или нет. Упадет прод - виноват и отвечать будет ПМ.
Знаешь, знаешь что я заметил? Никто не паникует, когда всё идёт согласно плану... даже если план чудовищен. Если завтра я заявлю прессе, что один из членов банды будет застрелен, если грузовик солдат взлетит на воздух — паники не будет. Потому что всё это — часть плана. Но когда я говорю, что какой-то жалкий мэр умрёт, все вдруг теряют голову. Совсем немного анархии, нарушение установленного порядка — и всё вокруг повергается в хаос. (с)
Надо начинать с четкого разделения обязаностей, ответственности и полномочий. Хотя бы простая RACI матрица, которая со всеми сторонами согласованна.
да, таблица, где SP приравнены к часам - отдельная песня в некоторых компаниях :)
Плюсую! Благие начала убила накрученная сверху философия, которая позволило превратить обучение 10 страничному гайду в тонный курсов и сложных сертификаций, без которых вы не поймете что такое скрам.
п.с. И только посмейте назвать наш фреймворк ужасным сломов метод/способ/процесс !!!
при этом команд без менеджеров в реальной жизни, почти не бывает)
согласен. плохо, что многие этого не понимают и суют скрам во все подряд проекты.
еще аджайл коучей забыли)
Курс должен быть законодательно закреплен на уровне 100 рублей. Чтобы удобно было считать.
а интеграция с гитом для ci/cd имеется у него?
Тут только лучи поддержки и аплодисменты, что смог вырулить проект, коллега!
иииии.... всё
посыла нет, не гожусь в посыльные :)
но, наверное, основная мысль стати в последнем предложении.
Хороший, калькулятор, пойду тестить.
п.с. еще бы научится точно прогнозировать сколько часов потребуется на ту или иную фичу :)
А нет сайта, куда его портировали, чтобы в браузере погонять?
Осталось на этом ХР через parallels запустить MacOS, чтобы круг замкнулся :)
Как-то уныло вышло.
Я люблю понятие экосистемы, но тут явно цена завышена.
Характеристики далеко не топ, привязка к экосистеме, расхваленный звук все равно будет хуже самого дешевого внешнего.
Просто телек на 65 дюймов с внешним саундбаром будет раза в 2 дешевле чем от яндекса. Ну а какой-нибудь кинопаб даст фору всей экосистеме.
Очень тригернуло "Не хотите делать — отдайте другому" - спорный приём.
А по планированию, ничего лучше, чем Тайм-Драйв от Г. Архангельского, пока не написали, за последние 15 лет.