Часть 2. Платформа ни при чём

29.09.26

Команда - Коммуникации

История о том, как несколько хороших 1С-специалистов постепенно обнаруживают, что работать рядом — ещё не значит работать вместе. Через релизы, зависшие обмены, вечные «два дня», незаменимых разработчиков, пользователей с неожиданными требованиями и процессы, пережившие собственный смысл, они учатся превращаться в команду — не идеальную и не бесконфликтную, а живую. Рассказ о сложности совместной работы, в которой самые трудные ошибки обычно находятся не в коде.

Люди, которые смотрят в одну базу

В понедельник утром Сергей Викторович объявил, что теперь они команда. Это была не самая неожиданная новость понедельника — в рабочей базе с утра почему-то перестали проводиться реализации, — но всё-таки новость заметили. Сергей Викторович написал в общем чате: «Коллеги, с сегодняшнего дня работаем как единая команда», подумал и добавил ракету. Видимо, без ракеты организационное изменение могло не состояться. Петров увидел сообщение минут через двадцать: он как раз выяснял, почему после пятничнего обновления один и тот же документ на тестовой базе проводился, а на рабочей выражал принципиальное несогласие с действительностью. Петров был ведущим разработчиком и к словам вроде «команда», «вовлечённость» и особенно «синергия» относился осторожно. За двадцать лет рядом с 1С он усвоил: если нечто нельзя воспроизвести на копии базы, прежде чем обсуждать его философское значение, полезно посмотреть журнал регистрации.

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

Марина в это время разговаривала с бухгалтерией. У бухгалтерии «опять всё зависло». Через пять минут выяснилось, что зависло не всё, а один документ; ещё через пять — что документ не завис, а долго проводится; ещё через десять — что пользователь открыл период за три года и нажал «Заполнить». Марина обладала особым даром: после разговора с ней проблема становилась меньше, но реальнее. Она знала систему с той стороны экрана, о которой разработчики обычно вспоминают после слов «странно, у меня всё работает». Вадим, тестировщик, сообщения в чатах читал выборочно и считал, что большая часть человеческого общения страдает от недостатка предусловий и ожидаемого результата. Если ему говорили: «Иногда не работает», он спрашивал: «Иногда — это при каких условиях?» Если отвечали: «Случайно», он печально смотрел на собеседника. Случайности в его мире допускались, но только после того, как исключены права, данные, версия платформы, кэш, расширения, обмены и человек.

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

 

Когда все работают хорошо, а вместе получается странно

У отдела уже были почти все внешние признаки команды: общий чат, доска задач, еженедельная встреча, Wiki с документацией и пятничная ретроспектива. Документация, правда, местами описывала состояние системы двухлетней давности, но это тоже можно было считать формой исторического знания. Ретроспектива обычно начиналась вопросом Сергея Викторовича: «Что на этой неделе было хорошо?» После паузы кто-нибудь говорил: «В целом хорошо взаимодействовали». Сергей Викторович записывал «коммуникация». На вопрос «Что улучшить?» после такой же паузы возникал ответ: «Наверное, коммуникацию». Получалась удивительно стабильная система: коммуникация одновременно являлась главным достижением отдела и его основной проблемой.

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

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

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

Тем не менее вечер оказался неплохим. Люди посмеялись, поговорили не о задачах, узнали друг друга немного лучше. Сергей Викторович не считал мероприятие бесполезным; просто через два дня выяснилось, что настоящие команды строятся на материале похуже бумаги. Утром в четверг остановился обмен с сайтом. Сначала заказы просто перестали появляться в базе. Потом менеджеры заметили задержку и начали создавать их вручную. Затем обмен ненадолго ожил, часть заказов пришла автоматически, возникли дубли, а к обеду проблема достигла той приятной зрелости, когда уже затронула несколько подразделений и о ней знает коммерческий директор.

В переговорке собрались все. Петров полез в фоновые задания и технологический журнал, Лена восстанавливала, что менялось за последнюю неделю, Марина обзванивала менеджеров и пыталась отделить симптомы от последствий, Вадим строил воспроизводимый сценарий, Сергей Викторович каждые сорок минут сообщал руководству, что причину ищут и данные не потеряны. Через час Петров обнаружил подозрительный участок кода и раздражённо спросил, кто сюда вообще полез. Лена посмотрела историю изменений и ответила: «Мы». Петров уточнил, кто именно входит в это ёмкое понятие. Лена приблизила экран: «Ты». Петров сказал, что этого не может быть. Комментарий к изменению был его. «Комментарий ничего не доказывает», — заметил он, и в каком-то смысле был прав: полтора месяца назад они действительно меняли расписание регламентных заданий по просьбе бизнеса, чтобы ночной обмен не пересекался с закрытием смены. Решение тогда считалось временным, а временные решения в 1С, как известно, обладают необычайной продолжительностью жизни.

Ещё полчаса спорили о расписании, пока Илья, до этого почти не вмешивавшийся, не спросил: «А если обмен падает вот здесь, транзакция точно завершается?» В комнате стало тихо. Петров посмотрел код, потом ещё раз и сказал: «Не завершается». Илья на всякий случай ничего не добавил. Работу восстановили ближе к часу ночи. Никто не произносил вдохновляющих речей, Марина написала пользователям, Вадим завёл дефект, Лена добавила недостающее описание процесса, а Петров несколько минут молча смотрел на код и наконец сказал Илье: «Хорошо заметил». Тот ответил, что заметил случайно. Вадим немедленно сообщил, что случайно ничего не бывает. Все засмеялись.

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

 

Магическая величина «два дня»

После истории с обменом Сергей Викторович решил следующий тренинг пока не покупать и попробовать изменить обычную работу. Начали с планирования. Раньше схема была простой: заказчик приходил к Лене, Лена выясняла требования, затем иногда спрашивала разработчика, сколько времени займёт реализация. Петров чаще всего отвечал: «Два дня». У него это было не столько сроком, сколько жанром ответа. Примерно как у врача «понаблюдаем». Иногда два дня действительно означали два дня, иногда четыре, иногда неделю, а в особо интересных случаях через два дня Петров сообщал: «Там оказалось не всё так просто». Никто уже не удивлялся.

Теперь задачи стали обсуждать вместе. Первой попалась частичная отгрузка по резервам. Лена изложила требования, Петров привычно сказал: «Два дня». Сергей Викторович попросил не спешить. Марина уточнила, идёт ли речь только о центральном складе или обо всех, и напомнила, что в регионе резервирование работает иначе. Петров немного изменил позу. Вадим спросил, что произойдёт с уже созданными документами и является ли ответ предположением или зафиксированным требованием. Дима вспомнил про обмен с сайтом, Илья — про движения по регистру. Через сорок минут задача оставалась вполне решаемой, но первоначальные два дня куда-то исчезли. Петров вздохнул и произнёс: «Ладно. Давайте сначала посмотрим, что там реально затрагивается». Никто не аплодировал, но Сергей Викторович с удивлением понял, что это и есть прогресс.

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

Но сложнее всего оказалось с незаменимостью. У отдела существовал неофициальный статус задачи — «у Петрова». Если задача находилась у Петрова, вопросы временно прекращались. «Что с ошибкой себестоимости?» — «У Петрова». «А обмен?» — «Петров смотрит». «Закрытие месяца?» — «Петров разбирается». Фраза обладала почти лечебным действием: само присутствие проблемы у Петрова воспринималось как форма решения. Петров от этого одновременно страдал и гордился. Однажды Сергей Викторович спросил, понимает ли он, что огромный кусок системы существует только у него в голове. Петров возразил против слова «огромный», потом против «кусок», а когда Сергей Викторович предположил, что Петров может однажды уехать на месяц, обсуждение неожиданно перешло к тому, куда именно он собирается уезжать и почему так надолго. Разговор о передаче знаний оказался непростым уже на уровне гипотезы об отпуске.

Илья начал брать задачи сложнее, сначала вместе с Петровым. Это раздражало обоих. Илья боялся показаться глупым и слишком долго молчал, Петров боялся потерять время и слишком быстро объяснял. Его любимая фраза «тут всё стандартно» означала совокупность знаний, накопленных примерно с 2008 года. Для Ильи она означала практически ничего. Постепенно Петров научился объяснять не только что делать, но и почему, и тут обнаружилась ещё одна неприятная особенность профессионального опыта: многие решения, живущие в голове как очевидность, при попытке произнести их вслух начинают задавать владельцу лишние вопросы. На вопрос Ильи «А почему здесь временная таблица?» Петров однажды ответил: «Потому что быстрее». «Проверяли?» — спросил Илья. Петров задумался. Выяснилось, что проверяли лет пять назад, на другой версии платформы и другом объёме данных. Иногда после таких разговоров старое решение всё равно оказывалось правильным. Иногда — нет. Оба варианта приносили пользу.

Первую действительно серьёзную задачу Илья сделал почти без Петрова. Лена помогла с требованиями, Вадим разобрал тестовые сценарии, Марина нашла пользователя для проверки. Петров посмотрел уже готовый код и сказал: «Нормально». Для Ильи это было почти наградой, а Петров после работы выглядел задумчивым. Вечером он признался Сергею Викторовичу, что ощущение неприятное: «Они без меня сделали». Сергей Викторович напомнил, что именно этого они и добивались. «Я понимаю, — сказал Петров. — Но всё равно неприятно». И здесь выяснилось то, чего обычно не пишут в регламентах передачи знаний: незаменимость неудобна, отнимает вечера, портит отпуск и при этом каждый день сообщает человеку, что он нужен. Расставаться с ней значительно труднее, чем кажется со стороны.

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

 

Самая большая блокировка в системе

Пока Петров учился быть менее незаменимым, Сергей Викторович обнаружил, что сам находится примерно в том же положении. Только хуже. Все решения проходили через него: приоритеты, распределение задач, согласования, подключения специалистов, общение с заказчиком. Ему казалось, что это и есть управление. Однажды он заболел, два дня почти не отвечал на сообщения, а вернувшись увидел несколько задач, которые не двигались. На вопрос «Почему стоит?» ему отвечали: «Ждали тебя». Здесь нужно было определить приоритет, там — решить, кому отдать, ещё где-то — согласовать. Сергей Викторович медленно сел за стол. Он много лет гордился тем, что является человеком, через которого ничего не потеряется, и вдруг понял, что стал человеком, без которого ничего не движется.

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

Через полгода отдел действительно стал работать спокойнее. Релизы перестали напоминать эвакуацию, Вадима подключали раньше пятницы вечером, Лена не называла сроки без обсуждения, Марина успевала принести пользовательскую реальность до того, как разработчики построят вокруг неё красивую архитектуру, Илья спорил с Петровым и однажды оказался прав, а Сергей Викторович иногда целый час не знал, чем конкретно занят каждый сотрудник, и постепенно перестал считать это управленческим провалом. В речи появилось приятное слово «мы»: мы сделали, мы проверили, мы предлагаем, мы не успеваем. Но вместе с ним незаметно появилось другое — «они». Они поменяли требования. Они не читают инструкции. Они сами не знают, чего хотят. Они поставили срочность. Они сломали данные.

Внешний мир вообще обладает любопытным свойством: чем дружнее становится группа, тем хуже иногда начинает выглядеть всё, что находится за её пределами. На одной ретроспективе Петров минут десять объяснял, как бизнес в очередной раз изменил требования в последний момент. Лена поддерживала, Дима кивал, даже Илья, который заказчика видел всего два раза, выглядел возмущённым. Сергей Викторович тоже собирался присоединиться, но вместо этого спросил, когда они последний раз показывали бизнесу промежуточный вариант. Оказалось — три недели назад, на постановке задачи. «А потом?» — «Потом мы работали». Ответ прозвучал вполне логично, и именно поэтому стал тревожным.

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

Петров посмотрел на экран и спросил: «Так вот это для вас главное?» Заказчик ответил: «Конечно». «Почему сразу не сказали?» — удивился Петров. Заказчик посмотрел на него почти с сочувствием: «Вы не спрашивали». Марина рассмеялась. Не над заказчиком и не над Петровым, а над всеми сразу. Иногда несколько умных взрослых людей способны три недели профессионально работать только для того, чтобы в конце концов услышать фразу, которую можно было узнать за десять минут. В этом, наверное, и состоит одна из наиболее человечных сторон совместной работы.

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

 

Процесс, который однажды был полезным

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

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

Через два года директор встретил Сергея Викторовича возле кофемашины и сказал, что слышал про его сильную команду. Сергей Викторович посмотрел через стекло переговорки: там Петров спорил с Леной, судя по жестам — об архитектуре; Илья сидел рядом и улыбался; Вадим листал журнал регистрации; Марина разговаривала с пользователем; на доске красным горела задача с блокером, и никто не пытался перекрасить её в зелёный ради красивого отчёта. «Нормальная команда», — сказал Сергей Викторович. Директор возразил, что показатели хорошие, люди выросли, релизы стали спокойнее, хотя, судя по происходящему за стеклом, спорить они не перестали. «Конечно», — ответил Сергей Викторович. «А я думал, хорошая команда — когда все уже сработались». Сергей Викторович задумался и сказал: «Наверное, хорошая команда — не когда перестали спорить. А когда можно спорить и не разрушать работу». Директор заметил, что звучит красиво. «Я два года формулировал», — ответил Сергей Викторович.

В этот момент дверь переговорки открылась, выглянул Петров и сказал: «Сергеич, мы тут немного сломали». Директор заметно напрягся, Сергей Викторович — нет. Он уточнил, рабочую ли базу. Петров ответил: «Пока нет». «Это хорошая часть сообщения. Я нужен?» Петров оглянулся назад. Лена уже сидела рядом с Ильёй, Вадим что-то показывал Диме, Марина закончила звонок и вернулась к столу. «Пока нет. Если что, позовём». Дверь закрылась.

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

Никакое командообразование не избавляет от этого, и, пожалуй, не должно. Команда — не способ превратить людей в идеально согласованный механизм; такие механизмы вообще подозрительны. Она скорее позволяет нормальным, разным, местами упрямым людям делать сложную работу, не требуя, чтобы ради этого они сначала стали одинаковыми. Петров может не знать ответа, Илья — его найти, Лена — остановить разработку вопросом «зачем», Марина — разрушить красивую конструкцию рассказом о том, как на самом деле работает кладовщик, Вадим — потребовать воспроизводимый сценарий там, где все уже договорились считать проблему случайностью, а Сергей Викторович — не вмешаться, хотя очень хочется. Иногда даже заказчик временно попадает внутрь этого «мы».

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

Ракету использовать не стал.

командообразование команда управление командой 1С разработка 1С управление проектами тимлид руководитель команды командная работа взаимодействие делегирование совместное планирование ретроспектива Agile Scrum процессы разработки корпоративная культура мотивация управление изменениями

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Коммуникации Руководитель проекта 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

17.09.2026    249    0    YA_826532418    0    

4

Коммуникации Бесплатно (free)

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

03.09.2026    338    0    YA_826532418    0    

4

Коммуникации Аналитик Руководитель проекта Бесплатно (free)

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

02.09.2026    548    0    YA_826532418    3    

5

Коммуникации Удаленная команда Бесплатно (free)

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

02.09.2026    291    0    user2117358    0    

0

Коммуникации Бесплатно (free)

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

13.08.2026    499    0    irinaaykn    1    

1

Коммуникации Лидерство Бесплатно (free)

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

13.08.2026    519    0    G_104938689049837478547    0    

0

Коммуникации Бесплатно (free)

Delivery – это не доставка еды, а доставка ценности в продакшн: разбираем, как выстроить процесс поставки на примере команды, работающей с 1С:ЗУП. Показываем, как за пару лет удалось почти вдвое сократить срок поставки решений, увеличить количество релизов с пяти до двенадцати в месяц и уменьшить периоды бизнес-фризов – за счет процессов, автоматизации и фокуса, а не переработок. Объясняем, как Lead Time, предсказуемость и другие метрики помогают находить узкие места и оценивать эффективность команды. Делимся практическими кейсами, сложностями и результатами – без лишней теории, только опыт.

12.08.2026    466    0    a_borodavko    0    

27

Коммуникации Бесплатно (free)

Почему процессы, которые отлично работали в одной небольшой команде, перестают справляться с ростом, а увеличение штата не ускоряет поставку, а лишь усложняет коммуникацию и размывает ответственность? Рассказываем, как перейти от одной функциональной команды к системе автономных доменов, распределить архитектурную экспертизу и избежать ситуации, когда архитектор или платформенная команда становятся «бутылочным горлышком». Разбираем принципы Team Topologies с учетом специфики 1С, рабочие способы межкомандной синхронизации и трансформацию ролей руководителей, тимлидов и архитекторов. Показываем, как выстроить устойчивую ИТ-экосистему, в которой автономия не превращается в анархию, а координация – в бюрократию.

11.08.2026    392    0    Аверков    3    

2
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. NeLyubluSKD 29.09.26 13:11 Сейчас в теме
Надо же, как, оказывается, сложно выстраивать работу... В 2014м менеджеров вдруг стали считать никчемными людьми, а будущее приписывали айтишникам и программистам. Ведь они умеют работать удаленно, а это экономия на офисе ну и прочие бла бла бла))

Ну и как работается без менеджеров, ребят?) Говорите, Лена с Петей общего языка не находят?)) ну ну...
2. amiralnar 9 29.09.26 13:35 Сейчас в теме
(1) разговариваете с нейросетевыми галлюцинациями?)
4. Rico17 32 29.09.26 15:20 Сейчас в теме
(2)
разговариваете с нейросетевыми галлюцинациями?)

Скорее разговариваю с очень земными галлюцинациями — Петровыми, Ленами, Вадимами и руководителями проектов, которые почему-то из года в год повторяются в разных компаниях :)

Если персонажи показались слишком собирательными — замечание принимаю. Рассказ и задумывался не как реалистическая проза с претензией на Чехова, а как профессиональная история, где читатель иногда узнаёт коллегу, иногда себя, а иногда — ситуацию, которую лучше было бы не узнавать (Источник материалов для рассказа см. "Часть 1. Командообразование, или Белый кит сплочён.").

Ну а с нейросетью я тоже разговариваю. В 2026-м совсем её игнорировать — уже отдельный литературный эксперимент :)
3. Rico17 32 29.09.26 15:13 Сейчас в теме
(1)
менеджеров вдруг стали считать никчемными людьми, а будущее приписывали айтишникам и программистам.


Да, в этом как раз и есть хорошая ирония всей истории :)

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

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

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

Ну а Лена с Петей, конечно, общего языка сами не найдут. Особенно если оба совершенно уверены, что говорят на русском. :)
Для отправки сообщения требуется регистрация/авторизация