Что будет если убрать все эти scrum-атрибуты. Большинство менеджеров останутся без работы, а остальным станет только легче жить.
Был у меня как-то интересный опыт тимлидства. Когда я работал в прошлой компании, то в какой-то момент стал тимлидом абсолютно новой команды UI Kit. Это была не обычная продуктовая команда, поэтому от меня вообще ничего не требовали никаких метрик, оценок задач и прочего. Скорее это даже был эксперимент, где от меня ждали, что я смогу достичь большой цели — перевести два мобильных приложения на единую дизайн-систему.
Все, что мне нужно было, — это заявлять OKR, который я выполню за 4 месяца. По-простому — цели команды на какой-то промежуток времени. И потом в конце нужно было отчитаться перед руководством, на сколько процентов мы выполнили цели.
Я накидал план, как мы достигнем наших целей за 4 месяца, и мы раз в неделю просто сравнивались с этим планом и вносили корректировки. Заодно напоминали себе, что мы делаем и приближаемся ли к цели. Ну и еще было дейли, но даже не каждый день, а 3 раза в неделю. Остальное время каждый участник команды брал на себя большой проект и спокойно делал его, не отвлекаясь ни на какие оценки в сторипойнтах, формирование целей спринта и всякие скрам-встречи. Большинство дней были полностью избавлены от любых встреч.
Я так работал до самого последнего дня в этой компании, и нам так и не потребовалось ничего вводить. Цели достигались близко к 100%. Позже я понял, почему там получилось так сделать:
У меня была супер-мотивированная команда, которую мне позволили набрать самому. Это были люди, которые изначально хотели заниматься дизайн-системой
Мой менеджер не требовал от меня никаких метрик, оценок задач, промежуточных сроков и т.д. От меня нужен был только финальный результат. А часто все эти лишние процессы появляются просто для того, чтобы двигать отчеты наверх
Откуда появляется вся эта скрам-атрибутика в командах
Ну первое — она всегда там и была. Мы приходим во всякие бигтехи и живем по правилам. Но все равно когда-то это появилось.
Еще бывает так, что команда работала себе нормально, все даже были довольны. Но потом приходит заряженный тимлид из другой компании и начинает обвешивать команду новыми процессами, встречами, оценками и метриками. Часто они даже не задумываются, зачем это все, просто не представляют, как по-другому.
Бывает и так, что где-то выше команды появляется эффективный менеджер, который начинает насаждать всю эту скрам-атрибутику. Он требует метрики и отчеты от тимлидов, а тимлидам ничего не остается, кроме как обвешивать команду всем этим добром, чтобы отчитываться перед эффективным менеджером. А потом уже все привыкают и живут с этим. А кто спрашивал «зачем нам это нужно?» и получил ответ «будет прозрачнее и эффективнее», потом уже и не вспомнит, стало ли действительно эффективнее.
Последняя причина, почему все эти скрам-атрибуты теоретически могут появиться в командах, — это если сами команды нуждались в этом и ввели все осознанно. Но это какая-то фантастика, такого не бывает.
Эффективные менеджеры тоже хотят кушать
Представьте, так получилось, что вы оказались на какой-то промежуточной позиции между разработкой и топ-менеджментом. То есть вы и разработкой напрямую не управляете, и компанией не управляете. Все, что вам нужно, — это создать мост предсказуемости по доставке фичей, а еще нужно, чтобы фаундеры понимали, какие команды молодцы, а какие не очень.
И тогда все, что вам остается, — это строить систему, где будет создаваться иллюзия контроля. А по командным метрикам будет видно, что команда X просела в последнем спринте, потому что сеньор-разработчик был в отпуске. Вау, как бы мы догадались, что команда сделает меньше, когда нет одного разработчика, если бы не посмотрели на командный график.
И это еще хорошо, если на такого менеджера просто давят сверху, чтобы он все это приносил. Многие сами проявляют инициативу и начинают внедрять скрам просто ради ачивки, бонуса, повышения или похвалы от фаундера.
Оценки в сторипойнтах создают иллюзию контроля
Вы все равно никогда не угадаете сроки. Ну вот вся фича оценилась в 50 сторипойнтов — и что? А что там внутри: зависимости от других команд, долгое ревью, долгие согласования техдизайна или внезапные проблемы, которые сразу не учли.
Сторипойнты создают иллюзию контроля. А единственная реальная ценность от них в том, что команда просто обсуждает задачи, чтобы понять, что там нужно делать, и разобрать корнер-кейсы. Но это можно делать и без оценки.
Если просто назвать рандомное количество дней, и то будет лучше. Так хотя бы команде не придется постоянно заниматься этим адом с покер-планингом и прочими ритуалами.
Спринты и цели спринта на самом деле только замедляют команды
Сейчас я открою страшную тайну для многих менеджеров: если у команды срок на выполнение задачи — 2 недели, то она выполнит эту задачу, внимание, за 2 недели. И никогда не сделает это быстрее. А если не ставить срок в 2 недели, то команда будет делать столько, сколько реально потребуется времени — 3 дня, 5 дней или 8 дней. Ну вы поняли.
Этот эффект хорошо описал Дорофеев в книге «Джедайские техники». Если у задачи есть срок, то она всегда будет выполнена в последний день этого срока.
Дейли не всегда нужен
Большинство участников команды просто живут в режиме: сделаю 1, 2, 3 — и этого достаточно, чтобы рассказать на дейли завтра. На этом можно и закончить работу на сегодня. Это приводит к тому, что люди начинают бояться браться за большие сложные задачи. Потому что некомфортно каждый раз говорить: еще делаю, еще делаю, еще делаю. Это настоящая психологическая пытка, когда кажется, что все вокруг думают, будто ты просто прохлаждаешься. Проще взять какую-нибудь мелочь, закрыть ее за пару часов и отчитаться.
В моей прошлой компании была платформенная команда. У них дейли был один раз в неделю (тогда уж викли). Каждый участник команды делал сложную, продолжительную задачу, и можно было спокойно погрузиться в нее на целую неделю, не думая о том, что говорить каждый день.
А что делать-то тогда?
Любой диалог с предложениями добавить новые процессы или встречи должен выглядеть примерно так:
— А давайте будем оценивать задачи в сторипойнтах! — предлагает радостно
— Зачем?
— Чтобы давать предсказуемые сроки по фичам
— Каким образом это поможет угадать сроки?
— …
По поводу новых встреч. Например, в мой календарь тяжело воткнуть что-то лишнее. Я душу вытрясу, пока не пойму, зачем это действительно нужно.
Ну и на подумать: если человек мотивирован что-то делать, если он знает зачем и для кого, то он уйдёт в эту задачу с головой и выдаст превосходный результат. Если человека вогнать в рамки, обвешать метриками и процессами, то он выдаст ровно тот результат, который от него ожидают — ни больше ни меньше.
Приглашаю в свой тг-канал «Из найма в продукт». Я рассказываю, как совмещаю работу в найме и разработку собственного продукта. Пишу про IT, карьеру и выживание в профессии — обо всём, что меня волнует.
Комментарии (98)
Dmitriila
06.02.2026 01:25скрам=скам
microtheft
06.02.2026 01:25скрам=скам
скрам+скам=срам
vybo
06.02.2026 01:25Скрам на месте суммы же тут, в виде множеств (не путать с массивами) во всяком случае
sunnybear
06.02.2026 01:25Выглядит как "давайте уберём ремень безопасности: он только мешает, и ни разу пока не помог"
Fizika
06.02.2026 01:25ремень безопасности не есть рулевое колесо. Просто на дороге не нужно уж так теребонькать рулем туда-сюда, изображая крутецкий дрифт
Varowlord4
06.02.2026 01:25Скрам скорее навигатор, который каждые 100 метров перестраивает маршрут и требует подтвердить, что ты все еще едешь прямо, иногда проще выключить его и ехать по знакам
denisemenov
06.02.2026 01:25И всё это прекрасно бы работало, если все знают, куда едут. И точно ли там будет то, куда они хотят приехать, когда приедут.
Disonco
06.02.2026 01:25Не, это как "мы знаем что то что мы ищем где-то на севере, мы не знаем где именно, мы не знаем как долго мы будем ехать на север чтобы это найти, мы предполагаем что с очень высокой вероятностью мы доедем до этого за 3 месяца и мы не будем останавливаться каждый час и измерять пройденное расстояние, мы будем просто ехать вперёд ибо чтобы достичь цели к ней нужно двигаться".
rPman
06.02.2026 01:25Метрики нужны не когда все хорошо и все работает, а когда что то работает со сбоями или плохо, и что бы попытаться предугадать проблемы хотя бы до того как они начнут заметно влиять.
Как вы собираете искать 'импостера' в команде, если команда для вас - черный ящик.
Как собирать и какие именно метрики нужно собирать что бы стало хорошо, вопрос на миллион.
ahdenchik
06.02.2026 01:25Как вы собираете искать 'импостера' в команде, если команда для вас - черный ящик.
Это очень легко делается: просто научитесь программировать и смотрите что они там коммиттят.
А если вам это лень, и удобнее занятым людям голову клевать, то значит вы занимаете чужую должностьrPman
06.02.2026 01:25Конечно, это прекрасно работает в команде до 10.. ну 20 человек, а дальше 'научитесь программировать' уже не работает, вы человек и ваши возможности ограничены.
Я сейчас не защищаю современные методы построения этих метрик, там такой кошмар что волосы дыбом встают, но собирать метрики так или иначе нужно, и задача руководителя построить систему контроля такой, что бы она не мешала (или мешала по минимуму) работе.
Kasyan666
06.02.2026 01:25ИМХО, не сто́ит иметь столь большие команды, лучше их дробить на более мелкие из 5..6 человек, включая лида. Опять-таки, ИМХО, глубокая древовидная структура предпочтительнее и эффективнее новомодной "плоской" модели.
svz
06.02.2026 01:25Вы удивитесь, но из команд по 5 человек формируются отделы по 20 и направления по 100. И их руководителям тоже нужно как-то отслеживать эффективность работы своих подчинённых и прогресс своих задач. Процессы не заканчиваются отношениями между разработчиком и его тимлидом.
monco83
06.02.2026 01:25Тут ключевое "тоже нужно как-то отслеживать", причём каждое слово важно.
"Тоже нужно" - ну какой же он руководитель без отслеживания? Нельзя же подвергнуть сомнению его необходимость в роли руководителя?
"Как-то" - значит всё равно как, не важно точно или не точно ты отслеживаешь, оказывает этот контроль положительное влияние на процессы или не оказывает. Главное, чтобы были хоть какие-то цифры, которые можно показать и вниз и вверх для создания иллюзии контроля.
Ndochp
06.02.2026 01:25Процессы не заканчиваются отношениями между разработчиком и его тимлидом.
Почему? У 6 разработчиков есть тимлид, у 6 тимлидов есть тимтимлид. У тим тим тим лида в подчинении 258 человек, а подчиненных - шестеро. И еще 36 человек могут "через голову" нажаловаться на своего руководителя.
Takeora
06.02.2026 01:25Никогда этого не понимал. Зачем? К чему этот микроменелжмент? Вы рук отдела, у вас есть лиды, всё. Если кто-то проёбывается, это вопрос к лиду, он уже должен делать свою работу.
Shvabrashvabr
06.02.2026 01:25То есть это всё нужно когда в менеджменте сидит левый контингент, не разбирающийся в этой этой отрасли, присосавшийся к айтишке на волнах хайпа?
Manguss
06.02.2026 01:25Ой давайте уберем дедлайн, он же стресовый....
Дейли как ремень безопасности в авто, лишь бы не пригодился, но если что то важное и неожиданное происходит позволяет узнать об этом раньше.
Вообще без стеснения укладываемся в 5 минут дейли. Прощелкали доску, проговорили нет ли рисков если есть запланировали обсуждение и пошли работать дальше.
В зрелой команде нет осуждений что кто то 3 спринта одну задачу может копать или промахнуться в оценке.
Ни нужно ни одно действие в жизни воспринимать абсолютно, все имеет некий разбег, Много метрик не есть хорошо, и работать без метрик не есть хорошо. Дедлайн как священная корова - утопия, но и без дедлайна работать плохая идея.
dskonev
06.02.2026 01:25Если происходит что-то важное и неожиданное, нужно ли ждать дейли, чтобы об этом рассказать? Может лучше рассказать сразу, но по другому каналу передачи информации?
И не похож дейли на ремень безопасности. Скорее похож на жужжание навигатора, который кроме предстоящих действий сообщает о выполненных: "Когда я повернул на улицу Ленина, увидел что она перекрыта. Поэтому маршрут перестроил и совершил разворот. На ближайшем перекрёстке поверну направо и поищу параллельную улицу." Польза есть, если кто-то это внимательно слушал и знает, что там параллельных улиц нет до самого выезда из города. Подскажет, что надо повернуть налево: сэкономит немного времени на манёврах. Вот и всё, пожалуй. А ремень безопасности - это алерты и автооткат релизов по метрикам приложения. Но это уже не про мерам.
skovoroad
06.02.2026 01:25Если происходит что-то важное и неожиданное, нужно ли ждать дейли, чтобы об этом рассказать?
А человек может и не знать, что у него проблема. Что он решает промежуточную проблему, которую уже позавчера решили в соседней команде. Или что эту проблему год назад решал другой человек и признал её заградительно дорогой. Или что ваши работы случайно пересеклись и вы на мёрже друг другу помешаете. Или что сосед знает более эффективное решение. Разработчик, например, может не отдавать себе отчёта в том, что фичу лучше урезать, если она растягивается, но решить в срок. И так далее, много может что быть.
И дейли тут выступает в роли милиционера на лошади - одна голова хорошо, а две лучше.
В простых потоковых задачах это, может быть, и не нужно, а в сложных проектах с большим количеством контрибьюторов без постоянной коммуникации постоянно кто-нибудь будет забредать не туда, не по злобе, а просто ну потому что разработчик заведомо знает меньше, чем пять разработчиков.
А всё потому что, оказывается, созвониться на 15 минут в день придумал злой лид от безделья.
dskonev
06.02.2026 01:25Я же ни разу не сказал, что дейли бесполезен и вообще зло? Лишь то, что его польза ограничена подсказками типа "как пройти в библиотеку" и "за каким углом лежат грабли". И аналогия с ремнём безопасности некорректна.
tenzink
06.02.2026 01:25Даже если сам дейлик занимает 5 минут, чего я никогда и нигде не встречал, то это не значит, что его стоимость 5 минут. Overhead на неё всё равно не меньше 30-60 минут на разработчика: как и любая встреча он разбивает поток на до и после. Время тратится как на вхождение в митинг с потерей контекста разработки, там и на выход
Ndochp
06.02.2026 01:25У нас ввели дейлики через 15 минут после начала рабочего дня. Просто пестня. Хотя можно как раз успеть подвигать задачи по доске до актуального состояния. То есть по факту - подготовка к дейлику и больше ничего, а по документам - дейлик всего 15 минут.
Ivan22
06.02.2026 01:25у вас есть жесткое строего начало дня???? может еще и опоздания на проходной фиксируются?
aiminkai
06.02.2026 01:25Странное решение со стороны руководства. Просто вышвырнули 15 минут из рабочего дня
barloc
06.02.2026 01:25До этого надо ещё дойти, через боль и слезы видимо. Причём система как описана у автора более требовательная нежели история с списанием часовых затрат на каждую задачу.
Pavel_SD
06.02.2026 01:25Я так думаю, что команде мотивированных профи и правда ничего не нужно, никаких фреймворков. А как управлять командой, где есть джуны, стажёры, токсичные авторитеты и другие интересные кадры каждый со своим взглядом на всё вокруг?
DadeMurphyZC
06.02.2026 01:25//У меня была супер-мотивированная команда, которую мне позволили набрать самому. Это были люди, которые изначально хотели заниматься дизайн-системой
Вот. И как с остальными командами, которые занимаются: легаси г..ом, сервисами перекладывания "json", и в т.ч. где "джуны, стажёры, токсичные авторитеты и другие интересные кадры "
Varowlord4
06.02.2026 01:25Токсичные авторитеты любой скрам превратят в балаган, тут не процессы нужны, а жесткие кадровые решения. Никакой диаграммой Ганта токсичность не лечится
event1
06.02.2026 01:25А как управлять командой, где есть джуны, стажёры,
Над ними берут шефство опытные разработчики
токсичные авторитеты и другие интересные кадры
Этих надо держать в узде. Всё-таки, руководство — это не про даш-борды, а про людей.
vanxant
06.02.2026 01:25Да, и добавим сюда более реалистичные условия, чем "делаем никому не нужную хрень с нуля и без внешних сроков". Ну там постоянный поток багов, легаси, обязательства по срокам перед заказчиками/инвесторами и прочие милые особенности реального мира.
Ivan22
06.02.2026 01:25джунам помогает тимлид и лично следит без всякого скрама как они развиваются. "токсичные авторитеты" вообще наоборот получают буст к токсичноси при наличии всяких ритуалов скрама
monco83
06.02.2026 01:25Из всех скрам-церемоний я на самом деле положительно отношусь к дейликам и, как ни странно, к ретро. Сейчас и так все на удалёнке, никто никого не видит, общение, хотя бы по звонку, полезно. С Ретро то же самое.
Груминги постановок с командой, общекомандные демо - тоже полезные практики, но прибито ли это гвоздями к пресловутому "скрам-процессу"?
Спринты, с моей точки зрения, имеют смысл только тогда, когда они привязаны к релизам. На этапах R&D, MVP это просто бесполезная церемония.
Оценки не имеют смысла никогда. Будучи тим-лидом я мог оценить скорость доставки фичи плюс-минус палец без всяких циферок, просто понимая степень проработанности постановки, сложность открытых вопросов и валовой объём работы. Гадание на сторипойнтах точности не прибавит. И я совершенно согласен с посылом автора, что вся эта скрам-история - это создание иллюзии контроля для менеджеров среднего звена и красивых отчётиков для бизнеса.Ndochp
06.02.2026 01:25ИМХО, если задача не зашита под разработчика, который уже давно в теме что и как он будет делать, то гадание на сторипоинтах позволяет убедиться, что все понимают задачу одинаково, что никто из команды не видит подводных камней. На покере как раз сталкиваются взгляды "построим кастомизируемый механизм, заложим фундамент на его развитие на годы вперед" против "ну эту мелкую хотелку можно подпереть костылем за пол дня работы"
Ivan22
06.02.2026 01:25без всякого покера когда создается задача в ней тим-лид пишет описание как минимум вида "заложим фундамент на его развитие на годы вперед" либо "ну эту мелкую хотелку можно подпереть костылем за пол дня работы"
Ndochp
06.02.2026 01:25У нас аналитики пишут. Что-то типа "надо чтобы пользователю был виден статус документа" А дальше можно завести реквизит статус, и пусть проставляют что хотят, а можно сделать интеграцию с ЭДО и подтягивать статус оттуда. Причем сделать красиво, не для одного документа естественно, а с возможностью подключения любого.
Ivan22
06.02.2026 01:25Аналитик пишет бизнес-смысл, тим-лид или даже архитектор ревьювит и добавляет технических деталей. И все, никакой самодеятельности. А вопрос интеграции с ЭДО это 100% решение архитектурнное, которое я например как архитектор, никогда не доверяю девелоперам. (Иначе начнется хаос)
monco83
06.02.2026 01:25После декомпозиции тим-лидом задачи имеют уже достаточно определенную постановку. Если под задачей подразумевается постановка от аналитика, которую ещё и читало пол человека до планирования, вот тогда, да, остаётся покер или другие виды гадания.
victor_2004
06.02.2026 01:25Оценка помогает приоритезации. Когда ты приходишь к бизнесу и говоришь - у нас тут 100500 задач, в каком порядке брать? И понимая размер задачи бизнесс может захотеть что-то в первую очередь пропихнуть, что-то во вторую.
aiminkai
06.02.2026 01:25Вообще не понимаю сторонников отмены оценки. Особенно со стороны тимлидов. Рассуждения уровня хобби.
Как бизнесу (заказчику) понимать, как быстро он получит что-то, что ему настолько важно, что он готов платить немалые деньги?
Да, оценка это пальцем в небо. Но лучше уж так, и продать её (вернее труд команды), а потом обосновать почему больше. Чем сказать: мы беремся, но сроков нету, собирать метрики работают ли вообще в команде не будем, но хотим 2млн в наносек. Каждому.
monco83
06.02.2026 01:25Бизнесу интересна оценка не задач (юнитов для MR), а фич.
Оценка скорости доставки фичи определяется в первую очередь ясностью хотелок и проработанностью постановки.
Так что и без всякого покерного гадания я могу сказать, что вот в этой фиче всё понятно, за две недели сделаем, а тут такая куча подводных камней, что оценку давать бессмысленно.
iNaps
06.02.2026 01:25Хорошо, на 4 месяца энтузиазма и мотивации точно хватит, когда команда пилит новый продукт. Все заряженные и неуставшие. Но что дальше? Когда продукт в виде uikit будут использовать множество команд, ставить свои сроки фич и требовать быстрого фикса багов? Тут придётся прикручивать процессы
Ainyru
06.02.2026 01:25SCRUM это скам над Agile. Если скам убрать, то получатся то самое, что задумывали отцы-основатели (читаем манифест).
positroid
06.02.2026 01:25Из личных наблюдений - перешел с работы с отчетами по часам и оценками задач на обычный канбан без оценок и заметил, что стал работать эффективнее.
Просто потому, что если ты дал оценку в 10 часов с рисками, её все согласовали, а ты сделал работу за 5 часов - нет никакой мотивации сдавать задачу сильно раньше.
Отчасти это, конечно, из-за отсутствия нормальной системы мотивации и оценки перформанса, но все же.
kenomimi
06.02.2026 01:25Бесполезной управленческой единице надо показать и доказать свою нужность перед вышестоящим начальством. Оменно отсюда вылезают почти все метрики. Бездельник наводит суету, но, поскольку высокое начальство за матчасть своих подчиненных не шарит - у них свои задачи, оно принимает пустопрожнюю мышиную возню за реальные производственные процессы. Если взять и проверить, чего за пузомерки мы считаем - две трети менеджеров вылетят со свистом. Та же история в чиновничьем аппарате, например.
Как только мы начинаем что-то измерять, и это измерение начинает влиять на зарплаты - будте уверены, большинство работников сразу переключится с основной цели на накрутку/закрытие показателей. И если, например, на заводском конвеере можно точно синхронизировать цели и метрики - процент брака, количество деталей в час, и так далее - то в разработке считать нечего, почти все метрики там искуственные, не отражающие реальность в полной мере. Тут для оценки нужен менеджер, который сам разбирается в матчасти, чтобы понять, какая команда проседает, где есть проблемы, и всё в этом духе...
Scrum нужен и удобен там, где много задач, которые после декомпозиции по объему меньше или равны длине спринта. То есть никаких монолитных RnD на полгода, никакого рефакторинга одной фичи на пять спринтов, и прочего - только то, что мы можем адекватно разбить на подзадачи. И опять же, никаких сторипоинтов - задачи распределяет живой человек, и спрашивает статус на дейликах по ним тоже живой человек.
Дейлики и прочие встречи не чаще раза в день (лучше через день-два, зависит от задач) - хорошо, так как на удаленке очень важно понимать, что делает коллега. Встречи чаще раза в день, и больше часа - уже рак и трата времени. Если команда настолько большая, что каждый не успевает за час высказаться - эта команда должна быть поделена на части.
Iustinianus
06.02.2026 01:25Разработка радиоэлектроники. Работал по системе с ежедневными отчетами... месяца три, наверное. Как итог:
При постановке задачи требуемый срок в голове умножал на два и орал, как контуженная чайка, что даже в этот срок укладываюсь только с мотивацией и загрузкой 146%.
Рабочий день закончен - adios, amigos, через 9 часов и 30 секунд после утреннего логина на свой ПК никакой силой меня не удержать на рабочем месте, ибо отчет за день готов и отправлен.
Нужно надуть себе атомарных задач, чтобы отчет выглядел солиднее? Нет никаких проблем, я-то на каждый клик мышкой в САПР могу написать предложение, которое этот клик превращает в самостоятельную задачу. Учитывая, что административный персонал термины "импеданс", "диаграмма Смита" и "децибел относительно милливатта" понимал ещё хуже, чем я SCRUM и AGILE, проблем никогда не возникало.
Так и не смог придумать, к каким задачам отнести те 15 минут в день, что я ходил, простите, пописать и покакать. Размазывал (ой какой плохой каламбур вышел...) по остальной "воде".
На написание отчета уходило от 15 до 30 минут, с учетом п.2... Эффективность зашкаливала.
microtheft
06.02.2026 01:25Так и не смог придумать,
Тут все придумано. Нужно писать: "Расти над собой - 15 мин".
gnomeby
06.02.2026 01:25Ладно спринты, я юнитесты убрал для малых проектов и тоже ничего не сломалось. А разработчики стали тщательнее тестировать. Правда ничего и не улучшилось, только стало меньше переключений контекста.
Artyomcool
06.02.2026 01:25Ну я тесты пишу как раз чтобы тестировать. Для меня это быстрее и проще, а то, что после меня остаётся артефакт - это приятный бонус.
Varowlord4
06.02.2026 01:25У меня была супер-мотивированная команда, которую мне позволили набрать самому
C таким чит-кодом любой менеджер будет эффективным, а попробуй выдать результат с теми, кто есть: с уставшим мидлом, джуном, который боится комитить, и сеньором, которому все надоело. А с "командой мечты" можно и в баре планирование проводить, результат будет отличный
vital_pavlenko Автор
06.02.2026 01:25Уставшего мидла заменяем на свежего и бодрого
Джуна уже заменила нейронка
Синьеру тоже предлагаем найти место, где ему будет веселее, может тогда и интересно сразу станет
А если серьезно, то такую команду в целом ничего не спасетmonco83
06.02.2026 01:25В большинстве контор есть куча реальных, годами не разгребаемых проблем, которые являются реальными причинами и усталости мидла, и безразличия сеньора. Проблемы остаются всё теми же, а графики agile с годами становятся всё краше.
mSnus
Задачи, которые можно быстро закрыть, выдаются как приз тем, кто хорошо работал на долгих задачах