В понедельник был на #KnowledgeConf - конференции по управлению знаниями в ИТ. Конференция первый раз прошла в 2019 в двухдневном формате, в 2020 была вынуждена уйти в онлайн, потом несколько лет шла как отдельный трек на Teamlead, а сейчас прошла отдельно. Один день, три трека докладов и один мастер-классов. 300 очных участников, что вполне неплохо.

Я публиковал заметки с докладов прямо в ходе конференции, а теперь собрал их в единый отчет https://mtsepkov.org/KnowledgeConf-2025. Основной фокус - практика: онбординг, получение знаний от экспертов и так далее. По вопросам организации и структурирования знаний, по их различным способам представления докладов не было, и меня лично это огорчает. Потому что из опыта я знаю, что есть проекты и продукты с хорошей документацией, а есть - с плохой и непонятной. Люди озаботились написанием, но у них не получилось. Так что это важный практический вопрос: чем как создать именно хорошую документацию. чем она отличается от плохой.

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

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

Я на #ЛАф, мой доклад был открывающим и слады уже опубликованы на моем сайте https://mtsepkov.org/ProjectModel-LAF

#ЛАФ Регина Шарафутдинова и Мария Хромых из Газпромнефти. Будущее бизнес-анализа: Роль критического мышления в эпоху автоматизации и ИИ. Рассказ про новую реальность, в которой аналитик активно использует ИИ. Как для того, чтобы создать варианты решений, так и затем, чтобы обработать интервью. То есть по-максимуму вынести свою мыслительную работу на аутсорсинг. При этом важный аспект - подвергать сомнению. И интервью, и предлагаемые решения. То есть владеть критическим мышлением.

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

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

Доклад интересный. Но я хочу заметить, что есть два принципиально различных варианта мышления: нарративное, примером которого являются литературные тексты, но в повседневной жизни ей пользуются, и мышление структурными моделями разной степени формализации, при котором ты выделяешь типы и экземпляры объектов и не путаешь их, различаешь роли и индивидов, которые их играют, и так далее. ИИ мыслит нарративно. Так вот, доклад был об нарративном мышлении. Критическое мышление было лишь инструментом проверки нарративных текстов на формальную логику, разрывы аргументации, что важно. Но для аналитиков важнее структурное мышление моделями, и даже когда ему поступает текст - он должен его разметить, выделить понятия, определить их типы и так далее. ИИ, кстати, это тоже частично умеет - если специально попросить. Это базовое умение есть не у всех, в школе и институте этому не учат. В Школе системного менеджмента Левенчука об этом был курс Онтологики Прапион Медведевой, который сейчас вошел как часть курса Рациональной работы.

А про причинную связь и отличие причин от корреляций я тут хочу порекомендовать книгу The Book of Why (есть по-русски), в которой как раз рабирается современная разделение причин от корреляций на материале проверки лекартсв, вывления причин болезней и других подобных темах. Таам не тривиально.

#ЛАФ Анастасия Кайнова. Deep Dive in Problem Solving: опыт сотрудника поддержки в карьере аналитика. В докладе кейсы, как углубляться в устройство системы. При этом надо не просто уметь работать слогами, но и заглядывать в код, например, чтобы заметить отсутствие сортировки, понимать структуру передачи сообщений, когда между фронтом и бэком могут быть фильтры и прокси, так что сообщения не доходят. И, конечно, надо докапываться до причин - что не работает, почему возник запрос. Потому что задача по созданию отчета об опозданиях сотрудников может иметь в основе проблему, что система регистрации по пропускам работает плохо и отправляет данные с задержкой или теряет их - то есть реальных опозданий нет, после наладки системы задача отпала. В доладе много классных примеров. Спасибо!

Для тех, кто на #ЛАФ. Этого не было в программе, а рассказ ожидается очень интересный.

Завтра, 8 июня в 12-00 в зале Кострома будет мой мини- доклад "BABOK для чайников, или почему я не зря куплю эту толстую книжку".

#ЛАФ Артем Шуткин. Аналитик как страховой агент взаимозаменяемости участников команды. Доклад об актуальной теме: как быть готовым к рискам ухода сотрудников, в том числе внезапным. Не всегда это печальные, как болезнь или увольнение, может быть и свадьба или повышение. К этому надо быть готовым, и не только по вашей команде, но и по команде заказчика, уход в середине проекта РП заказчика, с которым было много неформальных согласований или ключевого пользователя. который все согласовывал - серьезный риск для проекта. И нужны сценарии действий, нужна оценка трудоемкости замены. И исходя из них - поддержка артефактами, фиксирующими знаниями, и организация перекрытия ответственности, которая создает буфер из людей, которые могут подхватить работу. В докладе все изложено относительно структурно. Один из артефактов - матрица RACI, из которой должны быть риски по уходу сотрудников.

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

#ЛАФ Наталья Седова из Skillbox. Карта компетенций как вариант оценки и развития навыков аналитика. При команде 15+ неформальное понимание о компетенциях сотрудников уже не укладывается в голове, его надо выложить в экзокортекс и сделать нагладным, а для этого - сделать структурным. Так появляется задача сделать карту компененций. Она к ней подступалась несколько раз, но заканчивалось все длинными mindmap навыков на 225 вопросов, с которой непонятно что делать, стандартная оценка нет/знает/применяет/может обучить - не прививается в компании. Она поменяла подход. Создание карты запустила как командный проект, с разделением по задачам и людям. Это дало нужный организационный фокус, а еще карта компетенций получилась коллективным достоянием, она не была в одной голове. И это позволило оценивать карту компетенций через интервью с обсуждением вместо формальной оценки.

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

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

#ЛАФ Ирина Гертовская. Почему требования – не всегда требования. А если не требования – то что? Ответы на вопросы в чатах аналитиков. Первая часть доклада - про разрыв между целями и задачами бизнеса, и требованиями. Аналитиков учат слушать стейкхолдеров, и дальше превращать это в требования. При этом стейкхолдер говорит, что ему ближе. И реальная задача аналитика - не превращать быстро информацию от стейкхолдеров в требования к системе, а восстановить комплексную картину целей и задач, и на основании ее уже сделать требования.

Дальше были инструменты из BABOK: схема BACCM со связями: начинаем с контекста (предметной области) и стейкходеров, а затем надо понять потребности стейкхолдера и ценности - ради чего работает бизнес. Ключевой вопрос даже не "Зачем", а "кому нужно (кто будет деньги выбивать)?" - и у него спрашивать "зачем?". Далее области знаний, это по сути треки в проекте. И техники, которых в BABOK 50 с описанием на 185 страниц. И это - справочник, в который полезно заглянуть, чтобы не упустить что-то важное в новом проекте, чего у вас не было в предыдущих.

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

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

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

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

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

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

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

#ЛАФ Ильназ Хайдаров из Московской биржи. Интеграция как предметная область: чем и как управляем? Идея доклада - сделать систему, чтобы иметь описание всех интеграций. Для этого поставщик интеграции регистрирует OpenAPI и регистрирует его в системе, и потребители тоже фиксируют использование конкретных интерфейсов. А дальше доступ между системами в тестовом и в боевом контуре поднимается на основе зарегистрированных интеграций, при этом в тестовой среде контролируется соответствие API, а в боевом контуре есть возможность включать мониторинг и контроль избирательно. Ну и дальше наворачивать сервисы, например, уведомлять команды-потребители при изменении API в тестовом контуре, и не проносить на прод, пока не получишь подтверждения. Понятная и полезная конструкция.

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

#ЛАФ Ирина Баржак. Менеджмент конфликтов. Ирина - директор института публичных выступлений и публичных выступлений, перед чемпионатом мира по футболу она готовила людей отвечать на пресс-конференциях на провокационные вопросы, не впадая в эмоции, и о конфликтах знает очень много. И она рассказывала, как в конфликте сохранять спокойствие. Как же это сделать? А надо понять следующее: как правило, если человек гневно и не конструктивно о чем-то кричит - он просто проецирует наружу свои внутренние конфликты. "Вы не умеете управлять проектом" - это он не умеет. "Вы не можете организовать выполнение элементарной задачи" - это у него сейчас не получается организовать выполнение задач, или у него не получалось когда-то и осталась травма, которую он выплескивает. А если так - то нет смысла на него раздражаться, самому гневаться или вести себя агрессивно. Надо спокойно слушать и переводить его выплески на язык фактов. Ваша задача - снизить градус конфликта, потому что когда другой человек кипит, то конструктивный диалог невозможен. Говорите тихо. Записывайте претензии, явно. Часто реплика "позвольте я запишу ваши претензии, чтобы не ничего забыть" резко снижает конфликтность обсуждения.

А дальше техника трех да. Люди не любят, когда их лишают выбора. Если вам навязывают дают дополнительный scope - не говорите нет, скажите: это можно, но втрое дороже, или вдвое медленнее, или если вы дадите нам людей. Можно несоклько вариантов, и пусть он выберет. И другая техника - присоединение: признать проблемы и предложить вместе подумать над решением. Работает на поддержке и в call-центрах, Ирина обучала ей людей в МФЦ. Потому что кричать можно на другого, а тут вы получаетесь в одной команде.

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

В конце рассказа - про обесценивание. Бывает, что вас сказали "и над этим вы работали два месяца..." или "и вот это у вас в виде отчета...", или просто посмотрели, когда вы приносите результат. Тут надо понимать, что обесценивание - защитная функция психики. Маленький ребенок хочет в игру старших, а старшие его посылают, да еще обидно. Жуткая боль внутри. А дальше "и ладно, игра у вас дурацкая". Он обесценил то, куда хотел попасть. Прием запоминается, и дальше применяется в жизни, не всегда по делу. И его можно обернуть: если вашу работу обесценивают - значит она ценная. Только ни в коем случае нельзя говорить "ты обесцениваешь, потому что это ценно", это часто на бессознательном уровне, другой будет возражать.

В конце конспекта я хочу заметить, что у Ирины был аналогичный доклад осенью на SQAdays, вы можете посмотреть конспект в моем отчете https://mtsepkov.org/SQAdays-2024b, и там же - ссылка на сайт конференции, где опубликовано видео и презентация. У меня про тот доклад были размышления о том, что безусловно помогая справиться с проблемами тем, кто в слабой позиции техники доклада при этом усиливают тех, кто уже обладая сильной позицией отвергают любую обратную связь. В этом докладе такого отчетливого впечатления не возникло - появился выход в конструктив через технику трех да, через присоединение. Техника трех да была и в прошлом докладе, но не так акцентировано. Наверное, есть и другие примы, или просто иллюстрация кейсами. И в целом доклад ценный, потому что очень важно, чтобы люди не плакали потому, что на работе на них кричат или обесценивают результат.

Опубликовал отчет о #ЛАФ https://mtsepkov.org/LAF2025. Заметки я публиковал только в первый день, а во второй был едкий доклад Димы Безуглого о путях эволюции ИТ-компаний, мастер-класс Макса Дорофеева о том, как через синтаксис ловить ошибки в логике и еще много интересного. Так что читайте. И я по-прежнему с интересом наблюдаю за эволюцией смыслов сленговых слов с очисткой негатива: душнила из человека, душащего идею, превратился в человека, внимательного к деталям и логике. Про эволюцию токсика я пока не очень понимаю, но она тоже идет.

После конференции Школы системного менеджмента решил посмотреть обновленные версии курсов, и начал с Рациональной работы. Я этот курс смотрел еще в пререлизах курса Онтологики, а в 2023 году прошел и даже в качестве учебной работы написал статью "Онтологии социальных отношений", в которой попробовал построить онтологию мета-уровня, внутри которой можно описывать и сопоставлять онтологии социальных моделей. С тех пор курс превратился в руководство и сильно изменился, и я делюсь размышлениями https://mtsepkov.org/RationalWork. В частности, появились интересные концепты темпоральной части объектов и функциональных физических объектов. Появились мантры элегантной работы и операционная как способ наведения фокуса на текущую деятельность на предмет проверки ее рациональности и целесообразности. И многое другое. А разделы про причинность, в которых рассказывается про диаграммы причинности, позволяющий обосновать причинность через статистические данные, побудили меня прочитать книгу The Book of Why, на которую ссылается руководство, потому что плюшевые примеры в руководстве меня не удовлетворили совершенно. Книга оказалась очень содержательной, и о ней я тоже написал достаточно подробно. Думаю, будет полезным.

Завтра 18.06 в 18:00 в рамках проекта УНИВЁРS будет вторая часть моего семинара по инженерную модель личности. Первая часть была 05.06 и ее запись уже доступна, а завтра будет продолжение. Мы начнем с новой темы - модели ценностей, поэтому можно слушать и тем, кто не был 6на первой части. Ссылки на регистрацию - в посте-анонсе.

Опубликовано видео второй части моего семинара по развитию личности, https://youtu.be/cNM7IK9tlO0, в которой рассказ был о моделях ценностей и других социальные модели, а также схемы самоопределения. Самоопределение рассмотрено как создание аватара для новой деятельности, а личность в целом представляет собой множество аватаров, и такая конструкция рассматривается в ряде моделей психологии. В первой части https://youtu.be/w0xMgqVQli0 мы говорили о быстром и медленном мышлении, эмоциях и обучении, формировании личности.

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

Презентация доступна на моем сайте https://mtsepkov.org/PersonalityUnivers. Подробнее о модели личности можно узнать из моей книги, которая так и называется: Инженерная модель личности. Я благодарен УнивёрS за возможность участия цикле семинаров https://www.univers.id/seminari, где идет очень содержательный разговор.

#Highload Смена восприятия. Олег Бунин на открытии "есть похожее в создании музыки, создании ролика, создании программ", и я тут же додумываю: все эо сейчас хорошо делает ИИ/LLM/GPT. F он продолжает: "все это - создание чего-то из ничего, нужен лишь замысел" - и это тоже правда. Всем доброе утро! Я эту неделю на конференциях: Highload, потом Teamlead в Питере.

#Highload Дмитрий Кривопальцев и Вадим Клеба. Как выбрать технологии для высоконагруженного проекта и не привлечь внимание санитаров. Доклад - обзор вопросов, которые надо решать при выборе технологий. Но по факту на все вопросы есть общий ответ: включить мозг, а не следовать за модой. А подробнее: (1) понимайте вашу задачу, (2) потребности бизнеса и (3) возможности вашей команды. Любая технология имеет плюсы и минусы, для разных задач подходит разное. И с любой технологией потмо долго жить, нужны люди, которые ей владеют. А теперь по содержанию детально.

Первое - язык. Тут в командах обоих докладчиков два языка, у одной - java + python, при чем на python ядро? а на java - высокопроизводительные конкретные сервисы, в другой java + Go, при этом java - основа, а go - для кусочков, которые общаются по http. B это иллюстрация к уместности языков для задач. При этом надо помнить, что быстрый язык сам по себе не дает производительности, производительность обеспечивается устройством кода. По умолчанию - используем что знаем. Но обязательно помните про команду - возможность изучения новых языков командой, возможность найма разработчиков, владеющих языком.

Второе - база данных. В 9 случаях из 10 подходит PostgreSQL. А в том одном случае - выбирайте по характеристикам, понимая зачем это нужно. Но помните про сопровождения, был кейс, когда выбрали Кассандру, она подходила идеально по характеристикам, но через два года выяснилось, что поддерживать некому, и лучше бы накостылили что-то на PostgreSQL.

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

Открывающий доклад #Teamlead Дмитрий Болдырев. Что нам стоит Team построить? «Шокирующая правда» о командах и командостроении. Доклад о строительстве команд в old school парадигме - всерьез и надолго. Детальный разбор модели Такмана по этапам. С рисками и потерями. И не очевидным, на мой взгляд, эффектом: Дмитрий говорит, что производительность +30%, 1 из трех команд разваливается на пути, а процесс командообразования для 12 человек занимает около года. При этмо понятно, что есть ситуации, когда команда все-таки необходима, например, нужно решить прорывную длинную задачу. Но, как я вижу, на практике есть light-вариант команды, которая уже больше, чем группа автономных исполнителей, но не в полной мере удовлетворяет всем критериям командной работы, которые формулировал Дмитрий. И при хорошей культуре и умениях в компании или отдельного руководителя проектные команды получаются такие, и гораздо быстрее. Еще замечу, что Scrum (и Kanban) дает организационную форму, обеспечивающую light-вариант создания команды - если уметь это делать, я это видел на многих историях.

Это было мое мнение, а теперь - конспект содержания доклада, оно ценное. И хорошо структурированное.

Команда - свойство рабочей группы, в котором она демонстрирует командную работу.
* Все действительно хотят достичь цели, стоящей перед группой. Не сочувствуют, делают вид или разделяют, а воспринимают как личную
* Имеют одинаковое представление о том, что происходит: что делается, куда идем
* Все в целом согласны с ситуацией. Нет противоречий и внутренней оппозиции
* Все постоянно отслеживают друг друга, мониторят. Они сами хотят знать, что делают другие
* Все дают друг другу немедленную, искреннюю и конструктивную обратную связь. Критика - про действия, а не личность, и идеи исправления
* Все проактивно подстраиваются, адаптируются друг под друга.
* Все проактивно страхуют друг друга и оказывают поддержку.
* Все взаимодействуют напрямую, адресно и не ожидают фидбека. Не через руководителя, не послания "в пустоту" (тут нужно сделать...), не сигналы
* Все правдиво информируют друг друга о своем положении дел. Не боятся рассказывать о фейлах.
* Принимают друг друга такими, как есть, с достоинствами и недостатками. Нет ситуации "он не нравится, я не общаюсь"
* Все доверяют друг друга: добросовестны и нет злобных замыслов
* Нет внутренней конкуренции и борьбы за статус, не бьются друг с другом
* Участники осознают и принимают групповую ответственность. Включая материальную: личная зарплата зависит от результата группы. Реакция на такое предложение - маркер
* Группа слаженно работает и при отвсутствии руководителя
* Участники стремятся оставаться в текущем составе
* Группа устойчива к трудностям и постоянно развивается

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

У командности есть цена.
* Превращение группы в команду для 12 человек занимает в среднем год
* Может потребоваться радикальная перестройка бизнес-процессов и орг.структуры
* Командообразование, строительство дает просадку производительности на 25% минимум.
* Смена состава 30-70%, уйдут или вы отправите специалистов, которые могут быть профи. Профессионализм и умение работать в команде - разное.
* В 1 случае из трех группа теряется
* Наличие у руководителя выраженных личных качеств.
* Требует радикальной перестройки руководителя от директивного в не-директивный когда завелась.

Командообразование - дорого, долго и больно. Почему? И как ее строить?
0. Понять, зачем нам строить команду. Есть альтернатива - регламентация. Когда нужно: (а) сложная работа с большим количеством взаимосвязей и зависимостей; (б) работа в долгую; (в) прорывная задача.
1. Установить состав и границу группы.
2. Изучить людей: личностные особенности, мотивация, квалификационные способности. Может выясниться, что из этих людей команда не получится, придется менять состав.
3. Обеспечить наличие базовых условий. (а) Общая цель - must. (б) Рабочие созависимости - в процессе, не объединение в конце, не эстафета. Это может требовать реорганизации. (в) Стабильный состав ядра группы. (г) Первичная организация работы - планы, роли, регламенты. Можно от руководителя, можно дать групп самой организоваться. Самоорганизация - дольше, обязательно поругаются, а договорятся ли - не факт. Если задали - они начинают работу, но групповая динамика будет запускаться дольше.
4. Заинтересовать,б вдохновить тиммейтов достижением цели - это самое простое
5. Дать освоиться - состояние лимба. Они будут работать, в этой работе будет позитивная мотивация, они послушны и лояльны лидеру, декларация приверженности и добросовестность, вежливость и неконфликтность. Но каждый будет обособлен, сосредоточен на своей работе, а остальное - фон. Не будет инициативы, группа будет реактивна, закрытость и неискренность, приукрашивание информации, сдержанность, не работа на максималках. Мотивы: расположить к себе (новую) группу, но при этом не рисковать (ситуация неопределенная). 99% рабочих групп пребывают в этом состоянии, и есть риск застрять в нем. Состояние комфортно и для группы и для руководителя, состояние может длиться годами.
6. Форсирование работы. Либо естественно - в проекте возникают проблемы - не успеваем, не взлетаем. Или искусственно, через ускорение процесса. Но не микроменеджмент, не долбить каждого 5 секунд - это испортит репутацию.
7. Накопление напряжения внутри, без выхода наружу. Проявятся слабости участников, нельзя держать фасад. Пойдет формирование симпатий и антипатий, борьба за статус - кто-то всегда этим займется. Наступает разочарование друг в друге и в проекте - думал, все хорошие и будет легко, а это не так. Кризис мотивации и падение производительности, отрицательная спираль. Если ничего не делать - три варианта (а) скатиться в формализм, думать о себе; (б) постоянная смена состава; (в) выгорание с уходом или формализмом.
8. Стимуляция, обострение кризиса - чтобы недовольство вышло. (а) Поощрять откровенную обратную свзь, подначивать: "не нравится - скажи как есть, другому или всем, публично".
9. Кризис: тихий развал группы (никто не вышел на работу); громкий развал группы; групповой конфликт или серия - групповая драка. Драка - не развал, это хорошо.
10. Решение судьбы группы. Конфликт выплескивает эмоции, потом включается мозг и они самоопределяются: уйти или остаться. Здесь нужны усилия по возвращению ценных сотрудников, это нетривиальная задача. Итог: развал или сохранение. Группа сохраняется, если для них дело, общая цель имеет значение. Или когда некуда идти, нет вариантов.
11. Реорганизация группы с учетом негативного опыта. Пересмотр целей, стратегии,планов, изменение рабочего процесса, перераспределение ролей, люди сами вызываются. И пересмотр финансовых условий, это в момент удержания. И в этом участвуют все, реорганизацию делают сами. И есть риск не договориться - тогда окончательный развал группы.
12. Метаморфоз группы. Групповая цель - как собственная. Раз уж остался - все соки из всех выжму. Ответственность каждого за общий результат. Принятие своих ролей. Принятие друг друга как есть - они друг друга знают: "Ладно, вы все кривые, но вас могила исправит, работаем вместе". Фокусировка на задаче и прекращение дрязг. Выполнять хорошо работу самому и помощь товарищу. Рост производительности с положительной обратной связью.
13. Метаморфоз руководителя. Максимум полномочий отдать группе. Иначе они на реорганизации скажут "определись, или командуешь и мы каждый за себя, или организуемся". Это - потенциальный блокер.