{"id":14271,"url":"\/distributions\/14271\/click?bit=1&hash=51917511656265921c5b13ff3eb9d4e048e0aaeb67fc3977400bb43652cdbd32","title":"\u0420\u0435\u0434\u0430\u043a\u0442\u043e\u0440 \u043d\u0430\u0442\u0438\u0432\u043e\u043a \u0438 \u0441\u043f\u0435\u0446\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 vc.ru \u2014 \u043d\u0430\u0439\u0434\u0438\u0441\u044c!","buttonText":"","imageUuid":""}

Процессы и люди в IT: Иерархия в организации

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

Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в L3, дорос до тимлида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в АйТи Мегагруп.

Что делает сферу информационных технологий такой весёлой и забавной с точки зрения технологий управления? Давайте представим себе завод. На заводе есть цеха, склады и станки. Их нужно расставить в правильном порядке, чтобы осуществить необходимые цепочки производства чего-то, что требует выполнения сотен операций в определённой последовательности.

В ИТ все ровно так же. Однако, ваши цеха и станки это не какие-то предметы, это люди. То есть в какой-то момент ваш «станок» может просто встать и уйти, он же вам не принадлежит.

Кроме того у каждого «станка» свои возможности, производительность и уникальные способности. Вплоть до того, что один «станок» может заменить один-два «цеха». То есть один человек будет производить больше, чем несколько отделов. Причем возможно только иногда и под своё хорошее настроение.

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

Те подходы, которые хорошо работают на физических линиях производства, плохо работают на линиях производства в ИТ, которые состоят из живых людей.

Как это ни странно, но HR - это очень важный человек в ИТ. Честно говоря, области ИТ и HR вообще очень близки.

Ну и что, скажите вы, ведь есть и другие области, в которых работают люди, а не машины? Например, бухгалтерия. Да, конечно. Только условный «старший» бухгалтер физически не может сделать в 100 раз больше, чем «обычный» бухгалтер. А разработчик — может, просто исходя из своих личностных качеств. Из-за такой зависимости эффективности работы от личных качеств сотрудника, вы не сможете просто взять и смахнуть один отдел либо заменить в нём всех людей. Стоимость замены не только высокая, но и часто просто неизвестная.

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

Хотите быть успешными в ИТ? Придётся изучить не только технологии, методологии и процессы, но ещё и людей.

Иерархии в коллективе

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

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

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

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

Другой пример. Вы молодой лейтенант, который прибывает на фронт во время второй мировой войны. Если вы умный руководитель, то скорее всего, найдёте того сержанта, который на фронте уже год и фактически осуществляет управление, и первые несколько недель будет слушать вы его, а не он вас. Иначе, у вашего подразделения где-то через недельку будет новый командир, лейтенанты тогда на фронте недолго жили. Это тоже упрощённый пример, чтобы почувствовать разницу между формальной и фактической иерархией.

Самая большая ошибка, которую вы можете сделать, это отпустить иерархию и отдать её формирование кому-то другому. Руководить и решать за вас тогда тоже в итоге будет кто-то другой.

Самоорганизующиеся коллективы

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

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

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

Давайте поймём, как вообще растёт иерархия/команда. По сути есть два естественных механизма роста, которые исходят из разных потребностей людей. Вот их и рассмотрим.

Иерархия на основе взаимной помощи и общей цели

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

Это ключевой момент. Помощник обучен и работает самостоятельно, с минимальным контролем. У помощника и начальника общие цели, начальник выступает скорее, как наставник. С помощником разговаривают, делятся мыслями по поводу работы, обсуждают общие цели и какие-то текущие проблемы, где-то помогают, где-то получают помощь от него. Это член команды, за которым следят, а не контролируют, член команды, которому доверяют и о котором заботятся.

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

Проходит какое-то время, и объем работы возрастает. Становятся нужны новые помощники. А потом уже помощники помощников. Начинает разрастаться команда и иерархия внутри команды. Но всех объединяет общая цель, к которой они идут вместе, взаимная помощь и доверие друг к другу.

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

А вы попробуйте не только вырастить такого помощника, а ещё и помощника, который сможет вырастить помощников себе. Именно вырастить — это медленный процесс.

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

Зато, это команда с распределенным центром принятия решения. Проблему будут решать сразу и прямо в месте её возникновения.

Иерархия на основе контроля

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

В свою очередь, сотрудник не доверяет нам. Ему не хочется чтобы его наказывали «просто так», а ещё ему хочется понимать, как получать премии побольше. Сотрудник начинает требовать понятных и чётких правил игры. Появляются регламенты и процессы.

Все мы понимаем, что регламенты и процессы будут сразу же нечестным образом использованы одной из сторон. Причём на уровне: «Нигде же не было написано, что кошек нельзя сушить в микроволновке».

Кроме того, так как сотруднику в своих грехах признаваться резона нет, нужен будет человек который будет следить за соблюдением регламентов и процессов. Честно говоря, контролирующему сотруднику мы тоже доверять не будем, у него будет свой регламент и процесс. А ещё иногда будут возникать непонятные и нерегламентированные ситуации, и сотруднику придётся обращаться к контролирующему его человеку, чтобы узнать, а как в этой ситуации поступить «хорошо», чтобы его не наказали. Поэтому контролирующий сотрудник иногда будет «должен» думать за своих подчинённых. Почему слово «должен» взято в кавычки? Ведь для контролирующего сотрудника это тоже риск.

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

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

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

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

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

Иерархия и решение проблем

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

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

Часто проблему нужно начинать решать сразу же. У сотрудника, который встретил проблему, уже есть какие-то навыки (его не зря учили), у него есть понимание общей цели и ценностей (пусть и неформальных) команды, на базе которых он может разобраться, какое решение является верным, а какое нет. То есть сотрудник сам принимает какие-то решения и начинает решать проблему по месту возникновения. Желательно, чтобы в случае сомнений в своих силах, сотрудник сразу подал сигнал тревоги, перед тем как приступать к решению проблемы.

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

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

Что происходит в иерархиях, которая выстроена на контроле? По сути будет обратный процесс. Если возникла проблема, значит в ней кто-то виноват. А значит, если проблема не нуждается в срочном решении, то лучше на неё не реагировать, чтобы случайно не стать в ней виноватым и не быть за неё наказанным. Может даже возникнуть заговор молчания.

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

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

Таким образом, проблема начинает «подниматься» до уровня сотрудников, которые способны взять на себя риск принятия решений. То есть проблема поднимается до ближайшего центра принятия решений.

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

Иерархия и решение конфликтов

В любом коллективе возникают конфликты. Чем больше коллектив, тем чаще они возникают. Обычно мы говорим о конфликтах интересов. Например, они могут возникать между разными ветвями иерархии, когда разные зоны ответственности обладают разными интересами.

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

То есть, задействованные сотрудники рассматривают конфликт интересов и договариваются о том, как именно и почему так они будут разрешать такие конфликты. Ключевое слово «почему так», то есть все должны понимать почему решение именно такое, какие у него есть плюсы и какие минусы. Таким образом при появлении конфликта интересов лишь частично похожего на уже решённые конфликты интересов, повышаются шансы найти решение по месту его возникновения, не привлекая других участников команды.

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

Помним, что в иерархиях на основе контроля есть запрограммированные конфликты интересов, и системе выгодно иметь поток конфликтов определённой мощности и наказывать нижестоящие слои за возникновение таких конфликтов.

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

Взаимодействие иерархий

Здесь всё просто и сложно одновременно. Однотипные иерархи легко сливаются, разнотипные иерархии отталкиваются, но только в пределах одного «слоя».

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

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

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

Одна сторона будет требовать понимания и общих целей, другая сторона будет требовать правил и регламентов (которые они не будут соблюдать).

Результатом такого конфликта интересов, часто становится уничтожение одной из иерархий (все носители уволены), либо принуждение к подчинению одной иерархии другой. Сотрудники из подчинённой иерархии либо притворяются, что следуют правилам/договорённостям, либо трансформируются (меняют мировоззрение), либо постепенно замещаются (отложенное увольнение).

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

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

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

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

Масштабирование иерархий

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

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

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

Иногда возможно метастабильное состояние иерархии, когда иерархия кажется монолитной и однотипной. Такое может происходить при сильном давлении людей одного типа на людей другого типа, но не может происходить в долгосрочной перспективе (несколько десятков лет).

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

Подводя итоги

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

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

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

Возвращаясь к нашей предметной области в виде сферы информационных технологий мы увидим, что наибольшей эффективности достигают небольшие и сплочённые команды. Бывают случаи, когда команды из 10 человек спокойно делает то, что не могут сделать 100 других специалистов с компетенциями не ниже, которые просто участвуют в команде с иерархией другого типа.

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

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

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

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

Если вы дочитали до конца и извлекли из этого что-то полезное для себя, а тем более если вам ещё было интересно, то спасибо вам.

0
52 комментария
Написать комментарий...
Dima

Статья наверное интересная, но текста много и он сливается, картинки не очень в тему показались. Они не раскрывают и не дополняют текст. Меня не вовлекло, уж простите, может это будет важно для вас.

Ответить
Развернуть ветку
Леонид Игнатов

Всё крайне формально, даже картинки как будто из стандартного набора. Похоже на статью ради портфолио или что-то подобное.

Ответить
Развернуть ветку
10 комментариев
Константин Митин
Автор

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Константин Митин
Автор

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

Ответить
Развернуть ветку
32 комментария
Mike K

Соглашусь с другими комментаторами: статье не хватает контекста и реальных примеров, чтобы понять многие аспекты.

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

Спасибо!

Ответить
Развернуть ветку
Vladimir P

Спасибо! Очень интересно написали! Кому как, я прочел на одном дыхании.

Ответить
Развернуть ветку
Константин Митин
Автор

С кейсами не так все просто. Нужно понимать, что все ситуации сложные и для них нет простого описания. С каждой стороны свои конструктивные мотивы и своя правда. При условии, что только основных действующих лиц будет от десяти и более, по объёмам это выйдет где-то на уровне бизнес-романа. Тем более, что проблемы не ходят по одной. Например, это может быть комбинация конфликта двух иерархий после акционерного развода, осложнённая сопутствующим вылетом золотой шестерёнки, отсутствие которой компания не смогла скомпенсировать, на фоне банального треугольника Карпмана на уровне ДИТ и операционной дирекцией, с элементами JSDD от разработчиков, при условии что каждая сторона делает весьма сильные политические ходы.
Плюс проблема NDA, плюс вопросы этики. Правильно упаковать кейс, так чтобы о нем можно было рассказывать, очень сложно. Возможно когда-нибудь, но не сейчас. )

Ответить
Развернуть ветку
Viktoriia Kh

Текст объемный. Содержание хорошее. Думаю разбить на две части будет отличной идеей. Что касательно самой темы; недавно писала развёрнутый ответ на то, как поддерживать положительный климат внутри комнаты и прочитав разные источники информации, мне очень понравилась краткое содержание книги про принципы переговоров по Гарвардской методике. Книга называется: «Переговоры без поражения» думаю будет интересно почитать тем, кто изучает построение процессов, механизмом в команде и построение отношений в коллективе.

Ответить
Развернуть ветку
Даша Рудковская

Как бывшему юристу и начинающему PM мне статья понравилась. Был бы у меня еще более обширный практический опыт было бы еще интереснее. Но да, местами, текст был "перегружен" и я теряла мысль автора. Картинки я сначала смотрела, потом не понимала к чему некоторые приведены. Но статья толковая, пишите)
Мне было бы интересно еще прочитать реальные практические кейсы внутрикорпоративных конфликтов и способов их разрешения.

Ответить
Развернуть ветку
49 комментариев
Раскрывать всегда