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

Пока ощущение, что ничего не работает, мы обречены, сроки не оцениваются, в дедлайны не попадается! Ужас!

Бизнесу вообще-то надо знать, когда примерно будет готово. Ну знаете, маркетинговые компании там, субсидирования проектов, планирование ликвидных средств — вот это вот всё. А мы такие: мы программисты, профессия творческая, вот посмотрите — quant valerian написал, что ничего не работает!

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

Наконец-то закончился период сдачи задач на SRE Week от Школы Анализа Данных. Это был интенсив, где за неделю показали всю суть ШАДа. Прочитали несколько лекций, а потом дали задачи. Ощущения в целом, как на картинке с совой. Но мне понравилось.
Скоро напишу пост, как я решал задачи (про то, как планировать проекты тоже напишу), как только найду полчаса с живым мозгом.
А пока предлагаю посмотреть задачки здесь https://gitlab.sreweek.ru/sre/sre-week

Задачи с SRE Week делились на три блока: bpftrace, binary-search и "sre". Я начал с бинпоиска, потому что "щас я вам покажу, кто здесь перфоманс инженер", вот почему.

Первая задача — моя любимая. Поиск в маленьком массиве (не более 100 интов). Я думал, что просто сделаю линейный проход, бранчей не будет, по памяти всё хорошо — зайдёт. Но не тут-то было! Впрочем, задача всё равно оказалась довольно простой: в условии упоминается, что для решения доступны AVX2. Просим chatGPT написать линейный поиск на AVX2 — есть решение. Не то, чтобы там был какой-то сложный синтаксис, но я его, конечно же, не помню. А тут получите, распишитесь.

Следующую задачу я решал часов пять. Нужно было искать в отсортированном массиве интов, размером от 256 до 2^16. Ха!, — подумал я, — это же просто galloping binary search! И снова оказался не прав. Я снова попробовал векторизовать, уже galloping binary search (тут chatGPT не справился совсем) — не хватает скорости. Переуложить массив в eytzinger точно дольше, чем поискать один раз. chatGPT снова бессилен.
Путём гугления в яндексе я обнаружил статью на хабре. Действительно, бранчлес версия бинпоиска залетела, как нож в масло. Вкратце: мы храним только начало и длину окна, тогда на каждой итерации либо двигаем начало, либо просто уменьшаем размер окна; единственная операция сравнения тогда будет в условии цикла.
Side note: я пробовал написать бранчлес версию сам (до того, как нашел статью). Реализация через тернарники не работает. Реализация через арифметику над булами тоже не работает. perf'а у меня на виртуалке толком не было, поэтому я не знаю, в чем причина.

Третья задача в общем-то ничем не отличается от второй. Нужно искать в больших массивах (2^16 - 2^20 интов). Всё, что нужно сделать — добавить префетч к решению второй задачи. Реализация с префетчем есть в той же статье на хабре. chatGPT просить не пробовал :)

Дальше я взялся за задачи блока sre. Самое мне понятное — single producer single consumer queue. Я просто попросил chatGPT написать на C++ на слабых мемори семантиках spsc очередь. Он выдал достаточно лакончиный и рабочий код на кольцевом буфере. Там зачем-то был лишний массив, как член класса, но его было легко удалить. Локально эта реализация проходила тесты, но вот в контрольной системе — нет. Тогда я вкрутил самую попсовую оптимизацию: заменил остаток от деления на логическое И (предварительно захардкодив размер буфера в степень двойки: 2^15). И НЕ ЗАШЛО! АХАХАХАХА. Я поменял размер буфера на 2^16, и тогда зашло. Не ищите здесь логику. Дело в том, что тесты в контрольной системе ОЧЕНЬ шумные. Мог ничего и не менять, короче.

Разделавшись с очередью на раз-два-три, я взялся за задачу retry. Тут мы сталкиваемся с golang. Там есть клиент и сервер. Сервер падает на произвольное количество времени, потом поднимается. Клиент должен:
1. Не просыпать ни одного запроса
2. Поддержать RPS не более, чем x3 от нормы
3. Поддержать тайминги не более, чем х4 от времени недоступности сервера
Я сначала придумывал хитрые алгоритмы отображения отрезков одной длины в отрезки длины х4, но минут через 20 понял, что надо просто написать рейт-лимитер. Я попросил chatGPT написать мне тупейший рейт-лимитер на скользящем окне (никаких вам лики бакетов и подобного), прям с мьютексом, не выдумывая ничего. Настроил рейт-лимитер на параметры условия задачи. И зашло с первой попытки.

Далее я взялся за задачу traces. Я её так и не сдал. Условия там замудренное, но по-сути нужно научиться склеивать спаны в трейсы, находить самые нагруженные участки и репортить их. Извините за мой французский. Условие было довольно нечеткое, много белых пятен и неоднозначностей. Я сразу же, не думая, скормил его chatGPT. Тот выдал довольно понятный, но прям _очевидно_ неоптимальный код на golang. А, да, он еще и не работал. Даже на скормленных примерах. Я надолго откладывал эту задачу в пользу более интересных bpftraces, однако, вернулся к ней после всего. Мне удалось дожать версию нейронки до состояния, когда она падала по таймауту на последнем тесте. Правда, для этого пришлось реверс-инжинирить первый тест на сервере (печатал его данные в выхлоп, чтобы посмотреть в логах CI).
Когда я переделал алгоритм на сильно более оптимальный вариант, я его сломал 🤡 Теперь оно падает где-то на 35-м тесте. СОВРЕМЕННЫЕ ЧУДО-ТЕХНОЛОГИИ МЕНЯ НЕ СПАСЛИ! Ура! Нас не заменят! Хорошо, что я менеджер.

Дальше было самое мясо. Я вообще не знал, как пользоваться bpftrace. Поэтому уже на первой задаче (оттрейсить, какая программа и сколько пишет на диск) я пошел спрашивать chatGPT, чтобы научила меня писать скрипты для bpftrace. Оказалось, что тула очень сырая, некоторые синтаксические конструкции из доки не работают на многих версиях. Но с грехом пополам и one-liner'ами с сайта Брендона Грегга я разобрался. Первая задача залетела минут за 20.

Примерно в этот момент объявили, что для получения сертификата необходимо набрать 1300 баллов. Это означало, что нужно обязательно сдать либо traces, либо bpftrace-3 (самые дорогие задачи). Поэтому, я тут же взялся за bpftrace-3. Это просто мозги в фарш, ребята. golang, функция-член структуры принимает аргументом указатель на структуру из инта и строки (строка в голанге это инт и массив байт, не 0-terminated, как в Си). Нужно собрать все вызовы, для каждой строки из аргументов сложить числа.
Не, ну так-то изян. НО ЭТО ГОЛАНГ! ChatGPT здесь выдает вообще не рабочие варианты. Брожение по документации bpftrace — тоже. Более того, там есть misleading обсуждения, что в голанге calling conventions разные в разных версиях (то на стеке, то в регистрах), но ни одна из этих версий у меня не сработала.
Я уже и таблицу символов всю до дыр просмотрел, уже и научился правильно трейсить такие методы (например, u:main:* не сработает, а вот u:./main:* — да 🤡), если хотите потресить метод, у которого в названии скобочки и звездочки (голанг же), то возьмите его название в двойные кавычки (u:./server:"main.(*Server).Serve"). И on-liner'ы ваше всё. Ничего не работает.
Пришлось расчехлять gdb. Там цепляемся к процессу, ставим брейкпойнт внутрь искомого метода, смотрим, че на стеке, че в регистрах, кастим всё к желаемому типу — находим аргумент в регистре rbx.
Далее в bpftrace скрипте читаем регистр, считаем смещения, собираем строку и вуа ля — нифига не работает, потому что регистра rbx нет. ebx, кстати, тоже. Вот вам знание, которого нет в интернете: надо читать регистр bx. Без префиксов. Тогда работает.

И на десерт я взял трейсинг мьютекса: какой трейс сколько держит лок (никогда так не радовался C++). Там всё просто, даже chatGPT не нужен. Если трейсите мьютекс. Но наивное решение не работает! Я битый час пробовал трейсить и lock (еще пойди научи bpftrace ловить деструктор!) и mutex. Несколько часов пытался понять, почему один из трейсов дублируется, хотя он ключ хеш-таблицы (это баг самой bpftrace). Оказалось, что я трейсил не то! Я считал время от момента входа в функция для лока (то есть вместе с ожиданием, когда лок станет доступен), а надо было трейсить выход! Это делается заменой u на ur.

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

Прям щас
Стрим Бушвакера
Средневековая Япония
Потом не говорите, что я вас не предупреждал
https://www.twitch.tv/bushhistory?sr=a

Так как планировать

На самом деле здесь есть несколько вопросов в одном. Будем разбирать по одному.
1. Как оценивать срок проекта?
2. Как спланировать проект (в смысле риск менеджмента)
3. Как исполнять сам проект? То есть как двигаться по проекту, вовремя определять риски и понимать с ними.

Я постараюсь напоить поменьше воды, но тема очень абстрактная. Поехали.

1. Сроки. Никто никогда не попадает в сроки. Это на самом деле очевидно, потому что срок это точка во времени (а время мощности континуум), иными словами вероятность попасть точно в срок равна нулю. Но это не возможное событие (вы почти наверное знаете о чем я, в этом то канале).

Но что тогда делать? Подумать! Что мы обычно имеем в виду, когда называем срок? Это какая-то точка, в которой скорее всего будет готово. Но с какой-то вероятностью будет готово раньше, а с какой-то позже. Более того, плотности вероятностей будут не линейны слева и справа от точки. Поэтому гораздо более честно будет называть несколько точек: будет готово через 7 дней с вероятностью 80%, через 8 дней с вероятностью 90%, через 14 дней с вероятностью 99% и т.д.

Да, это гораздо сложнее для других менеджеров (и вообще для людей, вероятности же), но на самом деле это гораздо честнее и позволяет более продуманно подходить к смежным активностям (маркетинг, лигал и т.п.). Кроме того, уже сам факт работы с вероятностями заставляет смежников заниматься управлением рисками. Петя из юр отдела послушает вас и подумает: "хм, если через неделю будет готово только с вероятностью 80%, то стоит поуправлять ожиданиями той стороны и заложиться в контракте на просрочку".

А как оценивать эти вероятности?
Начнём с того, что задачи делятся на две фазы: НИ и ОКР.
Вот НИ оценить очень сложно. Зато его можно задать! Мы можем управлять ползунком между качеством придуманного решения и временем, затраченным на его изобретение. Топорные решения обычно можно выдать за часы. Что-то поумнее требует больше времени. Вот ставьте дедлайн: думаешь не дольше, чем Х времени, потом приносишь, что надумал.

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

Для нас с вами, любителей дата дривен всего (хотя я тут совсем не фанатик), у меня есть бонус-трек. Если вы работаете MOVE'ами, если у вас уже есть какая-то история такой работы, то у вас есть статистика. У меня, например, есть прям графики, где можно посмотреть, за сколько какой персентиль каких эпиков/сторей/move делается.
Вот мы недавно спланировали проект на квартал. Экспертная оценка (целились в 80% вероятности) совпала с оценкой по 85%% из статистики.

2. Про риски. Тут я никакой Америки не открою. Составляете табличку рисков (можете привлечь команду, например, через футореспективу "кораблик", добавить стандартные таблички из интернета, взять с прошлых проектов, попросить у коллег). Bowtie diagram вам в помощь (риск, вероятность, импакт, как предотвратить, что делать при реализации).

Отмечу только, что есть ещё один полезный взгляд на риски (и вообще на многие вещи, Брукс так на проблемы разработки ПО смотрит в no silver bullet).
Бывают случайные риски (кто-то заболел), а бывают системные/процессные (не знаю как назвать нормально) риски. Вот вторые бывает сложно заметить, но они самые злые, они жрут ваш фрупут постоянно, очень тихо чавкая. Это могут быть какие-то неэффективные коммуникации, ненужные бутылочные горлышки, размытые договорённости и т.п. Например, нужно всегда получать апрув на фичу от тимлида, который вечно занят на встречах — это вот оно. Или надо ждать викли, чтобы сообщить о проблеме — тоже оно.

Про третий пункт будет позже.

SCRUM это хороший инструмент для слабых менеджеров

Буквально все ритуалы скрама призваны угнетать пролетариат и снимать ответственность с руководителя. Давайте разбираться.

1. Планирование. Это встреча, где менеджер напихивает разрабам в спринт побольше работы, причём, если они не успели, то сами виноваты (неправильно оценили!), а если успели, то менеджер молодец — хорошо планирует.
Причём инфляцию стори пойнтов менеджеры стараются пресекать (как мы знаем из макроэкономики, зря), а меньше, чем в прошлом спринте взять нельзя. Поэтому ошибки в сторону недооценки задачи уплотняют спринт (в прошлый раз же успели 100 sp, давайте в этот тоже успеем), а ошибки в сторону переоценки караются (потому что менеджер выглядит плохо планирующим, ему неприятно).

2. Демо. Этот ритуал нужен для того, чтобы вызывать чувство вины и комплекс неполноценности у разработчиков, которые приболели, у которых проблемы в личной жизни или просто накопилась усталость. К демо нужно успеть показать, что ты молодец и хорошо поработал. Иначе будет неудобно "перед пацанами".

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

4. Груминг. Акт снятия ответственности с лида, переноса её на коллектив. Неверно выбрали приоритеты — МЫ виноваты. Ошиблись в оценке задач — ВЫ виноваты (разработчики). А вот если всё у команды идёт хорошо, то молодец менеджер, это же он всё настроил так хорошо.

5. Ретроспектива. Это либо поиск виноватых в предыдущих проблемах, либо способ заставить работников придумать, как их получше эксплуатировать. Зачем думать менеджеру, если может подумать команда!

А помните, был такой — семавер?
Ну вот он остался в Фетхие. Оказалось, что в Белграде такую штуку не найти! Но мои любимые коллеги в этом году подарили мне новый на день рождения ❤️
Привёз из Москвы в Белград турецкую вундервафлю и счастлив. Такие дела.

Держу в курсе.

Обещанная третья часть про управление проектами

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

Итак, у нас есть на самом деле уже спланированный и оценённый проект. Есть сроки с вероятностями, есть риск реестры. Есть диаграмма Ганта (мы по ней искали критическую цепь).
Начинаем работу!

Всё, наша диаграмма Ганта устарела и поплыла! Но не спешите её чинить, она нам больше не нужна.

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

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

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

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

Берём нашу оценку срока проекта (там уже есть обычно менеджерский коэффициент). Делим на 2. Очень грубо, здесь проходит 50% вероятности, что мы закончим проект к этому сроку. Про плотности вероятностей у меня был пост с Монте-Карло, я все ещё считаю, что здесь что-то примерно логнормальное.
Теперь, берём половину от этой половины. Это будет где-то 80% (3/4 времени, но распределение скошено влево). Эта четвертина будет нашим сигнальным буфером.

Каждый день мы смотрим:
1. Насколько процентов готов проект
2. Насколько процентов использован буфер
Делим второе на первое. Это наш индикатор проблемности! У него есть лаг длиной с первую половину проекта, но если это долго, то можно брать промежуточные майлстоуны.

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

Начинать искать причины проблем в проекте нужно уже на жёлтом. На красном нужна уже не профилактика, а лечение.

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

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

PS:
Нигде в тексте не пришлось к месту важное замечание. Чем дальше во времени ваши планы и задачи, тем более они размыты, тем менее специфицированы. С появлением новой информации (в т.ч. требований) может меняться будущее проекта. Его можно вообще остановить. Отсюда сразу можно делать вывод, что детальные планы нужны максимум на одну итерацию вперёд. Остальное больше для оценки и задания направления.
И это ещё один повод вспомнить, что мы не исполняем план, мы решаем задачу.

У меня сегодня контент-бомба!
Вы знаете, что я про Яндекс не пишу вообще ничего. Но вот на каналы и посты коллег ссылаюсь регулярно! Оказалось, что существует огромная папка с каналами
яндексойдов. Там можно найти контент и про компанию, и про разработку, и про менеджмент, и про ML и ещё кучу всякого, в чем я не разбираюсь 😁.
Забирайте папку, выбирайте себе любимчиков, читайте!

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

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

Ближе к окончанию тренинга у нас случилось упражнение pvp. По легенде сейлз покупал у меня ноутбук. Я довольно неумело торговался, но в конечном счёте договорился на больше, чем был обозначен минимум в моём задании. Но после раскрытия моим визави своей легенды, я был обескуражен. Он прожал меня ОЧЕНЬ сильно внутри своих границ допустимости (ну и внутри моих тоже). Я несколько расстроился, подумал, что всё-таки это не моё, с людьми работать, переговоры вести.

Но на общем сборе оказалось, что только две пары из шести или семи вроде смогли о чем-то договориться и заключить сделку. То есть я попал в 15% УСПЕШНЫХ кейсов! Просто вау!

Так что же в переговорах необходимо, чтобы прийти к соглашению? Контринтуитивно, но нужно в самом начале обсудить все no go пункты. То есть вы сразу, не пытаясь придержать информацию и что-то на этом выгадать, должны выдвинуть must требования. И получить такие же с другой стороны. Если они конфликтуют, сделки не будет — не стоит тратить время. Если конфликта нет, начинаем торговаться, но мы _уже_ знаем, что сделка возможна. И с большей вероятностью эту сделку мы заключим.

Как это сделать?
1. Не показывать нужду. Оно же право на нет. "Если вас не устраивает цена, можете искать другого продавца, ничего страшного"
2. Говорить нет не предложения, которые вам не подходят. Да и вообще на первое предложение. Это создаёт конструктивный лад, так как вторая сторона теперь хочет понять, что нужно, чтобы нет превратилось в да.
3. Снова право на нет. Вы предлагаете Х, но говорите, мол, нет так нет, никаких обид. Если это принципиальный пункт, вы услышите нет.

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

В чате писали, что не могут со мной связаться, поэтому я сделал бота для обратной связи @QuantValerianBot
Инжойтесь

А чтобы пост не был совсем уж бесполезным, вот вам примерно контекст последнего поста (где я писал, что вокруг все внезапно заговорили про переговоры)


Книга Кэмпа "Сначала скажите нет", мы читаем в книжном клубе

Третья глава книги "Путь камикадзе" про переговоры вокруг безнадёжных проектов

Коллега из лавки про переговоры https://t.iss.one/leadsnotes/55

https://youtu.be/1xJVYAVdrUY?si=0rlLFlkd2_G7dqnj подлодка про зарплатные переговоры (я больше рекомендую более старый выпуск с тем же гостем)

https://youtu.be/gs4NoXwXCEE?si=Pocft1aksG9ypN84 Бреслав и Ложечкин про переговоры в корпорациях

https://youtu.be/IwsdeH3SUQ4?si=9WHwJmgumDAvF9fb мультик про переговоры с иностранцами

Плюс подлодка ещё очередную мини конференцию стартовала про переговоры и теперь везде их реклама))

А ещё я машину продаю, кстати

Ключевые принципы успешных переговоров по Кемпу

Выдаю вам лютую базу, собранную мной из разных источников информации о ведении переговоров.

1. Контролировать чувство нужды, скрывать его. Давать визави право сказать "нет". Если вы будете цепляться за сделку или какое-то условие в ней, а та сторона это поймёт, из вас выжмут максимум по все параметрам, угрожая отобрать пункт, в котором вы нуждаетесь.

2. Позволять визави чувствовать себя "в порядке". Не стоит строить из себя акулу переговоров, какого-то переговорного мачо. Это некомфортно собеседнику, он с меньшей охотой будет идти вам на встречу. Кроме того, он будет все время ждать какого-то подвоха, а возможно даже скрывать какие-то важные вещи. Лучше вам самим быть "не в порядке", т.е. немного не в себе, что-то забыть, где-то запутаться и т.п. Будьте комфортным.

3. Не бояться говорить и слышать "нет". Слово "нет" выводит на конструктив. Вам что-то предлагают, вы отвечаете "нет". Именно в этот момент визави начинает выяснять, почему именно нет, здесь начинаются переговоры по-существу. Если вы скажете "да", то дальше уже проще вам досыпать деталей, вы же уже согласились! Если скажете "может быть", это вообще не дает никакой информации и никуда вас не движет. Говорите "нет".
Быть готовым услышать "нет" это снова про первый пункт. Вы не должны нуждаться. Нет так нет, договоритесь с кем-то другим или в другой раз. Поощряйте собеседника говорить "нет", таким образом вы вынуждаете его принимать решение. Если он не готов сказать вам "нет", то автоматически должен уже сказать вам "да".

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