Вася Латышев про рост и развитие

Чему можно научиться у ИИ Нейросети и разного рода ИИ-агенты делали люди. Очень умные люди. В результате ИИ-решения впитали в себя лучшие подходы к решению задач и достижению целей. Вот, что мне нравится больше всего: 1. Работа до цели Суть в том, что ИИ-агенту задаешь цель с правильным определением параметров ее достижения и говоришь работай. И искусственный интеллект продолжает совершать операции до тех пор, пока не достигнет результата. И неважно, сколько времени ему для этого потребуется. Он всегда в великолепном настроении :) У него нет переживаний. Он не устал. Его ничего не отвлекает. Он просто фигачит)) Чему тут надо учиться - в своей ежедневной работе мы заранее должны понять, чего на самом деле хотим, т.е. учиться четко расставлять приоритеты и фокусироваться. Мозгу важно знать как выглядит конечный результат. И по каким параметрам мы поймем, что цель достигнута. Когда образ конечного результата понятен и шаги определены - мозгу проще сфокусироваться на достижении результата и быстрее достигнуть цель. 2. Контекст решает все Один и тот же модель на плохом промте дает плохие результаты, на хорошем - блестящий. Модель не тупая, ей просто не дали вводных: зачем, для кого, какие ограничения, что уже пробовали. Чему тут надо учиться - мы ставим задачи людям ровно так же плохо, как пишем плохие промпты, аля сделай нормально. Хороший руководитель = хороший промпт: цель, контекст, ограничения, критерии приемки. И обратная сторона - самому не стесняться спрашивать контекст, а не додумывать. Тут в помощь инструкция по сделыванию и преза по корп.культуре, которую я делал еще в 2023 году. 3. Ошибка это сигнал, а не провал Вся суть обучения моделей - быстрая петля: попробовал → получил оценку → скорректировал. Миллионы итераций. Чему тут надо учиться - короткие циклы обратной связи вместо больших релизов. И спокойное отношение к неудачной итерации. 4. Мой любимый: сначала разобраться, потом делать У любого нормального кодинг-агента есть четыре фазы: исследуй → планируй → пиши → фиксируй. Разработчики Anthropic прямо рекомендуют этот порядок. Причем агенту прямо запрещают трогать файлы, пока он не изучил контекст и не показал план. Как это устроено внутри: Исследование. Агент сначала читает код: какие файлы затронуты, как устроены зависимости, где вообще место для изменения. Ничего не пишет. План. Формулирует пошаговый подход и показывает его тебе на согласование. Это самая дешевая фаза по затратам и самая ценная по результату: правки в план стоят копейки, правки в готовый код стоят дорого. Код. Только теперь пишет по согласованному плану, сверяясь с окружающим кодом. Проверка и фиксация. Прогоняет тесты, отдельный агент-ревьюер смотрит на результат до коммита, и только потом собирается коммит. А если один и тот же затык повторяется, решение записывается в проектный файл памяти, чтобы в следующий раз не наступать на те же грабли. Чему тут надо учиться - многие разработчики обычно делают наоборот - сразу бросаются делать, а разбираться начинаются находу, по мере написания кода. Фаза исследования кажется бесполезной: ничего не происходит, ничего не двигается. В этом и смысл. Правка в плане стоит десять минут, правка в готовом решении - две недели. Да и после исследования может оказаться, что задачу делать не надо (во время моего отпуска случилось 2 кейса, когда разработчики хотели начать делать то, что уже было сделано или нужно было решать по другому, пришлось останавливать)

Про ИИ-трансформацию в компании ИТ-гигианты активно продвинулись в ИИ-переходе: яндекс запускает программу 75-75-75, Авито еще в начале года объявили о внедрении AI-First подхода. У меня в компании ИИ-переход идет не системно. Поэтому на 3 квартал я себе в KPI поставил задачу связанную с ИИ-трансформацией. Хочу написать несколько мыслей на этот счет. У многих есть ложные ожидания, что ИИ "сам" сделает бизнес лучше, а вас супер эффективным. Но ИИ - это усилитель, а не двигатель. Он не меняет бизнес сам по себе. Он усиливает того, кто уже знает, чего хочет бизнес. С опорой на этот тезис и понимая правила автоматизации бизнес-процессов можно сформулировать шаги к ИИ-трансформации: 1. Не хватайтесь за весь бизнес. Выберите ОДИН процесс Самый простой способ увеличить хаос до предела и перегореть - это в самом начале попытаться "внедрить ИИ во всё". Не надо. Возьмите одну область (например, поддержку клиентов или бухгалтерию), выпишите её по шагам, и у каждого шага честно отметьте две вещи — как часто это делается и рутина это или творчество. Плюс сколько времени шаг съедает у человека. Получаем простую формулу: частое + рутинное + дорогое по времени = первый кандидат на ИИ. Забирающие время и повторяющиеся задачи созданы для автоматизации. Творческое и редкое оставляем людям — и это отдельная зрелость: решить, что не автоматизировать. 2. Разберите процесс по косточкам. Выбранный процесс раскладываем в таблицу. Слева — процесс по шагам. Дальше — где утекает время и деньги. Дальше — что отдаём ИИ. Дальше — важное — что остаётся человеку (не всё нужно автоматизировать). И последняя колонка — метрика: как поймём, что стало лучше. (Смотри картинку к посту) Это первый кирпичик. Один процесс, разобранный по косточкам. Повторите это со своим отделом и у вас уже есть то, чего нет у девяноста процентов сотрудников.  3. Окупаемость — вот что отделяет красивую презентацию от настоящих результатов Процесс нашли. Теперь считаем окупаемость - три числа Утечка в месяц = часы рутины/мес × стоимость часа × объём Срок окупаемости (мес) = стоимость внедрения ÷ утечка в месяц Первое - сколько часов в месяц люди тратят на эту рутину. Второе - сколько стоит час их работы. Третье - умножаем на объём. Получаем, сколько денег в месяц утекает. Вычитаем стоимость внедрения - получаем срок окупаемости. Если процессов несколько - берите тот, где отдача на вложенный рубль больше. Дело не только в бюджете, а в людях. У каждого внедрения нужен владелец, который доведёт его до результата и удержит живым. Таких людей всегда меньше, чем денег - поэтому чаще именно это, а не бюджет, задаёт потолок. Нет владельца для процесса - не берите его, каким бы вкусным ни был ROI. Это база с которой можно начинать. А как вы подходите к ИИ-трансформации у себя в компании?

В предыдущем посте я рассказывал про книгу Гергели Ороша. В ней есть мысль про повышения: тебя повышают не за то, что ты хорошо делаешь текущую работу. Тебя повышают, когда ты уже стабильно работаешь на следующем уровне. Хорошо делать текущую работу - это baseline, как раз за это ты и получаешь текущую зарплату. Книга про разработчиков, но она легко перекладывается на любую другую роль, например, на менеджеров проектов: Джун - ведешь трекер задач, готовишь статусы, фиксируешь договоренности после встреч, следишь за дедлайнами отдельных стримов. Тебе дают четкий скоуп и ты его довозишь. Ошибки допустимы, но ты учишься быстро и одну ошибку не совершаешь дважды. Для перехода дальше нужно показать, что ты можешь вести небольшой проект от начала до конца без микроменеджмента. Начать замечать риски до того, как они стреляют. Мидл - декомпозируешь большие задачи, управляешь зависимостями между командами, фасилитируешь принятие решений (а не просто передаешь информацию), ведешь стейкхолдеров, сам понимаешь, когда план нереалистичен, и предлагаешь альтернативы. Умеешь говорить "нет" или "не сейчас" с обоснованием. Для перехода дальше нужно начать влиять не только на "как" (процесс), но и на "что" (скоуп, приоритеты). Браться за проекты с неопределенностью, где нет готового плана. Синьор - ведешь несколько параллельных проектов или один стратегически значимый. Умеешь работать в условиях, когда требования неясны, стейкхолдеры конфликтуют, а ресурсов недостаточно. Сам формируешь план, продаешь его руководству. К тебе ходят джуны и мидлы за советом. Твоя ценность: тебе можно отдать самое сложное и забыть. Лид - определяешь стандарты проектного управления в компании, внедряешь практики, которые масштабируются. Видишь проблемы на уровне портфеля проектов: ресурсные конфликты, стратегические противоречия, системные риски - и решаешь их до того, как они становятся кризисами. Работаешь напрямую с топ-менеджментом, переводишь бизнес-стратегию в конкретные бэклог работ. Между уровнями меняются две вещи: - масштаб: задача → проект → несколько проектов → организация - автономия: делаешь что сказали → сам решаешь как → сам решаешь что → формируешь повестку для других

За что на самом деле повышают зарплату На прошлой неделе я рассказывал своей команде про KPI: для чего нужны, как формируются, как считаются. После презентации пришло несколько человек с просьбой повысить ЗП или подключить к системе KPI. И каждый из тех, кто пришел - сделали это не правильно :) Я уже как-то писал, как подходить с повышением. Что сотрудник должен создавать доп.ценность для компании и расширять свою зону ответственности. А для этого должен понимать как работает бизнес: как обслуживает клиентов, откуда берутся доходы, на что тратяться деньги и так далее. И с учетом этого строить свое развитие - влиять на доходы, сокращать расходы, делать продукт качественным и ценным для клиента. У меня на столе лежит книжка Гергели Ороша - Разработчик ПО. В этой книге есть глава о повышение зарплаты. Хочу поделиться рекомендациями автора на этот счет. Большинство сотрудников думают так: Я хорошо работаю (конечно же по мнению сотрудника :)) -> меня должны повысить. Но реальность устроена иначе. Компании повышают не за то, что ты делаешь свою работу хорошо. Они повышают за то, что ты уже работаешь на следующем уровне. Вот что это значит на практике: Джун → Мидл. Перестаешь быть тем, кого нужно постоянно контролировать. Берешь задачу - и доводишь до конца. Не ждёшь, пока тебе скажут, что делать дальше. Сам пинаешь смежные отделы (тестировщиков, ревьюверов), чтобы протолкнуть свою задачу на следующий этап. Задаешь правильные вопросы вместо того, чтобы молча буксовать. Мидл → Синьор. Уже не просто решаешь задачи, а видишь проблемы, которые никто не поставил. Влияешь на решения команды. Менторишь других. Твой руководитель или менеджер перестает думать о тебе как о ресурсе и начинает думать как о партнере. Синьор → Техлид/Архитектор. Твое влияние выходит за границы команды. Ты формируешь технические решения на уровне продукта или компании. Люди приходят к тебе за советом не потому, что ты начальник, а потому что ты разбираешься. Что из этого следует? Не жди, пока тебе дадут возможность проявить себя. Начни действовать на уровень выше прямо сейчас: 🎯 Бери ответственность за результат, а не за таски 🎯 Делай работу видимой: пиши документацию, выступай на внутренних демо, делись выводами 🎯 Думай не "что мне поручили", а "что нужно команде/продукту" 🎯 Ищи проблемы, которые болят, но никому не назначены P.S. Книгу рекомендую почитать не только разработчикам, но всем кто взаимодействует с ними. Купить можно в Читай-городе.

Понравился пост из одного из каналов, на которые подписан. Прикладываю как есть: Отрубай это дерьмо В нашем деле запустить – это только половина. Вторая половина – это вовремя отрубить. Все вокруг говорят: запускай, тестируй, экспериментируй. Никто не говорит: останови это нахер, пока не стало хуже. А ведь именно это отличает тех, кто делает бизнес, от тех, кто тестирует гипотезы и набирается опыта. Примеры: Выкатил фичу, конверсия упала на 30%? Это не "нужно подождать данных". Это значит отрубай и разбирайся. Каждый час такой фичи в проде – это деньги, которые ты мог заработать, но не заработал. Запустил трафик, потратил штуку баксов, и купил на нее всего 50 кликов? Надо было отрубать после первой сотки, а не ждать, пока потратишь месячную зарплату рабочего в Гуанчжоу. Нанял человека, прошел месяц, а он до сих пор "разбирается в процессах"? Не разберется. Отрубай. Запустил канал трафика, льешь вторую неделю, ни одной оплаты? Это не "рано делать выводы". Это рынок тебе говорит – тут ловить нечего. Договорился о партнерстве, а партнер три недели не может созвон назначить? Не назначит. Отрубай и двигайся дальше. Почему люди не отрубают? Потому что больно решать, больно признавать, что решение было хреновым. Культура fail-fast должна быть развита не менее, чем культура быстрой разработки и итераций. Потому что каждый день, когда ты кормишь дохлую лошадь – ты не кормишь живую.

Как выбрать исполнителя Есть ряд признаков, которые помогают отличить подходящего исполнителя от негодного еще до начала работ. Вот на что стоит обратить внимание. 1. Был ли исполнитель полезен еще до заключения контракта, при обсуждении задачи? Получили ли вы от него дополнительные знания и/или развивающую информацию, которая улучшила ваше собственное понимание? 2. Оговаривались ли цели, результаты и сроки? Задавал ли исполнитель уточняющие вопросы? Корректировал ли ваши предложения? Хороший исполнитель помогает переформулировать цели, если они с точки зрения результатов сформулированы не вполне корректно. Он не берется за невыполнимые задачи – и в этом случае сможет показать заказчику, в чем его ошибка. "Это нельзя сделать, потому что… Так нельзя, потому что… Лучше вот так… Можно сделать так… Здесь мы поставим цели более амбициозные, у нас есть запас…". Если в разговоре появляются подобные фразы - это хороший знак. 3. Есть ли четкий ответ на вопрос, как именно будет достигаться поставленная цель? Если совсем упростить, то заказчик обязан ответить на вопрос "Что делать?", а хороший исполнитель на вопрос "Как делать?". Здесь и проходит граница их зон ответственности. Важный момент. Если заказчик будет каждый раз вмешиваться в процесс, пытаться управлять – ничего хорошего не получится. Нельзя лезть на "чужую поляну". Даже если ситуация критичная, не делайте за исполнителя, а помогите ему пойти в правильном направлении и понять вашу логику. Если исполнитель не отвечает на вопрос "Как делать?" или предложенные им способы и средства достижения результата вас не устраивают, то лучше поменять исполнителя уже на данном этапе. Ищите того, у кого есть четкое понимание, как решить задачу.

По мотивам пятничных посиделок В эту пятницу у нас был очередной архитектурный комитет. В ходе обсуждений, вспомнилась цитата из старой книги, название которой уже не помню. Технологии должны работать в интересах компании, а не программистов. Эта фраза звучит провокационно. Но чем дольше работаешь в индустрии, тем больше понимаешь её правоту. Знакомая ситуация? Команда выбирает новый стек. И аргументы звучат примерно так: - Rust сейчас на хайпе, давайте попробуем - Мне будет интересно поработать с этим фреймворком - Это круто будет смотреться в резюме А через полгода - сервис, который некому поддерживать, документация на китайском, и три человека в мире, которые понимают, как это работает. Даже некоторые контрагенты, когда приходят и продают свои продукты, хвастаются, что запили что-то на модном стеке. Недавно, одни товарищи продавали сканер безопасности и делали акцент на том, что он на Rust-е написан 😁 Но матерые CTO знают, что технология должна "настояться" прежде чем ее использовать в качестве основной. Например, Уилл Ларсон (его книжки можно купить в Читай-городе) продвигает концепцию "Boring Technology". Суть простая: каждая новая технология - это не бесплатный апгрейд, а долг. Её нужно изучить, отладить, найти грабли, обучить команду. Дэн МакКинли (экс-Etsy) написал эссе Choose Boring Technology. Его идея - у команды есть ограниченное количество "инновационных токенов". Потратил на базу данных - экономь на фронтенде. Кельси Хайтауэр (легенда DevOps) вообще говорит прямо: лучшая инфраструктура - та, о которой ты не думаешь. Но это не значит "никогда не учи и не пробуй новое" Это значит задавать правильные вопросы: - Решает ли это бизнес-задачу? - Кто будет поддерживать через 2 года? - Есть ли специалисты на рынке? - Что будет, если автор забросит проект? Технологии - это инструмент. Молоток не должен быть интересным. Он должен забивать гвозди. А какой самый странный выбор технологий вы видели "потому что интересно"? Мантикор/Темпорал? 🤪

8 способов увидеть плюс там, где кажется минус. Для тех у кого стакан полупустой Прочитал в одном канале, на который подписан, про рефрейминги, которые превращают проблемы в возможности: — Я ошибся → я купил ценный опыт — Всё завязано на мне → я нашёл узкое место — Ошибся при найме → стал лучше понимать, кто мне нужен — Клиент отказался → я не продал себя ниже рынка — Меня критикуют → я заметен — Конкуренты копируют → подтверждают, что мы впереди — Ушел сотрудник → освободилось место для более подходящего — Я сомневаюсь → я не действую на автомате

Про найм В одной желтой книге вычитал интересный лайфхак, который автор применяет на собеседованиях с кандидатами. Он предлагает дать выбрать кандидату одну из трех абстрактных картин. А дальше задать ему три вопроса по той картине, которую он выбрал: — Как вы думаете, как автор назвал бы эту картину? — Как вы думаете, что на ней нарисовано? — Как вы думаете, какую эмоцию хотел передать автор? Абсолютно не важно, как называется выбранная кандидатом картина на самом деле и что конкретно на ней изображено. Это абстрактная живопись. Нет какого то сюжета или эмоции. При этом, когда мы смотрим на абстрактную живопись и пытаемся описать ее, мы заглядываем внутрь себя и отдаем свою проекцию вовне. На этом, в том числе, строится Арт-терапия. По сути это тест Роршаха. Но если вы скажете кандидату, что он проходит тест Роршаха и попросите его рассказать, что он видит на кляксе, он захочет рассказать что-то, чтобы вы подумали о его внутреннем мире как можно лучше. Здесь тест Роршаха завуалирован, поэтому он расскажет вам что-то, что будет отражать его внутренний мир и текущее состояние. Тест Роршаха — это проективная психологическая методика, созданная швейцарским психиатром Германом Роршахом в 1921 году. Суть метода Человеку последовательно показывают 10 карточек с симметричными чернильными пятнами (5 чёрно-белых, 2 чёрно-красных, 3 цветных) и спрашивают: «Что это могло бы быть?» или «На что это похоже?». Психолог фиксирует ответы, время реакции, какую часть пятна человек интерпретирует, что именно определило его ассоциацию — форма, цвет, ощущение движения. Как это работает Поскольку пятна не изображают ничего конкретного, человек невольно «проецирует» на них своё внутреннее содержание — эмоции, конфликты, особенности мышления. Отсюда термин «проективный тест». Что оценивают Анализируются не столько сами образы («вижу бабочку» или «два человека»), сколько формальные характеристики ответов: насколько ответы типичны или уникальны, ориентируется ли человек на целое или детали, как реагирует на цвет и так далее. Это даёт информацию о когнитивном стиле, эмоциональной регуляции, контакте с реальностью. Сейчас много агентств, которые натаскивают кандидатов на успешное прохождение собеседование на ту или иную должность. И, как мне кажется, это очень интересный способ "встряхнуть" кандидата, чтобы оценить кем же он является на самом деле (хотя бы в психологическом плане). ChatGPT - сгенерировал абстрактную картинку к посту: — Как вы думаете, как автор назвал бы эту картину? — Как вы думаете, что на ней нарисовано? — Как вы думаете, какую эмоцию хотел передать автор? 😉

Про функциональные требования Я по несколько раз в день пишу в Claude требования к задачам, которые мне нужно решить. Бездушная машина обычно понимает всё довольно хорошо, даже может учесть некоторые вещи, которые я пропустил. Когда пишешь требования для "живых" разработчиков, дела обстоят сложнее: — Времени на написание требований уходит много; — В силу спешки и / или глубокой погружённости в контекст, часть требований опускается как очевидные; — Это приводит к тому, что исполнители неправильно понимают задачу или тратится много времени на разжёвывание. Какие же есть подходы, чтобы тебя понимали лучше и задачи решались эффективнее? User Story Формат: "Как [роль], я хочу [действие], чтобы [цель/выгода]" Классический agile-подход, фокусирующийся на том, КТО, ЧТО и ЗАЧЕМ. Простой и понятный, но иногда слишком привязан к конкретному решению. Пример: "Как покупатель, я хочу фильтровать книги по жанрам, чтобы быстрее находить интересующую литературу" Job Story Job Story это подход к описанию требований взятый из фреймворка Jobs To Be Done (JTBD). JTBD говорит о том, что люди "нанимают" продукты для выполнения конкретных "работ" в их жизни (например, зубную щетку нанимают на "работ": держать зубы в чистоте). В отличии от User Story, в JTBD фокус держится на контексте и мотивации, а не на самом пользователе. Это помогает понять глубинные потребности и найти неожиданных конкурентов. Формат: "Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]" Пример: "Когда я еду в командировку, я хочу взять что-то для чтения в дороге, чтобы с пользой провести время и отвлечься от рабочих мыслей" Use Case Более формальный и технический подход, детально описывающий взаимодействие пользователя с системой. Включает все возможные пути выполнения задачи, обработку ошибок и граничные случаи. Идеален для сложных систем и технической документации. Формат: Структурированное описание с элементами: - Название (цель) - Актёры (кто участвует) - Предусловия (что должно быть выполнено до начала) - Основной сценарий (последовательность шагов) - Альтернативные сценарии - Постусловия (результат) Какой выбрать? User Story — для простых задач в agile-командах Job Story — для продуктовой разработки с фокусом на контекст Use Case — для технической документации и комплексных систем

Про обязанности Когда я чувствую, что сотрудник начинает хуже справляться с задачами или результаты снижаются, я предлагаю сделать одно простое и одновременно сложное упражнение: составить список своих ключевых задач, должностных обязанностей и метрик эффективности. Лучше всего давать это упражнение сотрудникам уровня senior и выше. На мой взгляд, оно вводит человека в состояние осознанности. В этом состоянии сотрудник начинает ясно видеть разницу между тем, что он должен делать в рамках своей роли, и тем, чем он фактически занимается. Появляются важные вопросы: ❕ Как можно объективно оценить мою работу? ❕ Через какие метрики это измеряется? И, поверьте, даётся это упражнение далеко не так просто. После выполнения результат обязательно нужно обсудить с руководителем, чтобы при необходимости скорректировать ожидания, фокус или критерии оценки. А задачка со звёздочкой, это ответить на вопрос: "Какую дополнительную ценность я создаю для компании?" Но этот пост я хотел написать немного о другом. Сегодня утром, по дороге на работу, я слушал книгу "Книга для мужчин. Быть сильным и настоящим". В одной из глав, автор рассказывал про 25 обязанностей мужчины. Хотите, изложу их в следующих постах? Если да, ставьте 👍. Если нет 👎

Про книги Майкла Роуча Мне нравится читать книги с идеями, пришедшими из восточной философии. В прошлом году на январских праздниках я прочитал книгу Алмазный огранщик. Это книга буддийского монаха Геше Майкла Роуча, в которой он описывает применение древних тибетских принципов ведения бизнеса в современном мире. Центральная идея книги — успех в бизнесе достигается не через конкуренцию и агрессивные методы, а через щедрость, честность и помощь другим. Роуч предлагает систему "кармических отпечатков": правильные действия и мышление создают благоприятные условия для будущего успеха. В эти праздники я прочёл продолжение Алмазного огранщика — книгу Кармический менеджмент, которая детально раскрывает практическое применение буддийских принципов кармы в повседневном управлении бизнесом. Если честно, вторая книга давалась мне с трудом: я даже хотел её бросить, но в итоге дочитал до конца и считаю, что не зря. В праздничные дни я всегда провожу ретроспективу прошедшего года и ставлю цели на текущий. Поэтому мне особенно интересной показалась глава про целеполагание (которую я изначально неправильно понял и к которой пришлось возвращаться). Роуч разделяет желаемый результат (цель) и путь к нему (действия). Цель — это то, что мы хотим получить (рост прибыли, успешный проект, лояльную команду), но мы не можем напрямую заставить это случиться. Мы можем лишь создать причины для этого результата через правильные действия. Парадокс в том, что чем больше мы зацикливаемся на самом результате (тревожимся, напрягаемся, давим), тем меньше он к нам приходит. Вместо этого нужно сфокусироваться на ежедневных правильных действиях, которые создадут условия для достижения целей. Это снижает уровень стресса и одновременно формирует реальные предпосылки для успеха. Что же это за правильные действия — напишу отдельным постом завтра.

Карьера как бизнес 1️⃣ Ваша карьера - это ваш бизнес. Компания, в которой вы сейчас работаете - это ваш текущий клиент. 2️⃣ Поиск новой работы - поиск нового клиента или upsell (допродажа текущему клиенту). Вам нужно понимать: а) как повышать свою ценность, б) как найти своё отличие от тысяч других предложений на рынке, в) как донести до клиентов свои ценность и отличие. 3️⃣ Повышать ценность и углублять отличие от других - это не процесс быстрой упаковки на этапе написания резюме. Это длительный и затратный процесс улучшения того, что предлагает ваш бизнес. У вашего бизнеса есть один продукт - это вы. Улучшение себя для следующего клиента начинается с самого начала работы на текущего клиента. 4️⃣ Если воспринимать себя как продукт - можно воспользоваться механиками создания ценности, чтобы повышать свою ценность для клиента / работодателя. 5️⃣ Вам часто может казаться, что основную часть рабочего времени вы тратите на выполнение своих прямых задач - как, например, программист на программирование. Однако если заняться наблюдением и подсчётами, окажется, что существенная часть времени уходит на рабочее общение - с начальниками, коллегами, подчиненными, смежниками - и решение непрямых задач. Улучшение себя - это не только работа над своими профессиональными навыками, hard skills, но и работа над всем остальным, что называется soft skills: коммуникации, критическое мышление, организационные навыки, решение проблем и т. д. 6️⃣ Решение о приеме на новую работу по результатам интервью критично зависит от ваших soft skills, а не только hard skills. Уровень hard skills - это уровень отсечения неподходящих кандидатов, уровень soft skills определяет выбор наиболее подходящего кандидата из оставшихся. 7️⃣ Самый надёжный способ двигаться вверх по карьерной лестнице - брать на себя больше ответственности. Если вы будете дожидаться, когда вам предложат взять больше ответственности - вы лично можете этого не дождаться. Самый быстрый способ самому взять на себя больше ответственности - взяться за тот участок работы, за который не хочет браться никто другой.

О самом ценном Бывший CEO Coca-Сola Брайан Дайсон как-то сказал: Представьте, что жизнь - это игра, в которой вы жонглируете пятью шариками: Работа, Семья, Здоровье, Друзья и Душа. Вскоре вы поймете, что шарик Работа сделан из резины: если он упадет, то подпрыгнет и вернется обратно. Но остальные четыре шарика - Семья, Здоровье, Друзья и Душа - стеклянные. Если уроните их, они могут быть навсегда повреждены: надколоты, поцарапаны или даже разбиты. Они уже никогда не станут такими, как были. Поминте об этом и старайтесь не уронить самое ценное. С Новым годом, мои дорогие! Хочу пожелать, чтобы каждый новый день приносил вам счастье, здоровье, любовь и удачу! Пусть у вас всегда будет время на семью и друзей - дарите им яркие моменты и лучи радости! А самое главное - позаботьтесь о себе! Ведь лучшее, что вы можете сделать для счастья и благополучия людей рядом с вами - это работать со своим внутренним состоянием.

5 коротких тезисов про обучение 1️⃣ Хочешь научить — перестань учить. Помогай делать. 2️⃣ Не делает — отстань. Не делает — значит, не хочет. Не хочет — не научишь. 3️⃣ Как заставить захотеть? Никак. 4️⃣ Как объяснить, чтобы захотел? Никак. 5️⃣ Как дать возможность захотеть? Давать больше пробовать. Показывать больше примеров. Подходит для детей и сотрудников

Начинаем с малого Текст не мой, но он мне настолько понравился, что я его решил вставить как есть. ** Недавно прочитал историю про стартап с AI-девушками, в котором не было никакого AI. С одной стороны экрана сидели одинокие мужики, которые хотели пообщаться. С другой – другие одинокие мужики из африки, которым платили за то, что они притворялись AI-девушками. Все работало, все были счастливы, пока кто-то не спалился. Считаю, что так и надо делать, потому что начинать надо с малого, ведь главное – это просто начать. Запустился на костылях, проверил работает или нет, если работает – масштабируешь, если нет – выкидываешь. Без чистого кода и архитектуры, без дизайна, без даже имени проекта и собственного юрлица. Надо чтобы было настолько тупо и просто, что даже стыдно. Почему в этом сила: 1. Маленькие задачи ты точно сделаешь. 2. Маленькие шаги – всегда про действия, большие – про размышления и страх 3. Ошибки все равно будут. Легче будет, если каждая ошибка стоит неделю, а не полгода Все ждут идеальный момент, а надо просто взять и что-то уже сделать.

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

Про разработку с помощью ИИ Не технари не читайте :) *** Тысячу раз слышал "Мы попробовали [вставь_сюда_любой_ai_инструмент], ничего хорошего не генерирует". Знакомо? Современные LLM-инструменты для разработчиков работают в основном агентно: читают код, вызывают тулзы, делают серии шагов. Вся эта архитектура держится на одном хрупком месте — на "контексте" — на том, что именно модель видит в каждый конкретный момент. Один кривой TODO в середине кода может сломать всего агента: 1 ошибка приводит к 100 строчкам неправильного кода, а это ломает контекст следующей задачи и всю дальнейшую цепочку. И потом на Reddit — куча комментариев: "я попробовал на своей кодовой базе, у меня не взлетело". Для таких инструментов важны далеко не промпты, а управляемый контекст на каждом шаге. “Context engineering” фактически становится задачей №1 при построении надёжных агентов. Context тут — это ограниченный ресурс, "оперативная память" агента: окно ограничено, а длинные траектории (много ходов + выводы инструментов) быстро переполняют его, что бьёт по качеству, цене и задержкам. По мере роста контекста возникает "context rot": модели хуже извлекают нужные факты — у трансформеров бюджет внимания конечен (парные связи ~n²), значит каждый лишний токен ухудшает фокус. Отсюда требование: минимальный, но максимально полезный набор токенов. Лишняя тысяча токенов может стереть суть. Поэтому контекст нужно сжимать, резюмировать, обновлять и очищать. Новая работа инженера, который бустит свою работу с помощью AI — это не писать идеальные промпты, а проектировать рабочее пространство модели: что она знает, что должна забыть и что именно ей показать на следующем шаге. Попробуйте вот такой промпт для своего проекта: Сформируй структуру проекта [описание проекта] так, чтобы она была оптимальна для работы LLM-агентов: минимум шума, чёткое разделение ролей, управляемый контекст на каждом шаге, детерминированная логика действий. Используй принципы context engineering. Ссылки на почитать: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents Честно спизженно позаимствовано отсюда https://t.me/startup_architecture/158