С разработчиками, ведущими деятельность в РФ, это решается. Например, путем создания агента (по типу авторского общества) с законодательной обязанностью разработчику передать право лицензирования и получать деньги по общему числу лицензий при непубличности конечных лицензиатов. А агенту - предоставить лицензию любому, чья деятельность соотв. законодательству. Все равно происходящее в этой сфере свободным рынком уже не кажется.
Это один из способов борьбы с недоверием. В 90-е доверие вообще было как мишень для приколов в самом мягком случае. С обеих сторон очевидно. Менеджеры не доверяют, потому что сами осознать предлагаемые решения неспособны, а команды (тут скорее о лидах речь) не слишком напрягаются в попытках свои решения объяснить, показать не просто отдельный случай, а хотя бы инженерный план достижения цели . Команды не доверяют, потому что могут прийти и сказать "сворачивайте ваши Иксперименты и развитие и делайте кондово и бегом".
А тут еще разработка, которая помимо производства софта еще и конструирование содержит и элементы НИОКР. И получается, что на цикл ОКР-конструирование-производство менеджеры 2-3 слоев и команды натягивают гибкие процессы. Сложность растет быстрее компетенций и тех и других. Пока проект небольшой, разбираются. В энтерпрайзе под это дело уже весь управленческий состав до тим-лидов включительно нужно очень серьезно готовить. Одних цели формулировать и управлять их изменениями не "а сегодня начинам жить по новому", других выстраивать процессы, третьих создавать и изменять решения достижения этих целей. Взаимное доверие только за счет взаимной уверенности в профессионализме может появиться. И один "случайно залетевший в систему" менеджер его легко может порушить. А это частый случай, вот и тянутся все к модели нулевого доверия.
Не обязательно к IT-компании. Большой поток налички может привлечь, участие в обнале, вряд ли их можно прятать без "попустительства" определенных органов. Хотя, некоторые интернет-магазины торгуют же за нал дорогой техникой с приличными скидками.
Ген.дир в эту команду должен быть из мира «розовых пони», где ресурсы нахаляву выдаются.
Отвечать за фин.показатели почти не имея инструментов влияния и рассчитывая, что ресурсов почему-то всегда будет хватать.
Проблема в доверии.
С суперсовременными технологиями в 40+ проблем нет.
А вот с неуверенностью в 30, что сможет командовать опытным работником за 40 есть проблемы.
С молодёжью проще — вытащил один раз из «дедлайн… цы» и авторитет какой — никакой.
И это еще про эксплуатацию микросервисных решений никто не пожаловался. Когда выясняется, что большая часть команды разработки о проблемах продакшна не особо задумывается — сети, доступы, авторизации, разброс характеристик всего что только используется и т.п. часто живут в идеальном мире до развертывания в прод.
И анализ небанального сбоя при участии архитекторов и тим-лидов, которым надо бросить все и отвлечься/скоординироваться/договориться тоже «радующая» всех процедура.
Мемчик веселый…
Главные библиотеки проекта — справедливость и равенство. Их выпестовали и их же деградация и привела к уничтожению. Уничтожив одно классовое общество за полвека собрали новое из номенклатуры, которой не нужны были ни справедливость, ни равенство со всем обществом.
Из этого развалилась генеральная линия и не стало ценностной основы труда на благо всего общества в любой его форме. Как нет и сейчас.
Автору вообще жирный плюс за взгляд на проблему.
Отрасли давно пора взрослеть и самой себе задавать вопрос за счет чего она живёт. И понимать свою экономику не в мире почти бесплатных денег, когда Uber может потрать на 8.6 миллиарда больше чем вырученные 14.16, а в мире где на твои потери кто-то должен заработать.
Тем более, что отрасль принесла миру социальную инженерию как инструмент управления самого высокого уровня.
Спорным мне кажется следующее:
«Когда работает Agile»
1. Для индивидуальных продуктов гибкость не нужна, нужны традиционный менеджмент и водопад.
Строгая последовательность критически нужна только при создании продуктов с неприемлемыми рисками эксплуатации, для нас это системы управления жизнеобеспечением и опасными техническими объектами и т.п.
В остальных случаях даже скрупулезно зафиксированные требования к продукту не слишком-то и эффективно достигать водопадом, поскольку риск попасть в изменяющуюся среду ненулевой. В том, что многие могут похвастаться постоянной работой на основе таких требований, я тоже не уверен.
Кроме того, даже если ваш продукт делается внутри для себя и вроде бы все можно узнать (но это не точно в 9X% случаев :) ), процессы для которых он предназначен, тоже меняются на ходу. В клинических случаях даже не сами процессы, а качество их модели в головах их исполнителей и владельцев. Есть ощущение, что в нашей отрасли водопад придает уверенности «излишне доверчивым» менеджерам и на этом его плюсы заканчиваются.
2. Экономика продукта выглядит уж очень упрощенно. Из прошлой статьи следует, что результат в виде прибыли получается по модели:
«применяем венчурный капитал -> вовлекаем человека, а не работника -> повышается ценность продукта -> расширяется рынок -> имеем результат».
И в каждой операции сталкиваемся с ограничениями. Более-менее логично можно обсуждать 2 из них:
— «расширяется рынок». Рынок всегда ограничен спросом. И по А.Смиту и по К.Марксу и по многим другим. Спрос всегда конечен, хотя мы и живем в расширяющейся вселенной, получить в обмен больше, чем есть у потребителя, мы не сможем.
— печально, но из этого следует, что и повышение ценности продукта ограничено.
Отсюда следует потребность в балансировании входных ресурсов и результата. И тут венчурный капитал in the wild становится злом, так как его цель перераспределить результат (часть спроса) в сторону своего продукта, то есть отняв его у кого-то еще. Социально-экономическая система расбалансируется, так как чтобы программист получал свое растущее вознаграждение, нужно, чтобы спрос, из которого оно формируется, был изъят у другой отрасли в системе, например у производителей продуктов питания. Что, в общем-то, несправедливо. Либо система должна расширяться за чей-то ещё счет, но опять планетарное ограничение никто не отменил, грабить уже некого.
И тогда логично, вовлеченность массово должна стать не экономической, а ценностной. То есть совершенствование с целью принесение пользы должны стать смыслом деятельности, это последний резерв развития экономики и основанного на ней общества. Слабо?
Незаметно получился «возврат к классикам», даже нового в комментарии не придумывается.
Поэтому идея разделять применимость Agile, базируясь на экономической основе, противоречит экономической логике. Как и виртуальность продуктов можно оставить для экономики эмоций, а не реальности.
«Как именно работает Agile»
3. Ценности. С т.з. результата через расширение не получилось, но экономить ресурсы ценности помогают в любом продукте.
4. Принципы. Увеличение цены продукта ограничено. Вовлеченность тоже, кроме ценностного. Техническая и материальная стороны продукта ограничены пределом спроса.
«Насущные вопросы»
5. Если исходить из желания совершенствоваться, то построить Agile снизу, очевидно можно. Сложно, что также очевидно. Получить команду, которая желает стать лучше сама по себе, чтобы приносить больше пользы, это большая радость. Но есть www.youtube.com/watch?v=-__m1hHb75A и далее www.youtube.com/watch?v=vxkm083j2AE. В корпоративе сложнее, чем в рыночном продукте, так как влияние продукта на результат сильно модерируется остальной деятельностью.
6. Злобный энтерпрайз, канбан. Дружат в обнимку. Корпоратив умеет считать результат по всей цепочке (иначе он не жилец), канбан приносит хотя бы минимально ценный продукт. Что согласуется с результатом всей модели стоимости.
Следуя такой логике вы превращаете модель в систему управления, переводя ее в субъект деятельности. Модель в принципе нелогично делать ни субъектом, ни объектом, хотя это требуется для каких-нибудь строгих выводов.
Возвращаясь к превращению в субъект — это в изрядной доле противоречит цели в п.1 — для организации… надо построить модель. Тут либо терминология изобретена заново и под моделью/средой понимается система управления, либо произведена свертка понятий.
Любопытно. Но путано в итогах. Вы среду (как модель) хотите построить (п.1 итогов) или организовать (п.3)? Зачем среде уметь противостоять внешним вызовам, вы же её декларируете как модель? И далее.
И Hashicorp тоже прикупили
С разработчиками, ведущими деятельность в РФ, это решается. Например, путем создания агента (по типу авторского общества) с законодательной обязанностью разработчику передать право лицензирования и получать деньги по общему числу лицензий при непубличности конечных лицензиатов. А агенту - предоставить лицензию любому, чья деятельность соотв. законодательству. Все равно происходящее в этой сфере свободным рынком уже не кажется.
Это один из способов борьбы с недоверием. В 90-е доверие вообще было как мишень для приколов в самом мягком случае.
С обеих сторон очевидно. Менеджеры не доверяют, потому что сами осознать предлагаемые решения неспособны, а команды (тут скорее о лидах речь) не слишком напрягаются в попытках свои решения объяснить, показать не просто отдельный случай, а хотя бы инженерный план достижения цели . Команды не доверяют, потому что могут прийти и сказать "сворачивайте ваши Иксперименты и развитие и делайте кондово и бегом".
А тут еще разработка, которая помимо производства софта еще и конструирование содержит и элементы НИОКР. И получается, что на цикл ОКР-конструирование-производство менеджеры 2-3 слоев и команды натягивают гибкие процессы. Сложность растет быстрее компетенций и тех и других. Пока проект небольшой, разбираются. В энтерпрайзе под это дело уже весь управленческий состав до тим-лидов включительно нужно очень серьезно готовить. Одних цели формулировать и управлять их изменениями не "а сегодня начинам жить по новому", других выстраивать процессы, третьих создавать и изменять решения достижения этих целей. Взаимное доверие только за счет взаимной уверенности в профессионализме может появиться. И один "случайно залетевший в систему" менеджер его легко может порушить. А это частый случай, вот и тянутся все к модели нулевого доверия.
Не обязательно к IT-компании. Большой поток налички может привлечь, участие в обнале, вряд ли их можно прятать без "попустительства" определенных органов. Хотя, некоторые интернет-магазины торгуют же за нал дорогой техникой с приличными скидками.
Отвечать за фин.показатели почти не имея инструментов влияния и рассчитывая, что ресурсов почему-то всегда будет хватать.
С суперсовременными технологиями в 40+ проблем нет.
А вот с неуверенностью в 30, что сможет командовать опытным работником за 40 есть проблемы.
С молодёжью проще — вытащил один раз из «дедлайн… цы» и авторитет какой — никакой.
И анализ небанального сбоя при участии архитекторов и тим-лидов, которым надо бросить все и отвлечься/скоординироваться/договориться тоже «радующая» всех процедура.
Главные библиотеки проекта — справедливость и равенство. Их выпестовали и их же деградация и привела к уничтожению. Уничтожив одно классовое общество за полвека собрали новое из номенклатуры, которой не нужны были ни справедливость, ни равенство со всем обществом.
Из этого развалилась генеральная линия и не стало ценностной основы труда на благо всего общества в любой его форме. Как нет и сейчас.
Автору вообще жирный плюс за взгляд на проблему.
Отрасли давно пора взрослеть и самой себе задавать вопрос за счет чего она живёт. И понимать свою экономику не в мире почти бесплатных денег, когда Uber может потрать на 8.6 миллиарда больше чем вырученные 14.16, а в мире где на твои потери кто-то должен заработать.
Тем более, что отрасль принесла миру социальную инженерию как инструмент управления самого высокого уровня.
Спорным мне кажется следующее:
«Когда работает Agile»
1. Для индивидуальных продуктов гибкость не нужна, нужны традиционный менеджмент и водопад.
Строгая последовательность критически нужна только при создании продуктов с неприемлемыми рисками эксплуатации, для нас это системы управления жизнеобеспечением и опасными техническими объектами и т.п.
В остальных случаях даже скрупулезно зафиксированные требования к продукту не слишком-то и эффективно достигать водопадом, поскольку риск попасть в изменяющуюся среду ненулевой. В том, что многие могут похвастаться постоянной работой на основе таких требований, я тоже не уверен.
Кроме того, даже если ваш продукт делается внутри для себя и вроде бы все можно узнать (но это не точно в 9X% случаев :) ), процессы для которых он предназначен, тоже меняются на ходу. В клинических случаях даже не сами процессы, а качество их модели в головах их исполнителей и владельцев. Есть ощущение, что в нашей отрасли водопад придает уверенности «излишне доверчивым» менеджерам и на этом его плюсы заканчиваются.
2. Экономика продукта выглядит уж очень упрощенно. Из прошлой статьи следует, что результат в виде прибыли получается по модели:
«применяем венчурный капитал -> вовлекаем человека, а не работника -> повышается ценность продукта -> расширяется рынок -> имеем результат».
И в каждой операции сталкиваемся с ограничениями. Более-менее логично можно обсуждать 2 из них:
— «расширяется рынок». Рынок всегда ограничен спросом. И по А.Смиту и по К.Марксу и по многим другим. Спрос всегда конечен, хотя мы и живем в расширяющейся вселенной, получить в обмен больше, чем есть у потребителя, мы не сможем.
— печально, но из этого следует, что и повышение ценности продукта ограничено.
Отсюда следует потребность в балансировании входных ресурсов и результата. И тут венчурный капитал in the wild становится злом, так как его цель перераспределить результат (часть спроса) в сторону своего продукта, то есть отняв его у кого-то еще. Социально-экономическая система расбалансируется, так как чтобы программист получал свое растущее вознаграждение, нужно, чтобы спрос, из которого оно формируется, был изъят у другой отрасли в системе, например у производителей продуктов питания. Что, в общем-то, несправедливо. Либо система должна расширяться за чей-то ещё счет, но опять планетарное ограничение никто не отменил, грабить уже некого.
И тогда логично, вовлеченность массово должна стать не экономической, а ценностной. То есть совершенствование с целью принесение пользы должны стать смыслом деятельности, это последний резерв развития экономики и основанного на ней общества. Слабо?
Незаметно получился «возврат к классикам», даже нового в комментарии не придумывается.
Поэтому идея разделять применимость Agile, базируясь на экономической основе, противоречит экономической логике. Как и виртуальность продуктов можно оставить для экономики эмоций, а не реальности.
«Как именно работает Agile»
3. Ценности. С т.з. результата через расширение не получилось, но экономить ресурсы ценности помогают в любом продукте.
4. Принципы. Увеличение цены продукта ограничено. Вовлеченность тоже, кроме ценностного. Техническая и материальная стороны продукта ограничены пределом спроса.
«Насущные вопросы»
5. Если исходить из желания совершенствоваться, то построить Agile снизу, очевидно можно. Сложно, что также очевидно. Получить команду, которая желает стать лучше сама по себе, чтобы приносить больше пользы, это большая радость. Но есть www.youtube.com/watch?v=-__m1hHb75A и далее www.youtube.com/watch?v=vxkm083j2AE. В корпоративе сложнее, чем в рыночном продукте, так как влияние продукта на результат сильно модерируется остальной деятельностью.
6. Злобный энтерпрайз, канбан. Дружат в обнимку. Корпоратив умеет считать результат по всей цепочке (иначе он не жилец), канбан приносит хотя бы минимально ценный продукт. Что согласуется с результатом всей модели стоимости.
В общем автору спасибо за тему, удачи!
Возвращаясь к превращению в субъект — это в изрядной доле противоречит цели в п.1 — для организации… надо построить модель. Тут либо терминология изобретена заново и под моделью/средой понимается система управления, либо произведена свертка понятий.