И Вы всё ещё ничего не поняли?
Я понимаю, что в 2014м было просто поверить пропаганде про печеньки, наркотики и сс-овские наколки. Но сейчас то Вы должны бы заметить, чего стоит эта пропаганда?
Сейчас давления пропаганды в Беларуси почти нет. Шутки Лукашенко это не пропаганда, это паника.
Вот в 14м была пропаганда — очень серьезно подготовленная, с захватом телеканалов в Крыму и блокированием украинских новостей; фейковых украинских новостных сайтов, призывавших запретить русский язык; армии ботов в Фейсбуке; Гоблиновский oper.ru, где в коментах к новостям напрямую приглашали «ехать в братскую страну, для оказания помощи» еще до расстрелов на Майдане. Актеры, типо «мужчин с красивой фамилией Шевченко, которые своими глазами видели трупы без органов под Славянском»; солдатскими дочерьми/матерями; беженцев, боящихся говорить на русском; ребят из Правого Сектора с полными пакетами взрывчатки, которых снимали с каждого приходящего в Крым поезда; обгоревших Беркутов из центральной России в украинской форме милиции в Парламенте Крыма; патриотичных жителей Донецка и Луганска из Ростова, которые в Трелло организовывали из местных живые щиты против входящих украинских силовиков и тд и тп. Российские каналы 24/7 вещающие про фашистов из европейских лагерей, госпереворот, запрет русского языка. Обколотые наркотиками апельсины даже не вспоминаю.
Там же где смелые милиционеры перед знанием парламента Крыма в 14м, которым тыкали в вооруженных автоматическим оружием людей, заблокировавших вход в здание.
Ритуалы Скрам — просты и понятны. Ничего сложно, сакрального, чудесного и т.п. в этом нет.
Это вам они просты и понятны, а а кому-то (многим) не очень. Там и правда нет ничего сакрального, это просто хорошо прописанные инструкции.
А если игнорирует, но понимая зачем и почему и, внезапно, все не сыпется, тогда что?
А если игнорируют, но понимают зачем и почему и, внезапно, все сыпется, тогда что?
Если без шуток, то это другой уровень осознанности, когда на первом месте values & goals. Если ценность, нужная конкретному продукту — очень быстрое деливери, быстрее чем у конкурентов, а какие-то из установленных правил этому мешают, православно будет процессы подкорректировать под конкретные цели. Четкие цели, правильные ценности — это то, чего не хватает многим коллективам для хорошей продуктивности.
Это не так. Просто потому, что «управление проектом» — куда как больше и сложнее, чем следование ритуалам скрама
Ну так «Управление проектом» — это вообще гораздо больше, чем прсто следование инструкциям. Речь шла о Скраме — там есть набор правил, которым нужно следовать. Если вы выбрали Скрам, работайте по Скраму. Если вы сели за штурвал самолета, то пользуйтесь инструкцией по управлению самолетом, а не самосвалом.
Вы не совсем правильно поняли суть написанного.
Скрам — это набор правил и инструкций, для того, чтоб быстро заделиверить продукт соответствующий требованиям заказчика. Такой же, как набор ПДД, задача которого — безопасность всех участников движения при минимальных ограничениях свободы. Такой же, как любая политическая теория, задача которой сводится к обеспечению блага определенной группе людей.
Можно ездить без ПДД, как и разрабатывать ПО без каких-либо правил и ограничений, как и жить в первобытно общинном строе. Это просто и доступно в целом любому социуму, вне зависимости от уровня образования, культурных потребностей, материальных притязаний. Естественно, производительность любой такой системы будет на соответствующем уровне, и ограничиваться будет числом одновременных участников. Вы не напишите хорошее ПО в компании на 1000 человек где нет никакого регулирования, не обеспечите интенсивное автомобильное движение в большом мегаполисе, не поставив светофоры и не разграничив парковочные зоны, и не запустите ровер на Марс обществом, где нет сложной системы законов и развитых политической и экономической систем. Чем более комплексный результат хотите получить, тем больше сложных правил и ограничений нужно устанавливать, тем сильнее регулировать коллектив. Чем меньше культура и уровень образования коллектива соответствует выбранной методологии, своду пдд или законам политического устройства, тем сложнее будет внедрить все это в коллектив. Нельзя просто так взять и построить завод по производству сложной электроники там, где единственным законом было «право сильного», в все образование заключалось в том, как ловить рыбу и изготавливать луки и копья. Нужно поколениями менять систему образования, культуру.
Скрам — сложная система менеджмента, для которой нужен определенный уровень образованности и культуры компании/коллектива, чтоб участники вообще могли строго следовать прописанным правилам. Координация и предсказуемость требуют большого числа ограничений. Если коллектив токсичен, уровень менеджмента примерно соответствует «я начальник — ты дурак, делай как сказали», исполнители читают требования после того, как закрывают задачи, никто не умеет собирать и описывать эти самые требования, то смысла от этой сложной системы никакого. Проще и быстрее работать так, как коллектив работал до этого.
Это результат работы по скраму, когда половина команды не следует инструкциям, прописанным в Скраме. То же самое получается, когда на дорогах общего пользования, половина участников начинает плевать на пдд и ездит как кому удобно. Как следствие — больше дтп, пробки, покалеченные пешеходы. Скрам — те же пдд, только для разработки. Если следуют все, то все работает как часы, с минимумом затыков. Если кто-то нарушает — страдают все. В наших краях скрупулезный менеджмент не приемлется, ценности продукта, компании редко ставятся выше личных предпочтений менеджмента или разработчиков, методологии переделываются под удобство коллектива. Нарушать правила в угоду сиюминутного удобства — норма.
Проблема в менеджменте и в культуре в целом, а не в методологиях.
Главная проблема скрама это то что он слишком сложный для большинства менеджеров. И слишком непривычный для остальных. Из-за этого берут 30% фреймворка, игнорируют всё что не нравится, потом внедряют через одно место и через полгода жалуются.
Главная проблема хорошего менеджмента это то что он слишком сложный для большинства менеджеров. И слишком непривычный для остальных. Из-за этого берут 30% фреймворка, игнорируют всё что не нравится, потом внедряют через одно место и через полгода жалуются.
Agile — принципы, ценности.
Scrum — менеджерский фреймверк для удовлетворения этих ценностей. Список правил, иструкция. Скрам — это серьезный менеджмент, который требует исполнительности и точности на всех уровнях команды. Если кто-то игнорирует — сыпется все. Если команда строго следует инструкции — она делает продукт соотвествующий требованиям заказчика быстро и качественно. Ценой ограничения свободы членов команды (см менеджмент, sdlc).
О реальном благе меньшинств тут речь не идет, как и об избавлении от расизма. Плевать хотел Линус и на меньшинства, и на права, и все остальное. Его задача — уберечь комьюнити от возможных скандалов и давления в мире, где ближайшее время число конфликтов, связанных с правами меньшинств, будет доминировать. Это хладнокровно продуманный политический ход.
Перефразируя старую поговорку:
Нет плохих бояр, бывают плохие цари.
Линус, к счастью, неплохой царь. То, что он не начал в угоду жителям Хабра направо и налево жечь едкими шутками неугодных цветных или сексуальные меньшинства, это наоборот говорит о Линусе как о дальновидном и грамотном лидере. В ядре важнее архитектура, технологии, комьюнити, которые все это дело будут поддерживать, а не детские комплексы или особенности местечковых культурных особенностей. Линус прекрасно осознает все это и не дает собственному эго все испортить.
Я бы не стал торопиться с выводами. В письмах он все так же выжигает ересь, как и раньше, но делает это куда спокойнее. Линус серьезно вырос.
Ближайшее будущее будет пестрить рассовыми/половыми/экзистенциальными конфликтами. К счастью, Линус стал зрелым лидер, в полной мере осознающий, в какую сторону «ветер дует». Он смог усмирить собственное эго ради дальнейшего развития своего детища. Это и есть главная характеристика настоящего лидера — умение поставить общую высокую цель выше хотелок собственного эго. Для эволюции Linux важнее процессы, выбор принципов, технологий и здоровье комьюнити, а не нейминг переменных или веток в гите. Идя навстречу трендам и адаптируясь под современную культуру, Линус оберегает будущее разработки ядра. Лезть в конфликты по бестолковым непринципиальным вопросам — тратить силы и время на то, что не принесет пользы. Приняв неизбежное и сконцентрировав усилие на построении комьюнити, процессах и качестве разработки, можно достичь куда большего.
Нет. И это не значит, что ему нужен новый Бентли. Или старый Мерс. Или старый ржавый таз без тюнинга. Или Бентли с тюнингом. При такой постановке вопроса, нельзя достоверно сказать, что нужно заказчику.
Нужно уточнить требования у заказчика, узнать цену, которую он готов заплатить, сроки поставки.
Если заказчик хочет красиво, но на завтра, а денег у него только на ржавый таз обвешанный тюнингом, то верхом глупости будет выделять на заказ ресурсов как на Бентли. Или вообще брать этот заказ.
Заказчику нужен не код, а продукт.
Продукт — это (условно) код, удовлетворяющий требованиям заказчика.
PM — это тот, кто организовывает процессы утверждения требований и контроля соответствия кода этим самым требованиям.
Вы можете как угодно красиво с блэкджеком и графиками показывать заказчику код, но он собака все равно просит, чтоб код удовлетворял указанным требованиям.
Потому, первоочередная задача PM — мешать разработчику писать быстрый красивый ненужный код. В том числе созвонами.
Не то чтоб это было прям звоночком и говорило о «сидении на попе ровно», но отсутствие текучки далеко не всегда хорошо для бизнеса. Иногда люди приходят не на свое место, и нельзя давать им засиживаться. Иногда люди вырастают быстрее, чем бизнес, и удерживать их — тормозить развитие.
Опять же, 10 лет в компании могут быть в одной должности, а могут от зеленого джуна, до технического директора.
Камерная мораль всего лишь следствие всей этой старой русской модели управления — «власть и авторитет выше ценностей и принципов». Начальник всегда прав, нельзя жаловаться на начальника вышестоящим, нельзя сдавать своих и тд — все это просто результат воздействия сложившейся модели управления на культуру.
В том самом американском менеджменте в этом есть смысл.
За любые проблемы в коллективе отвечает начальник. Поэтому начальник должен узнавать о любых проблемах первым. У него скорее всего более широкое видение ситуации.
Например, вам не нравится, как кто-то выполняет свои обязанности. Вы можете высказать недовольство прямо этому сотруднику. Но может оказаться так, что сотрудник не виноват, ему дали неверную информацию, неправильно организовали его работу, или взяли его по ошибке. Не обладая полной информацией(а в большой компании вы скорее всего не будете обладать всей нужной для понимания ситуации информацией), вы испортите настроение и себе и тому человеку. Возможный конфликт может испортить настроение всей команде, помешать работе. В конце концов за это пострадает как раз начальник.
Поэтому, «там» сообщают о проблема непосредственно начальнику. А он уже смотрит как ее решить с минимальными потерями для коллектива и рабочих процессов.
Говорить прямо о проблемах — у них это часть культуры. Скроешь очевидную проблему, так с тебя потом спросят.
Не в том дело.
История сама по себе слишком неправдоподобна. Либо автор сознательно исказил факты, чтоб подать историю в выгодном ему свете, либо он не осознал до конца происходящее, либо все это от начала и до конца выдумка. Мои американцы склоняются к тому, что это выдумка.
Не только. Второй ключевой момент — метрики. Начали снимать метрики процессов -> смогли оценивать эффективность -> смогли эти процессы менеджить. Кашу метриками не испортишь.
Конечно, без расстановки приоритетов показаниями метрик бы просто подтирались каждую итерацию.
Мы сделали для бизнеса простой инструмент (таблица в Excel), в которой он мог визуально планировать. Менеджеры дрались между собой, спорили, чья задача важнее, а потом уже приходили к нам и отдавали задачи в разработку.
Так как у нас уже были ограничения, то бизнес относился внимательнее к выбору задач, выбирал наиболее важные, а не заваливал нас всякой ерундой, которая им приходила в голову. И ещё один большой плюс: они отбирали задачи сами без нашего участия, не отвлекая разработчиков на совещания, те спокойно работали и не тратили время на встречи.
Вот это та самая ключевая мера, которая может решить большую часть проблем в любой разработке. Хвала вашему менеджменту, который осилил приоритеты. Не смог бы — все эти метрики, налаживание процессов, вовлеченность, оценка — все коту под хвост. Я видел массу примеров, когда даже слабые тех команды с хиленькими процессами при хорошем проектном менеджменте, который умел фокусироваться на приоритетах, показывали крутой результат, а крутые команды из топовых спецов шли на дно, когда менеджмент не мог элементарно определиться, что же продукту важнее.
Сейчас давления пропаганды в Беларуси почти нет. Шутки Лукашенко это не пропаганда, это паника.
Вот в 14м была пропаганда — очень серьезно подготовленная, с захватом телеканалов в Крыму и блокированием украинских новостей; фейковых украинских новостных сайтов, призывавших запретить русский язык; армии ботов в Фейсбуке; Гоблиновский oper.ru, где в коментах к новостям напрямую приглашали «ехать в братскую страну, для оказания помощи» еще до расстрелов на Майдане. Актеры, типо «мужчин с красивой фамилией Шевченко, которые своими глазами видели трупы без органов под Славянском»; солдатскими дочерьми/матерями; беженцев, боящихся говорить на русском; ребят из Правого Сектора с полными пакетами взрывчатки, которых снимали с каждого приходящего в Крым поезда; обгоревших Беркутов из центральной России в украинской форме милиции в Парламенте Крыма; патриотичных жителей Донецка и Луганска из Ростова, которые в Трелло организовывали из местных живые щиты против входящих украинских силовиков и тд и тп. Российские каналы 24/7 вещающие про фашистов из европейских лагерей, госпереворот, запрет русского языка. Обколотые наркотиками апельсины даже не вспоминаю.
Вот тогда была пропаганда.
Это вам они просты и понятны, а а кому-то (многим) не очень. Там и правда нет ничего сакрального, это просто хорошо прописанные инструкции.
А если игнорируют, но понимают зачем и почему и, внезапно, все сыпется, тогда что?
Если без шуток, то это другой уровень осознанности, когда на первом месте values & goals. Если ценность, нужная конкретному продукту — очень быстрое деливери, быстрее чем у конкурентов, а какие-то из установленных правил этому мешают, православно будет процессы подкорректировать под конкретные цели. Четкие цели, правильные ценности — это то, чего не хватает многим коллективам для хорошей продуктивности.
Ну так «Управление проектом» — это вообще гораздо больше, чем прсто следование инструкциям. Речь шла о Скраме — там есть набор правил, которым нужно следовать. Если вы выбрали Скрам, работайте по Скраму. Если вы сели за штурвал самолета, то пользуйтесь инструкцией по управлению самолетом, а не самосвалом.
Скрам — это набор правил и инструкций, для того, чтоб быстро заделиверить продукт соответствующий требованиям заказчика. Такой же, как набор ПДД, задача которого — безопасность всех участников движения при минимальных ограничениях свободы. Такой же, как любая политическая теория, задача которой сводится к обеспечению блага определенной группе людей.
Можно ездить без ПДД, как и разрабатывать ПО без каких-либо правил и ограничений, как и жить в первобытно общинном строе. Это просто и доступно в целом любому социуму, вне зависимости от уровня образования, культурных потребностей, материальных притязаний. Естественно, производительность любой такой системы будет на соответствующем уровне, и ограничиваться будет числом одновременных участников. Вы не напишите хорошее ПО в компании на 1000 человек где нет никакого регулирования, не обеспечите интенсивное автомобильное движение в большом мегаполисе, не поставив светофоры и не разграничив парковочные зоны, и не запустите ровер на Марс обществом, где нет сложной системы законов и развитых политической и экономической систем. Чем более комплексный результат хотите получить, тем больше сложных правил и ограничений нужно устанавливать, тем сильнее регулировать коллектив. Чем меньше культура и уровень образования коллектива соответствует выбранной методологии, своду пдд или законам политического устройства, тем сложнее будет внедрить все это в коллектив. Нельзя просто так взять и построить завод по производству сложной электроники там, где единственным законом было «право сильного», в все образование заключалось в том, как ловить рыбу и изготавливать луки и копья. Нужно поколениями менять систему образования, культуру.
Скрам — сложная система менеджмента, для которой нужен определенный уровень образованности и культуры компании/коллектива, чтоб участники вообще могли строго следовать прописанным правилам. Координация и предсказуемость требуют большого числа ограничений. Если коллектив токсичен, уровень менеджмента примерно соответствует «я начальник — ты дурак, делай как сказали», исполнители читают требования после того, как закрывают задачи, никто не умеет собирать и описывать эти самые требования, то смысла от этой сложной системы никакого. Проще и быстрее работать так, как коллектив работал до этого.
Проблема в менеджменте и в культуре в целом, а не в методологиях.
Главная проблема хорошего менеджмента это то что он слишком сложный для большинства менеджеров. И слишком непривычный для остальных. Из-за этого берут 30% фреймворка, игнорируют всё что не нравится, потом внедряют через одно место и через полгода жалуются.
Agile — принципы, ценности.
Scrum — менеджерский фреймверк для удовлетворения этих ценностей. Список правил, иструкция. Скрам — это серьезный менеджмент, который требует исполнительности и точности на всех уровнях команды. Если кто-то игнорирует — сыпется все. Если команда строго следует инструкции — она делает продукт соотвествующий требованиям заказчика быстро и качественно. Ценой ограничения свободы членов команды (см менеджмент, sdlc).
Нет плохих бояр, бывают плохие цари.
Линус, к счастью, неплохой царь. То, что он не начал в угоду жителям Хабра направо и налево жечь едкими шутками неугодных цветных или сексуальные меньшинства, это наоборот говорит о Линусе как о дальновидном и грамотном лидере. В ядре важнее архитектура, технологии, комьюнити, которые все это дело будут поддерживать, а не детские комплексы или особенности местечковых культурных особенностей. Линус прекрасно осознает все это и не дает собственному эго все испортить.
Ближайшее будущее будет пестрить рассовыми/половыми/экзистенциальными конфликтами. К счастью, Линус стал зрелым лидер, в полной мере осознающий, в какую сторону «ветер дует». Он смог усмирить собственное эго ради дальнейшего развития своего детища. Это и есть главная характеристика настоящего лидера — умение поставить общую высокую цель выше хотелок собственного эго. Для эволюции Linux важнее процессы, выбор принципов, технологий и здоровье комьюнити, а не нейминг переменных или веток в гите. Идя навстречу трендам и адаптируясь под современную культуру, Линус оберегает будущее разработки ядра. Лезть в конфликты по бестолковым непринципиальным вопросам — тратить силы и время на то, что не принесет пользы. Приняв неизбежное и сконцентрировав усилие на построении комьюнити, процессах и качестве разработки, можно достичь куда большего.
Нужно уточнить требования у заказчика, узнать цену, которую он готов заплатить, сроки поставки.
Если заказчик хочет красиво, но на завтра, а денег у него только на ржавый таз обвешанный тюнингом, то верхом глупости будет выделять на заказ ресурсов как на Бентли. Или вообще брать этот заказ.
Продукт — это (условно) код, удовлетворяющий требованиям заказчика.
PM — это тот, кто организовывает процессы утверждения требований и контроля соответствия кода этим самым требованиям.
Вы можете как угодно красиво с блэкджеком и графиками показывать заказчику код, но он собака все равно просит, чтоб код удовлетворял указанным требованиям.
Потому, первоочередная задача PM — мешать разработчику писать быстрый красивый ненужный код. В том числе созвонами.
Опять же, 10 лет в компании могут быть в одной должности, а могут от зеленого джуна, до технического директора.
Небольшая текучка — хорошо.
Сочетание du у нейтивов часто произносится как «джу»
gradually, education
Похожее, но встречается гораздо чаще:
said — сэд (а не сэйд)
says — сэз (а не сэйз)
За любые проблемы в коллективе отвечает начальник. Поэтому начальник должен узнавать о любых проблемах первым. У него скорее всего более широкое видение ситуации.
Например, вам не нравится, как кто-то выполняет свои обязанности. Вы можете высказать недовольство прямо этому сотруднику. Но может оказаться так, что сотрудник не виноват, ему дали неверную информацию, неправильно организовали его работу, или взяли его по ошибке. Не обладая полной информацией(а в большой компании вы скорее всего не будете обладать всей нужной для понимания ситуации информацией), вы испортите настроение и себе и тому человеку. Возможный конфликт может испортить настроение всей команде, помешать работе. В конце концов за это пострадает как раз начальник.
Поэтому, «там» сообщают о проблема непосредственно начальнику. А он уже смотрит как ее решить с минимальными потерями для коллектива и рабочих процессов.
Не в том дело.
История сама по себе слишком неправдоподобна. Либо автор сознательно исказил факты, чтоб подать историю в выгодном ему свете, либо он не осознал до конца происходящее, либо все это от начала и до конца выдумка. Мои американцы склоняются к тому, что это выдумка.
Конечно, без расстановки приоритетов показаниями метрик бы просто подтирались каждую итерацию.
Вот это та самая ключевая мера, которая может решить большую часть проблем в любой разработке. Хвала вашему менеджменту, который осилил приоритеты. Не смог бы — все эти метрики, налаживание процессов, вовлеченность, оценка — все коту под хвост. Я видел массу примеров, когда даже слабые тех команды с хиленькими процессами при хорошем проектном менеджменте, который умел фокусироваться на приоритетах, показывали крутой результат, а крутые команды из топовых спецов шли на дно, когда менеджмент не мог элементарно определиться, что же продукту важнее.