Ничего страшного, мы можем остаться несогласными. Но руководствоваться убеждением «я не представляю как это может быть и поэтому этого не может быть» — означает потерять интересные возможности. По-крайней мере стоит прочитать Фредерика Лалу чтобы общаться дальше.
Всё верно, я хочу совсем другого. Не могу не отметить, что описанная вами динамика корпоративной культуры — гипотетическая. Но, пожалуй, вполне возможная. Так же как и возможна другая динамика — формирование коллектива, который искренне верит в миссию компании. По поводу основной задачи тоже хотелось бы отметить, что не стоит делать выбор за основателя — компания ради денег или деньги ради миссии компании. В конце концов, любой здравомыслящий человек, основывая компанию должен понимать — а для чего деньги-то? Есть еда, дом, машина, отдыхаю на морях периодически, 20 яхт мне не надо. Что дальше? И тут возникают потребности гораздо более интересные чем финансовый успех.
Суть бирюзовой организации в одном комментарии не раскрыть, но я все таки немного дополню свой ответ.
Доверие в бирюзовой организации есть изначально т.к. каждый принимает общую цель и следует ей. Других людей коллектив просто выдавит из себя. В такой ситуации, если сроки не удалось выдержать — значит на то были объективные причины и это повод для того чтобы помочь или перенести сроки.
А подразумеваемый вами процесс поиска виноватых и вытекающая из этого агрессия — это удел нынешних коммерческих организаций, держащихся скорее на внутренней конкуренции нежели на сотрудничестве.
Можно и так посмотреть.
Но можно вспомнить притчу о каменотесах.
Работник обрабатывает камни или строит храм? Приятнее работать, если строить храм. Но можно и посмотреть как Вы — работник обрабатывает камни чтобы построить храм. Короче говоря ответы на вопросы «что?» и «зачем?» зависят от того на сколько общую картину вы можете видеть. Или я бы даже сказал — на сколько общую картину вам позволяют видеть.
И да, фокусировка и орг структура — независимые аспекты.
Когда-то было в порядке вещей бить жену. Сейчас это, как минимум, противозаконно. Времена меняются, мужчине приходится приспосабливаться или он остаётся без жены. Хотя изменения идут медленно, да и некоторые жены сами не против чтобы их били. Все таки ничего другого они не видели.
Если тема корпоративной культуры еще интересна, то очень рекомендую Эдгара Шейна «Организационная культура и лидерство». Он очень хорошо раскрывает и её суть и динамику.
На самом деле, я действительно потихоньку подбираюсь к тому, чтобы создать бирюзовую организацию. Может быть я наконец узнаю, что я витаю в облаках, а может что у меня критичесая несостоятельность в чем-то. Но может и наоборот — подтвердит мои мысли. Кто знает?
Если в Томске есть люди, заинтересованные в создании бирюзовой организации, я бы с удовольствием скооперировался. В этой теме довольно тяжело найти единомышленников.
Так что — последую совету Романа Кх.
У меня не было опыта работы в компании с децентрализованной властью, штат которой превышал бы 100 человек. Но Фредерик Лалу описывает компании значительно превышающие такой штат и при этом не испытывающие указанных вами проблем:
Теряется фокус
Есть предназначение, ценности, цели. Он как раз появляется.
появляются избыточные коммуникации
Петля обратной связи, используемая для адаптации, решает эту проблему.
Снижается возможность принимать рискованные решения.
Полагаю, у вас есть опыт или знания? Или вы предполагаете?
Не стоит обсуждать децентрализацию в отрыве от других факторов (адаптация, сотрудничество, фокусировка). Полагаю, что в отрыве от других факторов она просто не работает.
Данная статья об исследовании и о выводах, почему не заработал скрам. Не более того.
Она не об изменениях, которые я внедряю и она не описывает наличия или отсутствия прогресса.
Но я вас узнал, здравствуйте. Пора меняться, иначе останемся посредственной компанией с посредственными сотрудниками и посредственными руководителями. И я сделаю для этого всё что в моих силах.
Отчасти верно. Строительство дома это, конечно, интересная аналогия, но не полностью подходящая к разработке ПО.
Во-первых, в разработке ПО есть такое понятие как гибкость.
Во-вторых, заказчик всегда меняет требования, а agile лишь явно говорит «это неизбежно, будь готов!».
И опять таки agile не имеет отношения к костылями и качеству продукта. Он не противоречит качеству кода никак. Он просто позволяет делать качественный продукт в условиях неопределенности.
Так, не теряем нить беседы. Вы сказали — agile для быстрого создания продукта на костылях. Я сказал, что дело не в agile.
Далее вы пишете
Делать все по уму долго и, к тому времени как закончите, продукт может быть уже не востребован или все сливки соберет конкурент. Первая версия продукта — это костыль на костыле и костылем погоняет, но приносит деньги. Потом, когда все грабли найдены, продукт переписывают уже с учетом их.
Agile не упоминается.
Далее пишете еще предложение никак не аргументирующее ваше первое сообщение.
Я пока не понял почему вы писали, что agile для быстрого накастыливания? Я связи не вижу совсем. Прототип на выкидывание можно и по каскадной модели разработать.
Я считаю, что agile это как раз инструмент, который позволяет поддерживать качество продукта на высоком уровне т.к. позволяет, хотя бы благодаря тем же ретроспективам, увидеть проблему, донести ее до заинтересованных лиц и принять решение по ее исправлению. Но с другой стороны и в каскадной модели это может быть сделано… но обычно в водопаде не проводятся регулярные ретроспективы и потому отдача технического долга становится индивидуальной ответственностью, а не системой.
Доверие в бирюзовой организации есть изначально т.к. каждый принимает общую цель и следует ей. Других людей коллектив просто выдавит из себя. В такой ситуации, если сроки не удалось выдержать — значит на то были объективные причины и это повод для того чтобы помочь или перенести сроки.
А подразумеваемый вами процесс поиска виноватых и вытекающая из этого агрессия — это удел нынешних коммерческих организаций, держащихся скорее на внутренней конкуренции нежели на сотрудничестве.
youtu.be/scqp1RhHlEI
Там человек, в том числе, рассказал как проявились эти конфликты и как они решились.
Но можно вспомнить притчу о каменотесах.
Работник обрабатывает камни или строит храм? Приятнее работать, если строить храм. Но можно и посмотреть как Вы — работник обрабатывает камни чтобы построить храм. Короче говоря ответы на вопросы «что?» и «зачем?» зависят от того на сколько общую картину вы можете видеть. Или я бы даже сказал — на сколько общую картину вам позволяют видеть.
И да, фокусировка и орг структура — независимые аспекты.
Если в Томске есть люди, заинтересованные в создании бирюзовой организации, я бы с удовольствием скооперировался. В этой теме довольно тяжело найти единомышленников.
Так что — последую совету Романа Кх.
Есть предназначение, ценности, цели. Он как раз появляется.
Петля обратной связи, используемая для адаптации, решает эту проблему.
Полагаю, у вас есть опыт или знания? Или вы предполагаете?
Не стоит обсуждать децентрализацию в отрыве от других факторов (адаптация, сотрудничество, фокусировка). Полагаю, что в отрыве от других факторов она просто не работает.
Она не об изменениях, которые я внедряю и она не описывает наличия или отсутствия прогресса.
Но я вас узнал, здравствуйте. Пора меняться, иначе останемся посредственной компанией с посредственными сотрудниками и посредственными руководителями. И я сделаю для этого всё что в моих силах.
Во-первых, в разработке ПО есть такое понятие как гибкость.
Во-вторых, заказчик всегда меняет требования, а agile лишь явно говорит «это неизбежно, будь готов!».
И опять таки agile не имеет отношения к костылями и качеству продукта. Он не противоречит качеству кода никак. Он просто позволяет делать качественный продукт в условиях неопределенности.
Agile не означает отсутствие стратегического плана и беспорядочную работу.
Далее вы пишете
Agile не упоминается.
Далее пишете еще предложение никак не аргументирующее ваше первое сообщение.
Я пока не понял почему вы писали, что agile для быстрого накастыливания? Я связи не вижу совсем. Прототип на выкидывание можно и по каскадной модели разработать.
Я считаю, что agile это как раз инструмент, который позволяет поддерживать качество продукта на высоком уровне т.к. позволяет, хотя бы благодаря тем же ретроспективам, увидеть проблему, донести ее до заинтересованных лиц и принять решение по ее исправлению. Но с другой стороны и в каскадной модели это может быть сделано… но обычно в водопаде не проводятся регулярные ретроспективы и потому отдача технического долга становится индивидуальной ответственностью, а не системой.