IT - Менеджмент

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

Сверхинтеллект не может реагировать на каждое отклонение - это дороже, чем позволить отклонению быть.

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

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

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

Сверхинтеллект не может относиться к обратимому и необратимому одинаково - цена ошибки структурно разная.

Ты можешь удалить ветку. Можешь удалить коммит через reset. Можешь удалить файл. Всё это обратимо - есть reflog, есть история, есть пушы на remote. Пять минут, восстанавливается.

А можешь удалить репозиторий. Force push в main. Revoke ключа, которым шифровался backup. Удалить S3-бакет с production-данными без версионирования. Эти действия - другого класса. Не «сложнее восстановить» - а структурно невосстановимы или восстановимы только через признание катастрофы.

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

В управленческих решениях - то же. Но управленческой практики, отделяющей rm file от rm -rf /, почти нигде нет. Все решения идут через одно и то же ревью, с одними и теми же сроками, в одной и той же очереди. И раз в полгода кто-то делает rm -rf / в карьере или в команде.

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

Вы продукт-менеджер. Команда разработки согласилась, что фичи не идут в релиз без тестов. Это правило.

В середине квартала приходит руководитель на уровень выше: «Эту фичу нужно выкатить к понедельнику. Тестов сделать не успеваем. Это исключение, один раз».

Вы уступаете. Правильно ли? На эту конкретную фичу - возможно, да. В конкретном квартале - может быть, оправдано. Но посмотрите, что происходит с правилом.

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

Вы не отменили правило. Вы просто показали, что оно отменяемое. В нашей среде это - одно и то же.

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

Распожаризация невозможна, пока работают поджигатели

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

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

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

Тогда я этого не понял. Если у вас всё горит, то может быть стоит потратить силы на то, чтобы не допускать пожаров? Но теперь я осознал, что руководство по распожаризации отвечает на 1 и 3 теоремы выше, нащупав часть математического оптимума.

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

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

Нарушение 1. От вас ждут реакции на каждое отклонение — потому что организация не определила, какие отклонения требуют вмешательства, а какие нет. У вас нет границ допуска.

Симптом: «всё срочно».

Нарушение 2. Вы принимаете решение о найме/увольнении и решение о цвете кнопки с одинаковой скоростью — потому что они идут в одной очереди.

Симптом: «я за пятницу согласовал переход на новый фреймворк, увольнение сотрудника и название релиза».

Нарушение 3. Вы 10 раз решаете один и тот же вопрос - потому что в организации нет правил, есть только прецеденты.

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

Вот почему тайм-менеджмент не помогает. Он не трогает корень.

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

Если ты такой умный, то как не работать на износ?

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

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

Опишите на бумаге три полосы “скоростей” решения. Для каких типов решений вы сознательно не реагируете в первые сутки. Не как «я молодец и терплю», а как осознанная политика. Тут как с защитой от мошенников (что телефонных, что магазинных) - если требуют принять решение здесь и сейчас, то значит пытаются манипулировать.

Как говорит мой знакомый безопасник: когда от меня требуют принять решение, то думать о нём я начну не раньше завтрашнего дня.

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

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

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

Честно - это не спасет, но даст 20–30% облегчения. Корень проблемы в “чайка менеджменте” и бесконечном тушении кризисов. Но обозначить настоящую проблему - не половина решения, но начало пути к реальным изменениям.

Сверхинтеллект тоже будет перерабатывать в среднем менеджменте средней российской организации

В прошлую пятницу я утвердил ещё один MVP в Figma. На выходных отдыхал. Даже не заглядывал в рабочие чаты. Никто не сгорел и не умер.

Нет, я не победил систему и не превратил её в бочку с вином. Но перестрал растворяться в ней.

Задачи-пожары прилетают всё так же часто, но решаются в порядке “скоростных очередей”. И знаете что? За прошлую неделю только одна неожиданная задача требовала реакции в течение трех часов. 12 были распределены на следующие дни. 7 и вовсе ушли в мусорку, стоило отложить их на пару дней.

Коллеги и начальство знают, что если я сказал, что решение будет принято в четверг вечером, то бессмысленно требовать от меня ответа раньше, чем в четверг 17 часов. Это мое окно особо важных решений - четверг с 14 до 17. Даже под угрозой увольнения я сохранил правило. Работать продолжил. Это отдельная история.

Потому что даже сверхинтеллект выгорит в среднем менеджменте средней российской организации. Не потому, что он не имеет степени MBA или не успел овладеть практиками PMBOK 8. Потому что такая среда. Потому что он эффективен и на нём будут ездить, пока не сломают. Потому что учитывать ограничения заинтересован сотрудник (мы с вами), а не организация.

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

• Сколько вообще напоминаний приходит в неделю и в день.

• Насколько важно в напоминании человеческое присутствие.

Ответственный за задачу

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

Когда задачи — не задачи

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

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

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

Тактика пустого инбокса

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

1. Отключите все уведомления

2. Составьте себе расписание дня. Заложите туда, что вы раз в X часов заходите в каждое место с уведомлениями и разбираете их

3. Включите только критичные уведомления — о предстоящих встречах, сообщения от начальника.

Когда настанет время проверки инбоксов — заходите и разбирайте их под ноль. И следующие пару часов снова спокойно работайте.

Итоги

• Сделайте коллектор задач, чтобы было минимум мест куда надо ходить и их проверять. Чат-бот или таск-трекер вам в помощь

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

• Проверьте, является ли задача частью процесса, который где-то описан

• Используйте и обучайте других тактике пустого инбокса

Что-то забыл? Возможно. Подсказывайте и делитесь своим опытом организации рабочего процесса в комментариях здесь или под постом в моём ТГ-канале: https://t.me/the_young_manager/16

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

Пример страницы бронирования сервиса, которым я пользуюсь сам:

Стоит это недорого и оно того стоит. Из зарубежных сервисов знаю такой Calendly, а из российских Планёрка, которым пользуюсь сам. Есть ли ещё аналоги — не знаю, но вы можете поделиться в комментариях. Или другими интересными сервисами, которые были бы полезны менеджеру.

Также, приглашаю вас в свой телеграм-канал, где я рассказываю и о других сервисах, кейсах, подходах для менеджмента. А сегодня написал статью про экономику проекта для Пикабу Игры: https://t.me/the_young_manager/72

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

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

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

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

И именно поэтому на одном из недавних проектов я неожиданно столкнулся с жёстким сопротивлением. Моё руководство довольно прямо пушило меня назад. Моё желание «есть слона по частям» воспринималось как недостаток серьёзности подхода и вызывало предвзятое отношение.

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

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

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

Именно в этот момент вопрос перестал быть про Agile как методологию. Он стал вопросом о границе: где заканчивается стремление всё продумать заранее — и где начинается необходимость двигаться через итерации.

Иллюзия правильного решения

Всегда ли выверенное решение оказывается правильным?

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

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

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

Но у этого подхода есть фундаментальный недостаток: будущее плохо поддаётся предсказанию.

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

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

Формально ответственность в таких случаях ложится на PM. Но по большому счёту виноватых здесь нет. Проблема не в людях, а в том, что далеко не все готовы — или хотят — мыслить вероятностями.

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

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

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

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

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

Именно здесь и становится видно, в чём состоит иллюзия: правильность не обнаруживается заранее — она формируется в процессе.

Итерации как способ получения знания

Так что же нам делать в такой ситуации?

Пытаться сразу сделать всё хорошо и правильно — или всё-таки идти по итерациям?

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

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

Здесь важно понимать ещё одну вещь: каждое решение — это ставка.

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

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

В этом смысле итерации — это не способ ускориться. Это способ дешевле ошибаться.

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

Заключение

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

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

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

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

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

Читайте мою серию: Усталый Босс

Прошлые статьи:

• Agile без ритуалов — эволюция после бюрократии

• От PoC к масштабу — как превратить пилот в повседневную реальность

• Виды логики и их влияние на мышление

• Эволюция современной службы поддержки

• Когнитивные искажения в ИТ: коротко, по-человечески и с примерами

• Вариант ретроспективы для ИТ команд (postmortem)

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент