Agaltsov Anton | TeamLead-блог

👥 Оффер и переговоры о зарплате: сделка шире, чем оклад Оффер в узком смысле — формальное предложение о работе: должность, оплата, дата выхода. В широком смысле — совокупное ценностное предложение (Total Rewards): всё, что человек получает от компании в обмен на свой труд и время. Это понятие расширяет переговорное поле: при ограниченном бюджете на оклад сделка может состояться за счёт других компонентов — гибкости, обучения, скорости пересмотра. Пакет раскладывается на пять компонентов: фиксированная часть, переменная, долевое участие, бенефиты и условия работы. Один и тот же бюджет упаковывается по-разному, и воспринимаемая ценность различается: вариант «всё в окладе» выбирают те, кто не доверяет неденежным обещаниям, вариант с долей и грейд-планом — те, кто готов обменять часть денег сегодня на рост в будущем. 💡 Презентация оффера — управляемый разговор, а не письмо с цифрами. Оффер проговаривается голосом: только так видна реакция и слышны сомнения. Письмо фиксирует договорённости, но не заменяет разговор. Когда ожидания выше доступного предложения, дельта закрывается гибкой сборкой пакета (flexible package) — часто дешевле прибавки к окладу и с большим эффектом для человека. Самый недооценённый резерв — бенефиты и условия: они нередко стоят компании дешевле, чем оцениваются человеком. ⚠️ Антипаттерны: обещания без полномочий (невыполненное обещание демотивирует сильнее отсутствия), уступки без обоснования (разгоняют зарплаты внутри команды) и пересмотр «финально согласованного» оффера перед выходом. В IT удалёнка давно гигиенический фактор, а не бенефит. Дифференцируют предложение конкретика задач, скорость решений и честность коммуникации. 🔗 https://agaltsovav.ru/docs/people-managment/offer-and-salary-negotiation/

🏗️ DDD: код, который говорит на языке бизнеса Domain Driven Design — подход Эрика Эванса (2003), в котором первичной движущей силой проектирования выступает не код и не тесты, а предметная область. Модель бизнеса выражается через единый язык (ubiquitous language) и воплощается прямо в коде: любое расхождение между тем, как понимает домен эксперт, и тем, как это закодировано, трактуется как дефект модели. Если цикл TDD — Red-Green-Refactor, то цикл DDD другой: исследуй домен → построй модель → закодируй → уточни язык → повтори. Тесты не исчезают, но перестают быть первичным драйвером — первична модель. ⚠️ Распространённая ошибка — применять тактические паттерны (агрегаты, репозитории, доменные события) без стратегической работы над границами контекстов. Итог — технически «правильный» код, который моделирует не тот домен или делает это в неправильных границах. 💡 DDD — инвестиция в понимание сложной предметной области, а не способ писать код быстрее. Эффект проявляется на горизонте месяцев и лет, когда модель начинает работать на команду, а не сопротивляться каждому изменению. 🔗 https://agaltsovav.ru/docs/development-managment/ddd-domain-driven-design/ ENDOFPOST && ssh agaltsovav@100.64.0.4 wc -c /tmp/tg-post.txt

📋 Управление рисками проекта: превратить неопределённость в план Риск в проектном управлении — это событие × вероятность × влияние. Уже случившееся событие — проблема, а событие с нулевым влиянием — шум. Риск при этом не только угроза, но и возможность: с PMBOK 6 неопределённость официально разделена на угрозы и возможности, и зрелый риск-менеджмент работает с обоими хвостами распределения. Инструментальный минимум — реестр рисков и матрица «вероятность × влияние». Реестр ценен не как список страхов, а как план действий: у каждого риска есть владелец, триггер и стратегия реагирования. Для угроз — избегать, смягчать, передавать или принимать; для возможностей — использовать, разделять, усиливать. 💡 Управление рисками — непрерывный цикл, а не упражнение на старте: риски рождаются и закрываются, реестр живёт вместе с проектом. 🔗 https://agaltsovav.ru/docs/project-managment/project-risk-management/ ENDOFPOST && ssh agaltsovav@100.64.0.4 wc -c /tmp/tg-post.txt