Сотрудничество по словарю Ожогова (http://enc-dic.com/ozhegov/Sotrudnichat-33458.html)
«Работать, действовать вместе, принимать участие в общем деле.»
Об равноправии отношений ничего не сказано. Да, кстати, пойдите к своему босу или заказчику
и скажите, что отношения должны быть равноправными и сегодня вы им будете выдавать задачи, а они их исполнять… поглядим как пройдет у вас этот ход.

Благодарю
У меня есть блог, но пока в нём только одна запись
Действительно, когда мне есть, что сказать, коменты получаются на целый пост. И я уже давно подумываю собрать написанные коменты в ряд постов по ключевым темам в ИТ.

Я тоже играю ГО. Но пока тренируюсь на боте и так и не понимаю, как дойти до 4-ого кю в игре с ботом. Иногда я его просто обыгрываю, потому что в программе бота есть слабости анализа ситуаций и общих стратегий без деталей, особенно, когда действия максимально удалены на поле друг от друга, и когда уже поздно и бот упустил момент, стратегия начинает приобретать видимую на поле картинку.

Да, я согласен, что одним простым предложением передать всю глубину значения невозможно, если предложение отделено от контекста. Я всего лишь задал контекст предложению, в котором не стал расписывать более понятные нам обоим детали, чтобы не уйти в бесконечную детализацию Это как раз тот случай, когда говоря одно и то же, можно понимать разные вещи. И тогда, действительно, проще говорить «цели профессионалов лучше кореллирую с бизнесом», обозначая описанный контекст.

Мир сложен лишь тогда, когда мы не знаем его принципов, которые действуют независимо от уровней иерархии, нашего восприятия и наших желаний.

В вашем описании разбиения мне показалось, что есть иерархия. Если я прав насчёт иерархии, будет интересно следующее насчёт анализа ситуаций путём разбиений и построении иерархий.
Уже 5 лет я занимаюсь одной специфической проблемой, которая напрямую связана с механизмами мышления и работы языка (как естестественного, так и искусственного).
Для начала, прошу обратить внимание на 3 важных момента, которые большинство считает естественными:
1. человеку несколько тысяч лет насаждают социальную иерархию.
2. человек всегда стремиться вписать новое в структуры, уже известные ему.
3. все иерархии используют отношение принадлежности рекурсивно.

Задайтесь вопросом, зачем нужна принадлежность и социальная иерархия в условиях рабовладельческого строя (мечом или долгом) и как достичь такого мышления у человека.
Плюс, к этому очень много «научных моделей», использующих иерархию в силу кажущейся простоты и желанию простоты.
Сейчас я дам ряд утверждений, к которым пришёл самостоятельно, исследуя механизмы языка и мышления, которые по началу вызывают внутреннее сопротивление и отрицание, но если подумать и попробовать поступать по-другому, получается намного легче и проще благодаря большему соответствию реальным системам, и, главное – без конфликтов описания.
1. отношение принадлежности – ложное отношение, его не существует в реальных системах.
2. иерархий не существует, это иллюзия, ошибочно призванная упростить описание и потакать присущему многим желанию простоты, которая всегда сталкивается с неразрешимыми конфиликтами на реальных системах в силу своего несоответствия информационным законам: невозможно отношением принадлежности представить качественно иные отношения.
3. отношение наследования/обобщения не существует – это ложное отношение, в силу образующего его отношения принадлежности.

А что же тогда позволяет описывать любые системы? Отношения, которые могут проявляться между любыми отношениями. Отношения, которые выражют качества, присущие наблюдаемому отношению между другими отношениями. Качество – это тоже отношение и качество не принадлежит никакому из отношений, но может проявляться в отношении между n-кой других отношений. Простой пример: копать можно лопатой, можно ножом, можно палкой. Копать бетон палкой можно, пока он сырой. Значит, качество копать не принадлежит ни лопате, ни палке, ни ножу. Аналогично для всех других качеств. Есть ещё множество других приёмов, например, ролевой приём, приём совмещения ролей, приём назначения исполнителей на роли, приём рекурсии отношений и т.д.

Всё это я к тому, что действительно, двигаться можно в обе стороны: детализируя 1-арное отношение на несколько отношений или объединяя несколько отношений в одно и давая ему идентификатор. И количество таких комбинаций зависит от описываемой системы. Простота заключается в том, что все особенности уровня системы и взаимодействующей с ней другой системы являются следствием внутренних особенностей системы и больше ни от чего не зависят.

Используя эти приёмы, в большинстве случаев я сталкивался с конечными отношениями, т.е. мог перечислить всех участников отношения. Так было и при написании предыдущего комментария

>мы сойдемся по огромному числу пунктов во мнениях

Сейчас часто используют механизм свободы мнений. И это серьёзная ловушка и приём софистики. То что я написал, не является моим мнением. Вообще, странно иметь мнение, когда вещи, которые «выражает мнение», никак не зависят от мнения. Это как если бы кто-то говорил, что наше Солнце холодное, а кто-то другой – что горячее. При этом процессы на Солнце и распределение температур на нём никак не зависят ни от чьих мненеий, ни от способов описания, а определяются исключительно Солнцем. Поэтому я опиывал то, что наблюдал, видел, проверял и узнавал. Это не договор между торговцем и поставщиком, где цена определяется мнением и потенциальной силой обоих.

Поэтому действительно, критерием сходимости является совпадение в понимании описываемого, и, вероятно да, мы сойдёмся в этом понимании по огромному числу пунктов . Но такое понимание не будет нашим мнением, которое можно разделять/не разделять. Думаю, идеально сформулированных фраз не бывает, всё определяется тем, что ставится им в соответствие говорящим и слушающем, и мы будем убеждаться в том, что ставим одно и тоже

Теперь немножко прыгну в сторону, а потом вернусь к комментированию.
Я очень увлекаюсь игрой в ГО. Забавная такая игра, с простыми правилами, но дико сложной стратегией и тактикой. Точнее даже, с дико сложной стратегией и тактикой, если задаться целью стать сильным игроком.

При обучении, чаще всего делают упрощения. Говорят – угол, более ценен, чем сторона. Когда игрок подрастает, то говорят, угол ценнее в случаях 1, 2, 3. А потом, еще и еще увеличивают детализацию. И на супер профессиональном уровне игроки могут партию разбирать буквально до бесконечности выискивая разные потенциальные комбинации, альтернативные пути, слабые и сильные стороны.

К чем это я? )

Это я к тому, что естественно фраза «цели профессионалов лучше кореллирую с бизнесом» дикое упрощение.

Действительно, первым в голову приходит разбить на IT бизнес и не IT бизнес. Дальше, IT бизнес можно разбить на продуктовый бизнес (в котором чаще стоимость прибыли от работы может очень сильно изменяться) от предоставления услуг (выставляемая цена часа программиста хорошо прижата рынком). Дальше, можно каждую из этих частей дальше подразбивать и найти еще множество параметров.

Но, все таки лучше пытаться слегка все упрощать, иначе мы уйдет в то самое бесконечное обсуждение партии.

Уже, мы задели вопросы кадров, игр, отличии программистов в разных индустриях, процесс разработки, масштабирование и т.п. Я бы сказал, тут сходу на добрых десяток статей.

Причем, бьюсь об заклад, мы сойдемся по огромному числу пунктов во мнениях. Скорее всего просто будем выдергивать не идеально сформулированные фразы и дотачивать их напильником.

Осталось обсудить только один момент: цели профессионалов лучше коррелируют с бизнесом.

Тут нужно пристально рассмотреть структуру компании, её связь с клиентами (рынком), цели её членов и сравнить.
В общем, цели бизнеса – получать деньги за счёт наёмного труда через продажу продукции/услуг компании.
Есть несколько бизнес-моделей, о которых писал Макс Крайнов и Александр Орлов (ну и другие, разумеется).

Когда разработчик выгоден владельцу бизнеса? Когда он приносит доход, который значительно больше, чем его оплата труда: это позволяет снять существенную прибыль в свой карман, которая тем больше, чем меньше оплата труда и больше приносимый доход. И это одно из главных мест, где жадность и желание обосновать своё моржующее положение игнорируют то, что необоходимо для дохода (кадры решают всё), но недостаточно. И тут возникает конфликт: чем профессиональнее разработчик, тем меньше он нуждается в менеджерской опеке и тем больше стоит.

В первом примере возьмём банк.
Цель банка – заставить всех кого можно нести свои денежки, на которые владельцы банка скупают активы без реального труда.
В банке нет таких задач, которые бы были сложнее умножения, сложения и перекладывания из одного места в другое. Банковские положения предписывают кучу правил, которые предназначены направить потоки финансов в сторону центробанков и кредитующих банков, ну и дать возможность проверить, как выполняются предписанные правила. И это уже не имеет никакого отношения к созданию J2EE-продуктов по концепции SOA или продуктовых движков. Единственная незаметная сложность – это масштабы, с которыми любой профессионал легко справится благодаря стандартным подходам, которыми середнячок, обычно, не владеет. Эту сложность часто не замечают, и набирают лояльных людей в угоду себе, полагая, что грамотным управлением справятся с масштабами. Сравните это с тем, когда профессионал учёл масштабы и необходимые для этого действия, что и определяет рукводяющие направления и это сразу конфликтует с пирамидой подчинения в компании. Кого выберет слабый менеджер? Лояльного, а не того, кто может без него обойтись в ключевых вопросах типа «как делать». Ну и для полноты картины, неплохо бы провести опрос на тему кто, когда и почему остаётся после официального завершения рабочего дня и как обстоит вопрос с отпусками и перераспределением графика работы. В основном в банке, как в армии: нужно быть на месте от и до и неважно зачем. При этом сбои всё также случаются, а процесс разработки и не стремится к устранению имеющихся проблем.

Во втором примере возьмём Google, где набирают профессионалов и просто создают им все благоприятные условия для работы и развития, чётко поддерижвая при этом внутреннюю ИТ-культуру.

В третьем примере возьмём Microsoft, где сначала как раз набирали профессионалов и грамотных менеджеров, чётко разделяя их ответственности, а потом туда стали ломиться все, в особенности те, кто привык деньги вымогать, а не зарабатывать. Что нового появилось в их продуктах после 2000 г.? Их действия всё больше стали напоминать войну за потоки денег и вымогание их любой ценой из примитивного пользователя. Чего только стоит лоббирование установки их осей на ноуты до продажи и оплата контента владельцам описаний новостей (при этом новости владелец контента не делает). Остались красивые современные картинки с постоянно ухудшающемся функциональным дизайном и насилием над пользователем.

Также стоит посмотреть правила Ашманова, где чётко показана направленность целей, и как они коррелируют с культурной разработкой и профессионалами. И обратить внимание на тот факт, что либо общаешься, либо думаешь над архитектурой, записывая полученные решения (преимущественно на специальных языках) и пишешь код. Да, чтобы общаться, нужно, чтобы все были в одном месте. А вот чтобы сконцентрироваться, нужно, наоборот, отстраниться от всех желающих пообщаться. Также это хорошо коррелируют с принципом организации параллельных систем: чем больше параллельные процессы общаются между собой, тем больше они превращаются в одни процесс и работают как один процесс, а не как тысяча. Это следует из закона Амдала. Значит разработчики могут вполне иметь удалённые рабочие места, непосредственно будучи подключенными к общей среде, и в назначенные моменты времени своместно проверять достигнутое, чтобы затем на него опираться. И тут возникает принципиальное различие между менеджером и разработчиком: менеджер думает, что если человек сидит на рабочем месте, то он работает и это менеджер может всегда проверить. Хотя единственным критерием является количество завершённых единиц обработки, для чего необходимо представить разрабатываемый продукт контролируемыми единицами обработки (классами и методами, например, а не задачами, как любят менеджеры), и это сразу покажет, кто на самом деле и на сколько задействован в процессе разработки и даёт результат.
Ну и добавить сюда обучение. Середнячок, обычно, не может выполнять обучение другого, в лучшем случае, он может проверить, что тот прошёл обучение (просто потому что сам учиться плохо умеет). Часто для обучения выбирают коммуникационный способ, но забывают при этом, что можно подвести лошадь к воде, но нельзя заставить её пить. Процесс обучения всегда выполняется только обучающемся: чтобы разобраться, нужно дейстовать самому, и объяснения более опытного и знающего нужны только для того, чтобы убедиться, правильно ли всё понял. Опять таки, нужно чётко определить деятельность, когда лекции читать, когда единицы обработки обрабатывать, а не мешать это в одну кучу, заставляя постоянно переключаться.

Из всего этого я делаю вывод, что цели бизнеса далеко не всегда коррелируют с целями профессионалов, в особенности – сделать качественное ПО при помощи качественных, культурных процессов разработки. В этом случае куча менеджеров просто не нужна, т.к. в промышленном процессе разработки контролирующие и управляющие действия определены процессом, его инструментами и участниками, а не менеджером. И да, в этом случае необходимо подключение к процессу такого представителя заказчика, который может объяснить, чего хочет заказчик и описать это при помощи аналитика и архитектора (потому что умеет определять, что вообще можно сделать). И единственное, что здесь нужно распределять и чем управлять, так это обеспечением процесса разработки. Если человек не хочет работать, его не заставишь законными методами. Поэтому всё выше изложенное предполагает, что человек работает, а не забивает.

- Есть люди у которых больше заинтересованы в знаниях и развитии. Их цели лучше коррелируют с бизнесом. Мы называем их профессионалы.

- Есть люди, которые больше заинтересованы в деньгах. Они чаще ищут более легкие пути (чем через знания) их получения и их цели хуже коррелируют с бизнесом. Мы называем их среднячками.

Демократия в среде профессионалов ускоряет развитие. Она же в среде среднячков замедляет развитие.

1 – мне кажестя, вы не совсем полностью поняли изложенную концепцию относительно профессионалов. Середнячки просто хотят денег и понимают, что для этого им нужно делать, что начальник сказал. Профессионалы – люди с ИТ-культурой, и обычно, более высокой социальной, и стали профессионалами именно благодаря культуре, а не деньгам. Это их личный выбор. Ведь деньги ПО не создадут, для этого нужны знания и культура их применения, что и является ценностью для профессионала, которую он и хочет поэтому увеличивать. Это не означает, что им не нужны деньги. Просто их путь не заканчивается на деньгах, но учитывает их, так как просто получая деньги стать профессионалом неовозможно: деньги невозможно непосредственно превратить в знания в собственной голове, для этого нужно учиться, и да, на деньги или свободнодоступные материалы. И деньги для профессионала – скорее побочный эффект от их деятельности и заслуженного статуса, но от этого деньги не теряют для них своего значения. Профессионалы движутся по нескольким целям одновременно с параллельными приоритетами. У них потому деньги, что они профессионалы, а не наоборот. Но если они сделают деньги своей главной целью и путь не будет лежать через развитие, в мире ИТ они быстро превратятся либо в паразита, либо в середнячка, потому что мир ИТ стремительно развивается. Тем более, оптимизировать фиксированный оклад нельзя. Бонусы – палка о двух концах, на каждого действует по-разному, и вообще, лучше без бонусов, потому что на что тогда фиксированный оклад?. Да, в выборе работодателя профессионал вполне может выбрать того, кто предложит больше, а кто-то меньше, но от этого не станет менее профессиональным. Он работает на одинаковом для обоих вариантов уровнях и развивается в выбранных направлениях.

И я не даю оценки середнячкам и профессионалам, кто лучше, кто хуже. Я вего лишь описываю различные принципы достижения разных целей, и, как следствие – всего остального.

1) Насчет того, что среднячки – хотят денег, а профессионалы хотят улучшаться. Я с этим не согласен. И те и другие хотят максимизировать какую-ту функцию. В этой функции у переменных (денег, интересности, улучшений) разные коэффициенты. И для максимизации могут применяться разные методы.

Безусловно, есть какая-то категория людей, функция которых хорошо коррелирует с получением качественного/количественного продукта, который в свою очередь коррелирует с целью бизнеса. И мы таких людей называем профессионалы.

Однако, сказать, что только из-за того, что их функция лучше коррелирует с бизнес целью – они являются лучшим и новым классом людей – нельзя. Даже то, что они применяют менее агрессивные и менее эгоистичные методики – тоже не является однозначным показателем.

Просто, данная среда стала таковой, что такая функция + методы ценятся (получают больше ресурсов – например в виде тех же денег).

Это я все виду к тому, что человеческая база не слишком поменялась. Поменялось окружение и люди (в том числе профессионалы) подстроились под него.

Это хорошо показано в фильмах катастрофах. В случае изменения окружения, вчерашний профессионал с отличной этикой, будет грабить и убивать, чтобы остаться в живых. Сразу оговорюсь – естественно, есть исключения, но в думаю не стоит строить иллюзий о том, что появился новый тип – _человек действительно разумный_.

Конечно, было бы здорово. Ведь так у людей появится осознанный выбор стать лучше или продолжать быть такими же, как наши далёкие предки Я искренне хочу, чтобы помимо изменившихся декораций, изменились и люди.

Александр Орлов и Слава Панкратов сделали сайт, посвящённый проблеме игр в ИТ. И, насколько я знаю, выпустили брошюру по результатам вебинаров. Они рассмотрели 4 возможных варианта стратегии по отношению к игре:
1. играть и прогирать;
2. перевести в свою игру и выиграть;
3. проявить игру;
3. игнорировать.
Очень рекомендую ознакомиться с этими материалами, и особенно – с более чем 30 основными видами игр, стратегий для них, методов обнаружения игр, последствий проигранных игр, также на вебинаре мы обсуждали проблему предотвращения игр (не знаю, есть ли в брошюре). Основная идея – не играйте в напёрстки, эти игры всегда ведут шулеры с превосходящем количеством тузов в рукавах. В общем, не играйте, а живите реальной жизнью, в которой намного больше интересного, чем в вымышленном мире игр

Если я правильно понимаю self empowered team, как команду, которой делегировали полномочия, то думаю, ответ на объявленную тему такой:
1. команды с середнячками, обычно, делают своей целью деньги и это определяет всё их «среднее» поведение. Если деньги гарантированы, значит единственный способ сократить затраты – упростить работу, в том числе и передавая её проигравшим. Им не интересено сделать работу лучше, чем они делали её прошлый раз, им не интересно развиваться и разбираться. Ну и наградить непричастных, наказать невиновных. В большинстве, это цеховые рабочие для станков и конвееров.
2. команды с профессионалами в первую очередь стремятся каждый раз быть лучше, чем в предыдущий, и деньги для них отходят на второй план после согласования суммы, им интересно сделать работу лучше, чем прошлый раз, организованнее и с меньшими затратами, потому что иначе они будут терять квалификацию, т.е. деградировать, что противоречит их направленности на постоянное развитие. В общем, у профессионалов, обычно, имеются нематериальные цели, как у всех интеллектуалов. Это в большей части инженеры и в меньшей – исследователи и открыватели.

Сразу хочу обратить ваше внимание на то, что «дать тягать одело офциально», если я правильно понял, означает узаконить борьбу и возложить на неё ответственность за подбор кадров, т.е. создать искусственную эволюционную среду. В условиях, когда есть разум, естественный отбор не работает, потому что его принципы легко вскрываются (т.е. он осознаваем), и поэтому оцениваемый середнячок сразу начинает работать на оценку, а не на достижение целей проекта, что отлично промоделировано Эльдаром в «Джек Велч, кривая колокольчика или некоторые тонкости в реализации социал-дарвинизма», который показывает к каким проблемам в действительности приводит эволюционная среда (ревью, оценки, обязательное наказание и т.д.) и что она, наоброт, делает невозможным построение эффективной команды профессионалов, способной решать задачи в условиях меняющегося рынка, для чего необходимо не зависеть от предметной области и уметь быстро разибраться (ну, конечно, не в научных и сложных инженерных областях, где необходимы учёные, высшее образование и специальное обучение с введением в курс дела). Ну и тему корпоративных паразитов в целом тоже к озвученной проблеме очень полезно изучить

Вообще, к общей теме кадров….
Бизнес так жалуется, что не хватает профессиональных кадров. Но ведь бизнес сам хочет брать готовое решение-человека/команду, который уже знает, как решать их задачи и уже всё умеет. Так не бывает. Откуда такие люди возьмутся, если не будут решать задачи бизнеса? И зачем человеку решать одну и ту же задачу несколько раз? Вот и получается, что в итоге качество кадров падает, увеличивая в итоге в разы затраты бизнеса из-за неффективной работы кадров (профессионал в 5-10 раз лучше середнячка, что напрямую определяет затраты).
Создание ПО, это создание завода/конвеера/проекта станка (потому что сам станок делается сборкой кода и копированием, а ставится в производственную линию развёртыванием ПО), а значит, новый станок – это каждый раз новая проблема. Поэтому ключевым в данном вопросе явлется умение разбираться, осваивать новое и решать инженерные задачи, а не уметь в совершенстве винтить гайки и выполнять одинаковые операции на конвеере цеховым рабочим.
Для профессионала, обычно, не нужно разбираться годами в новом инструменте и уж тем более годами тренироваться пользоваться его функциями, просто потому что он сам создаёт инструменты. Он просто берёт его, читает инструкцию и использует (сужу по себе, хотя, может быть, ошибочно предполагать это для всех). Это касается всего: языков программирования, библиотек, сред разработки, сред организации работы (BTS, VCS, и т.д.). Что действительно требует времени (у меня больше месяца пока не уходило), так это разобраться в новой для себя технологии, подходе или парадигме. Обычно на это у меня уходит 3-5 дней. И это делается один раз и на всю жизнь, прям как научиться кататься на велосипеде. Вот это действительно требует усилий, но конечных. Почему-то бизнесА думают, что новое название влечёт новые качества. В ИТ это не так. Есть несколько классов языков, поняв парадигмы которых, можно просто брать и использовать язык конкретного класса. И всё умение заключается в глубоком понимании парадигмы и базовых принципов с умением выбора эффективных средств выражения. Например, парадигма обмена сообщениями и парадигма событий одинаковая для WinAPI и J2EE, Oracle Databse Advanced Queueing. Да, у них есть у каждого свои уникальные особенности, которые в целом ничего не усложняют. Я реализовывал парадигму обмена сообщениями и событиями полностью с нуля на C++, PL/SQL, Perl, Delphi. Язык выражения не имеет такого значения и сложности, которе ему придают. Какая разница как и что обозначать? Закладываемое разработчиком значение от этого всё равно не меняется. Если есть сложности с освоением системы обозначений, может тогда не стоит заниматься разработкой ПО, а выбрать задачи по-проще, более подходящие для индивидуальных способностей? Потому что говорить тогда о свободном освоении новой парадигмы или технологий вообще нельзя, а значит и о конструировании станка и создании производственной линии.