Я много-много лет работал программистом и тимлидом, видел некоторое дерьмо. Честно скажу, иногда просто диву даёшься, насколько порой игнорируются психологические моменты работы. Особенно в больших организациях. На практике это порой влияет на продуктивность чуть ли не в разы, без шуток. И буквально на ровном месте.
В безопасной, уважительной, творческой среде мозг раскрывается на всю катушку, и человек способен решать сложные нестандартные задачи, выдвигать классные идеи, работать с энтузиазмом. В токсичной, нестабильной, "микроменджментской" среде тот же самый человек быстро окукливается до состояния "ты начальник, я дурак", и всё происходит только из под палки и строго по инструкции. В какой-то очевидно плачевной ситуации получите "а никто не говорил это чинить".
Недавно я наткнулся на модель SCARF, и в этой модели, как мне кажется, затрагиваются основные пункты, на которые надо точно обратить внимание. Это даже не стоит рассматривать, как какую-то научную работу, просто направления для размышления.
Status — ощущение профессиональной значимости
Это даже скорее не про лычку в линкедин. Если идеи игнорируются без обсуждений, если код ревью - это соревнование "кто больше унизит", а не сотрудничество, если решения просто прилетают сверху без объяснений, то это усиливает окукливание. Мозг переходит в защитный режим и начинает делать "как можно меньше"
Что помогает:
Публичное признание вклада (но только по делу!)
Конструктивное code review: "почему так лучше", а не "ты сделал неправильно". Иногда вообще code review не нужно.
Вовлечение в архитектурные и продуктовые решения
потеря статуса мозгом ощущается почти как физическая угроза. Даже мелкое унижение резко снижает мотивацию
Certainty — предсказуемость и ясность
Сильно раздражает броуновское движение. Когда сегодня мы двигаемся сюда, завтра внезапно всё с точностью до наоборот. "Срочно, но пока не знаем, что именно"
Размытые требования, резко меняющиеся приоритеты и задачи без понятной цели создают фоновую тревогу. Интересно, что даже негативные новости воспринимаются спокойнее, если они чётко сформулированы и объяснены. Ясность почти всегда снижает стресс.
Что улучшает состояние:
Ясные цели на некоторый период
Понимание, зачем делается задача
Прозрачные планы и изменения с объяснениями, если уж изменения нужны
Даже плохие новости, если они понятны, воспринимаются легче, чем туман.
Я не люблю Скрам, это на самом деле просто ужас какой-то, но действительно хорошее, что Скрам может дать - это некоторое ощущение стабильности на отрезке времени.
Autonomy — контроль над своей работой
Возможность самому решать, как именно реализовать задачу, какие инструменты использовать и как организовать свою работу, напрямую связана с ощущением профессионализма. Микроменеджмент и жёсткий контроль, наоборот, быстро превращают инженера в "исполнителя инструкций", что снижает ответственность и инициативу.
Что работает:
Свобода в выборе технических решений
Возможность самому планировать работу
Доверие вместо тотального контроля
Задачи ставятся "что сделать" без "как сделать"
Программист без автономии чувствует себя «руками», а не инженером.
Relatedness — чувство принадлежности и безопасности
Речь идёт не о дружбе там какой-то, а об ощущении психологической безопасности. Если человек боится задавать вопросы, признавать ошибки или высказывать сомнения, его мозг переходит в защитный режим. В такой среде сложно ожидать качественных решений и нестандартного мышления. Поддерживающее общение и отсутствие культуры обвинений создают ощущение "мы вместе", которое напрямую влияет на качество работы. Кстати, Хабр этим сильно страдает: на любую нестандартную статью обязательно придет 10 душнил в коменты и начнут придираться к каждому слову, объясняя, какое же автор говно.
Что создаёт связанность:
Поддерживающее общение
Нормализация ошибок как части обучения
Ощущение "мы в одной лодке"
Когда человек чувствует угрозу со стороны коллег, мозг опять же переходит в защитный режим - про креатив и качество кода можно забыть.
Fairness — ощущение справедливости
Программисты очень остро чувствуют несоответствие между усилиями и вознаграждением. Непрозрачные повышения, разные правила для разных людей и необъяснимые решения разрушают доверие даже тогда, когда формально всё выглядит неплохо. Открытые критерии и последовательность в действиях почти всегда воспринимаются лучше, чем "тихие" договорённости.
Что помогает:
Ясные и открытые правила
Последовательность в решениях
Итого
Если программист будет весело решать проблемы в дружеской атмосфере, то он будет творить чудеса. Если его так или иначе "щемить" и микроменеджить, то чудеса придется творить менеджеру, чтобы хоть что-то куда-то ехало.
Самое странное, что когда компания в кризисе, она зачастую начинает включать режим "дурной начальник", и в итоге всё становится еще хуже, потому что никто в таком режиме уже не предложит креативных идей для выхода из сложной ситуации.
Традиционно всех приглашаю подписаться на мой канал Cross Join
Комментарии (37)
silentz
08.02.2026 12:27Это ровно то, что корпорации делают наоборот - в не зависимости от того что заявляют компании им выгоднее делать наоьорот и они это и делают:
Значимость - чел для корпорации это шурупик и его легко заменить значит он должен боятся увольнения и держаться за свое место
Предсказуемость, Справедливость и тд - та же история
Vladimir_VoV
08.02.2026 12:27А как быть с Legacy проектами?
Там практически никакой свободы в плане архитектурных решений.
Приходится плыть по старым рельсам попутно пристраивая кирпичики .
26rus_mri
08.02.2026 12:27Если проект легаси, но живой, там же переодически переделывают что-то. А если это мертвый проект и там держат кого-то для поддержки пока есть смысл, то это место на любителя)
Vadik_prog
08.02.2026 12:27С годами пришло понимание, что справедливо утверждение - если платят хорошие деньги, значит уважают тебя. Ко всяким там неконструктивным движениям и внутриколлективным коммуникациям вырабатываем хладнокровный подход - не принимаем все близко к сердцу ( хотя это тяжело , все таки живые люди, а не роботы)
vldmrmlkv
08.02.2026 12:27Это всё "как должно быть" или вы это реально применяли или работали там где это применяют? Я тоже видел всякое и как-то раз даже пытался, в приличной форме конечно же, об этом сообщить - посоветовали думать более позитивно!) Всё сильно проще, без этих ваших шарфов) /s
vvbob
08.02.2026 12:27Я как-то офигенно так работал при очень плохо организованном, вообще неправильном и некошерном подходе к разработке. Это был завод, тебе просто выдавали ТЗ, в котором просто по большему счету описывалось что надо бизнесу, и давались контакты людей, к которым обращаться если что-то непонятно, плюс срок на работы, причем срок большой, это не микрозадачи типа спринтов, а что-то на пол года - год. И ты садился и просто писал код, большинство технических решений принимал сам. И это просто счастье было, никакого микроменеджмента, никакого ежедневного контроля за каждым вздохом, никаких бессмысленных нытингов, созвонов и прочего менеджерского булшита, и при этом в принципе вполне нормальная з/п. Реально было ощущение что ты инженер, а не какой-то тупой биоробот крутящий гайки всю смену под бдительным присмотром надзирателя.
NeoNN
08.02.2026 12:27Ну как бы да, с такими процессами и на луну летали, и самолеты делали, а эти аджайлы только тревожность повышают.
vvbob
08.02.2026 12:27Менеджерам такое не нравится, потому что это подразумевает доверие и опору на профессионализм, им комфортнее заниматься микроменеджментом, потому что так у них возникает иллюзия контроля ситуации, и того что дело активно продвигается.
beswalod
08.02.2026 12:27Делать-то они делали, а вот как часто у них получалось это сделать, насколько эффективно, в рамках ли сроков и бюджета -- вопрос большой. Что касается космических программ и самолётов -- посмотрите сколько там неудачных запусков, закрытых проектов, ошибок, провалов и т.д.
В книге "Scrum. Революционный метод управления проектами" Сазерленд как раз приводит в пример провальный проект ФБР/ЦРУ/кого-то_там, когда они работали по waterfall и за несколько лет не смогли поставить нужное ПО.
Сложно судить по небольшой истории @vvbob, но хочется верить, что в его случае всё закончилось хорошо, бюджет и сроки не были превышены, а пользователи действительно пользовались ПО. Но такое бывает не всегда: вполне возможно, что разработчик через год принесёт вам сервис, который в таком виде никому не нужен. В этом случае и уровень тревожности, и уровень разочарованности у всех будет выше, чем уровень раздражения во время ежедневного stand-up.
Ksenia_Volk
08.02.2026 12:27Я сейчас как раз работаю над рекомендациями по совладанию со стрессом на работе именно для ИТ-специалистов и, очень жалею, что не видела эту модель раньше – многое пришлось «изобретать» с нуля. В свою защиту скажу, что научно обоснованных рекомендаций, адаптированных именно под ИТ и российские реалии, пока не так много.
Я работаю с айтишниками как психолог, и, разумеется, те, у кого всё благополучно, редко становятся клиентами. С пунктами модели, представленной в статье, по своему практическому опыту согласна на все 100.
Фактор непредсказуемости действительно часто связан с ростом тревоги. Понятно, что в работе программиста полностью устранить неопределённость невозможно: даже код, который вчера работал стабильно, сегодня может всё поломать. Однако, по моим наблюдениям, ситуация воспринимается значительно спокойнее, когда сроки и требования хотя бы относительно предсказуемы, а решения сопровождаются объяснением логики, а не только формулировкой «так решили».
Отдельная тема - автономия. Многие инженеры приходят в профессию именно потому, что им важно самостоятельно принимать технические решения. В ряде случаев я наблюдала, что избыточное количество созвонов и постоянный контроль скорее повышают напряжение, чем ускоряют работу, особенно если они не добавляют ясности по задачам.
Также часто всплывает вопрос справедливости: переработки, работа в выходные или во время отпуска в формате «посмотри, там чуть-чуть» нередко воспринимаются как норма, но не всегда компенсируются финансово или дополнительным отдыхом. Это, по понятным причинам, влияет на отношение к работе и уровень стресса.
И когда сложно работать автономно, сам процесс работы повышает неопределённость, а не снижает её, и приходится жертвовать своим отдыхом, у человека легко формируется ощущение «я ничего не успеваю», и появляются сомнения в себе как в специалисте.
В этом смысле статья кажется мне хорошей основой для обсуждения условий, которые действительно помогают программистам работать устойчиво и без лишнего напряжения. И, конечно, сами разработчики вряд ли смогут напрямую «внедрить» такую модель в организации, но если хотя бы знать, «как комфортнее», то можно к этому стремиться самому. Ну и невзначай подсунуть описание этой модели руководству))
vadimr
08.02.2026 12:27Я работаю с айтишниками как психолог, и, разумеется, те, у кого всё благополучно, редко становятся клиентами.
Очень мудрое замечание. А если сделать всё под тревожных людей, которые становятся клиентами производственного психолога, то не тревожные люди могут ведь и разбежаться за отсутствием поля для самореализации.
microtheft
08.02.2026 12:27И куда же Вы убежали от "аппаратно-программных комплексов"? :-)
vadimr
08.02.2026 12:27Не понял вопроса.
Но был в жизни как-то случай, когда окружение наводнили люди, полагающие необходимым мне объяснять, в чём состоит цель моей работы. В конце концов пришлось поменять организацию, а работа осталась той же, так как жизнь устроена таким образом, что был бы маузер, а цель для него найдётся.
microtheft
08.02.2026 12:27Вы написали свой комментарий после слов психолога:
Отдельная тема - автономия. Многие инженеры приходят в профессию именно потому, что им важно самостоятельно принимать технические решения. В ряде случаев я наблюдала, что избыточное количество созвонов и постоянный контроль скорее повышают напряжение, чем ускоряют работу, особенно если они не добавляют ясности по задачам.
И мне показалось, что Вы нашли для себя достаточно "автономную" работу, чтобы особенно не бегать.
vadimr
08.02.2026 12:27Всё верно. Но я же сразу написал, что статья совмещает в одну компостную кучу здравые по отдельности для определённых людей, но противоположные по своей направленности идеи.
vvbob
08.02.2026 12:27Если программист будет весело решать проблемы в дружеской атмосфере, то он будет творить чудеса. Если его так или иначе "щемить" и микроменеджить, то чудеса придется творить менеджеру, чтобы хоть что-то куда-то ехало.
Только вот жестокая реальность состоит в том, что бизнесу все эти чудеса не нужны, ему нужен работающий конвейер, с типовыми, легкозаменяемыми рабочими юнитами. Если биоробот начал сбоить и плохо работать, можно для начала отправить его на ТО (отпуск), если это не помогает, то его надо просто выбросить и купить вместо него нового. А креативность вся эта, она слишком непредсказуема и и только мешает работать конвейеру.
GBR-613
08.02.2026 12:27Не всегда, бизнес бизнесу рознь. Даже разные направления внутри того же бизнеса.
vvbob
08.02.2026 12:27Не всегда, но чаще все-же нужен именно конвейер.
GBR-613
08.02.2026 12:27Чаще... Интересно, это кто-то считал, бывает это чаще или реже?
На моем личном опыте, конвейер нужен только для самых простых задач, в которых человека легко заменить ИИ. А для абсолютного большинства задач либо нужны люди, которые умеют мыслить out of the box, либо конвейер уезжает куда-то не туда, куда нужно. Но один я, конечно, слишком маленькая выборка :-)
xaxaxabr
08.02.2026 12:27Жаль тех, кто потом будет с этими ЧУДЕСАМИ, потом разбираться...
Забавно, что автор даже не удосужился разобраться, а КТО собственно ХОЧЕТ или ДОЛЖЕН делать программиста счастливым.
v1nsk1
08.02.2026 12:27Статья хороша - структурированное описание того, что многие чувствуют интуитивно, но редко формализуют. SCARF довольно точно ложится на боли программистов: от toxic code review до хаотичных приоритетов и микроменеджмента
Особенно откликнулся момент про предсказуемость и автономию - даже сложные и неприятные задачи воспринимаются спокойнее, когда понятно "зачем" и есть свобода в реализации
Еще зашло про relatedness: культура обсуждений и отношение к ошибкам сильно влияют на качество решений
В целом чеклист хорош для тимлидов и менеджеров: если хотя бы часть пунктов соблюдается в команде, она начинает работать заметно эффективнее
cross_join
08.02.2026 12:27Видимо, для большинства организаций расшифровки будут несколько другие:
Silent agreement
Conformity
Agism of hiring
Running of loyality
Favoritism
vadimr
Только ЛЛМ, считающая среднее по больнице от текстов разных авторов, могла в наборе взаимоисключающих параграфов соединить ясные цели со свободой в выборе решений.
varanio Автор
Т.е. по вашему, цель и решения, приводящие к цели, - это одно и то же? Я не понял суть вашего наезда
vadimr
Решения вышестоящего уровня являются целями для нижестоящего.
Людям, любящим свободу решений, обычно нафиг не упали ясные цели.
useribs
Ничего не понял. Цель - реализовать то-то и то-то, на выходе должны закрыть такие-то потребности с такими-то метриками (доступности, надежности, whatever). Выбор решения за (командой)/разработчиком. >> Задачи ставятся "что сделать" без "как сделать", по моему все справедливо изложено.
vadimr
Как правило, люди, стремящиеся получить конкретные цели с определёнными метриками, и под свободой решений понимают только то, чтобы им не мешали использовать привычные им предопределённые инструменты.
Я вот лично далеко послал бы человека, который попытался бы меня осчастливить целью более конкретной, чем "произвести что-то, что можно выгодно продать в имеющейся ситуации". Постановка и уточнение цели – это вообще самая интересная часть творческой работы.
varanio Автор
Ну так да, от уровня зависит. Программист может повлиять на один уровень выше, но всё равно не будет делать полную проработку бизнес требований и согласований. А уж если речь про два уровня выше - там совсем труба
В небольших стартапах а ля 2 pizza team да, все влияют на всё, я согласен. Это нормально и хорошо
vadimr
Про стартапы не могу уверенно прокомментировать, я всю жизнь работал в корпоративной культуре. Мне кажется, для стартапов определённость текущих целей должна быть важнее, так как они работают только в тактическом масштабе и сосредоточены на поддержании штанов прямо сейчас, в то время как корпорация живёт в первую очередь внутренней жизнью.
xaxaxabr
"... все влияют на всё ..." - это вроде раньше называлось БАРДАКОМ...
GBR-613
В маленьком начинающем стартапе бардак не только неизбежен, но и оправдан.
vldmrmlkv
Это стратегия, основная цель, кстати, скорее всего - прибыль компании.
Это тактика, то как достигается цель - выбор решений.
Возможно имелось ввиду это, вроде всё логично.