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

Совершенно непрофильный пост о коронавирусе. Воспринимайте его как braindump и игнорируйте

Ежедневно сталкиваюсь с двумя полярными мнениями
А. “Это просто грипп!”
Б. “Мы все умрем!”
Оба мнения считаю ошибочными (и, разумеется, получу сейчас лещей с обеих сторон)

Теперь ссылки и факты
1) вирус официально называется SARS-CoV-2 (а до того часто называли 2019-nCoV, что означало “новый коронавирус); Болезнь называется Covid-19; Просто чтобы не путаться
2) он близкий родственник прошлой атипичной пневмонии (SARS)

Далее разберем пункт А

Вернёмся к обычным темам. Есть тысяча способов поделить людей на группы по какому-то критерию. У меня есть своя личная совершенно антинаучная классификация:

Я делю людей на
* бабочки
* ракеты
* бульдозеры
Это не покрывает всех людей на свете, а лишь тех, кто мне актуален.

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

«Ракеты» мчатся к цели сквозь космос. Они очень быстро могут преодолеть огромные расстояния и попасть за неделю туда, куда казалось и за 100 лет не дойти. Но им нужны бесперебойное поступление топлива в изобилии и чтобы не было препятствий. Об препятствия они взрываются, а от дефицита топлива падают. Сломанная ракета лететь уже не может :( но даже половина пути некоторых из моих «погибших ракет» и оставленные ими вымпелы на далеких астероидах и спустя 5+ лет кажутся серьезным достижением.

«Бульдозеры» делают дело медленно, но неумолимо. Объём труда и препятствия их не смущают. Непогода может притормозить их, но не отменяет сделанного.

Я лично наибольший комфорт испытываю с «бульдозерами», хотя могу раздражаться на их медленность. Но никакой «юнит» не универсален:
* «Ракета» очень сложна в обслуживании, но может сэкономить годы времени. Даже однократно применённая.
* «Бабочки» могут ничего не принести в сложном климате, если их не «пасти». Но можно многого добиться, используя «бульдозеры» для ликвидации препятствий и закрепления результата.
* «Бульдозеры» могут простаивать или грести не туда. Но "ракеты" и "бабочки" могут указать нужный путь.

Все совпадения с реальными людьми под их личную ответственность!

Довольно часто в попытке убедить или договориться, люди тратят силы на убеждение или переговоры с неправильным человеком. Частный случай "проблема лейтенанта".

К чему она сводится:
-есть человек, который принимает решения (ЛПР), которые вас касаются
- если бы вы общались с ним напрямую, то вы могли бы с ним обсудать иные способы достичь его целей, которые были бы вам удобнее. Этот человек мог бы сравнить выгоды и цены разных вариантов, сопоставить риски и потому его можно убедить. win-win, все дела
- но вот он поручает исполнение своего решения "лейтенанту". "Лейтенант" не понимает всего пространства решений, всех выгод и рисков. Он либо добивается исполнения и тогда он молодец, либо не добивается и тогда он плохой.
- вести переговоры с "лейтенантом" малоэффективно - все альтернативы для него заведомо плохие
Упс!

Многие этого не понимают, и сжигают килокалории аргументов вхолостую.

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

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

Давно не брал я в руки шашек… то есть давно не писал сюда. А тема сегодня “manage up”.

Недавно мы проводили опрос об обставноке в отделе и в частности спрашивали насколько легко выражать несогласие с руководителем. Один из отзывов был про меня лично: “если позиции не принципиально различны то договорить требует усилия, но не сложно. в противном случае *изменить мнение/позицию лидера можно только когда он сам придет после какого-то времени и накопления критической массы информации*. это либо приводит к  избыточным усилиям при убеждении, либо (что чаще) оставляется до момента набора критической массы информации”.

Надеюсь, что автор не против, но поскольку опрос анонимный, то уточнить нет возможности.

Этот отзыв побуждает обсудить концепцию “manage up”, которая у нас мало известна. Все понимают про “manage down” - сотрудникам надо ставить ясные задачи, мотивировать их, есть тысячи книг, сотни методов, куча курсов, Стратоплан и все остальное. Но, оказывается, готовить надо уметь не только сотрудников, но и босса. Сюрприз! Это и есть “manage up”.

Отзыв как раз удачно раскрывает в чем состоит manage up - руководителя трудно в чем-то убедить пока он не наберет критическую массу информацию! То есть чтобы его убедить … надо ему эту критическую массу предоставить! Мнение, неподкрепленное критической массой информации (фактами), к сожалению, часто оказывается недостаточно убедительно.

Обратимся к классике
1) известная цитата “Everyone is entitled to his own opinion, but not his own facts.” - не совсем следствие, но тонкий намек, что факты у нас должны быть общими, чтобы наши мнения вообще можно было сопоставлять
2) фундаментальная ошибка аттрибуции - действия других людей, кажутся вызванными их внутренними качествами, а собственные действия - внешними обстоятельствами. Внешним обстоятельством можно полагать и наш контекст, известные нам факты.

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

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

Здесь может возникнуть вопрос “зачем нанимать профессионала и не следовать его мнению? зачем корячиться с обоснованиями?” Нам всем очень лестно видеть себя профессионалами, однако наш профессионализм тестируется как раз способностью коротко и полно что-то объяснить. Помните анекдот “… я вам столько раз объяснил, что уже даже сам понял”? - да, только отличное понимание темы позволяет доносить мысль в короткой и одновременно полной форме.

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

Итого:
1) боссом можно и нужно управлять
2) управляют боссом (лучше всего!) через донесение информации
3) донесение информации надо уметь делать правильно

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

С некоторым удивлением всегда читаю о применении ТРИЗ к бизнес-задачам. Если вы не сталкивались с этой аббревиатурой раньше, то ТРИЗ это Теория Решения Изобретательских Задач, созданная в 1956 года Генрихом Альтшуллером. Это прямо набор конкретных принципов, абстракций и даже алгоритм, как изобрести что-то хорошее. В советское время отдельные последователи Альтшуллера регистрировали изобретения сотнями, а кто-то, помнится, и тысячу пробил.

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

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

Насколько я знаю, такой работы никто не проводил. Поэтому механический перенос принципов ТРИЗ на бизнес или выдачу каких-то собственных умозрительных принципов за “ТРИЗ для бизнеса” нельзя ставить с оригинальным ТРИЗ на одну полку.

В каком-то смысле программистские паттерны проектирования (синглтон и тп) можно воспринимать как элемент программисткого ТРИЗа, но аналогичной полной системы все-таки нет.

Так совпало, что в нескольких чатиках прозвучали вопросы о том, как правильно принимать/передавать дела по проекту другой команде. Вариант этого вопроса это “как правильно законсервировать проект?”.

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

Для понимая особенностей: размер кодовой базы порядка 1 млн строк, число пользователей (b2b) от нескольких тысяч до нескольких десятков тысяч. Нюанс в нашей области - все продукты коробочные, то есть развертываются на серверах клиентов. Нельзя обойтись нежным “работает - не трогай” на своих машинах - каждый раз надо распространить исправление, его развернут на тысячах самых разных машин чужие люди, и если чего пойдет не так, то будет большой вой.

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

Массовость породила некое подобие процесса:
1) инвентаризация всех существующих ресурсов для последующего копирования. Понятно, что сюда входит репозиторий кода. Но также и багтракер, и хранилище всех документов, и форум, и чат, и история тикетов , вообще все, что можно найти и что отдадут, дистрибутивы и бинарники. Об этом еще немного позже - но это предельно важный этап. Скажу только, что однажды мы обнаружили, что кусок исходников не был на передан (по недосмотру он вообще никогда не помещался в репозиторий) и нужный компонент нашли в бинарном мусоре перебором разных файлов методом черного ящика. Один из них правильно работал по шифрованному протоколу. Фуууух, пронесло…
2) знакомство; требуем общее описание продукта, его архитектуры и принципов. Из чего вы исходили, когда что-то делали, как оно все должно работать вместе. Детали модулей можно почти всегда выяснить по коду, а вот общие принципы выявить тяжело; На хороший документ в большинстве случаев рассчитывать не приходится - вызываем главного специалиста(ов) на место и он под запись рассказывает
3) инструкция по быстрому старту. как это собрать, запустить и убедиться, что работает. До “as a code” подхода оставалось еще очень много лет, да и сейчас он еще не повсеместен. Без такой инструкции я первый принятый продукт бесплодно устанавливал три дня подряд. Про сборку даже говорить не приходится - даже про родной продукт я часто шутил, что можно безопасно допустить утечку исходников - никто не скопирует продукт, потому что собрать его по исходникам просто нереально, нужна цистерна секретного соуса. Разумеется, инструкцию надо немедленно практически проверить. На слово в этом бизнесе верить не стоит.
4) инструкция по расширению - грубо говоря, как добавить новую фичу или модуль. Берем типовую задачу и примеряем ее на код. Интересно, что если с этапа рассказа про архитектуру разработчики выходили со словами “вау! Нам бы так!”, то с прохода по коду все обычно много плевались и говорили нехорошие слова о предшественниках.
5) распросить наиболее проблемные области по текущему опыту. “что бы бы вы советовали сделать самим себе, если бы не прервались.” Инженер не может удержаться и не поговорить о проблемах, а знать слабые места критически важно
6) после воспроизведения сборки, запуска и простых изменений (1-4 недели) с большей частью исходной команды прощаются и ВСЕ управление передается новой команде. 1-3 эксперта из исходной команды остаются консультантами на почасовой оплате на срок 2-4 месяца. Новая команда раскатывает обновление и если клиенты его пережили, то крещением боем пройдено.

Теперь вернемся к инвентаризации -

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

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

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

Но у кого такая проблема есть, то ее можно более-менее решить простым workaround’ом - написать эту обратную связь. Почему?

1) Потому что любой текст “не вырубишь топором”, и это обязует. Нам придется все сформулировать так, чтобы потом на наши претензии не было ответа “а что ты раньше не говорил, что код прямо совсем плохой? ты же просто сказал, что можно и получше”. Заодно запись еще и мысль в порядок приводит.
2) Потому что, написав все это, мы это должны будем переслать получателю. Но вначале поговорить. Именно вначале. И вот тут мы словами все по-человечески и расскажем, без этой письменной сухости. НО всякий раз, когда говорить что-то будет неприятно, когда захочется смягчить, замылить (есть вы будете связаны тем, что за спиной заградотрядом стоит текст, который надо будет отправить. И если мы говорим “ну тут чуточку не так”, а там написано что вообще все совсем не так, то потом будет удивление. Что это ты говорил одно, а написал другое? Так что придется соответствовать
3) И наконец надо переслать этот текст. Обязательно переслать. Это наш сожженый за спиной мост, чтобы не струсить и не убежать от неприятных слов. Это наш заградотряд, который заставит нас сделать #2 как положено;

У кого есть такая проблема, то пользуйтесь
А кстати, есть такая книжка radical candor, и там расписаны и про “оба хуже” (даже три способа делать плохо). Там они называются Obnoxious Agreesion (это когда “продолбали полимеры”) и Ruinous Empathy (это когда как-то неудобно сказать хорошему человеку прямо) Еще там написано как надо бы в идеале. У меня, правда, не всегда еще получается