Синицын, бл🤬

Про промптыОказывается, чтобы ИИ не генерил говно — нужно не магия, а нормальное ТЗ.Я тут нашел статью от NNGroup, и они предлагают неплохой базовый фреймворк для хороших промптов: CARE. 🔘 C = ContextИИ не знает, кто ты, где ты, зачем ты, и что тебе уже известно. Если не задать контекст — он придумает свой. А он, мягко говоря, может не совпасть.Пример: ты продакт, делаешь дашборд, а ИИ тебе генерит текст для HR-директора. Почему? Потому что не сказал, что ты продакт и ты делаешь дашборд.Сформулируй: кто ты, в какой роли, в какой ситуации, на каком этапе. Лучше два абзаца контекста, чем 20 минут редактирования потом.🔘 A = AskЧто конкретно ты хочешь? Не в духе “расскажи мне про CICD”, а “дай краткое сравнение GitLab и GitHub Actions для команды из 3 человек, которая раньше не использовала CI”. Чем точнее запрос — тем ближе ответ к делу.ИИ не умеет читать мысли. Он не знает, какой формат ты хочешь: таблицу, мем, список, анекдот, короткий совет? Скажи.🔘 R = RulesФормат, стиль, ограничения, объём. Не хочешь воды — напиши. Нужен текст в академическом или разговорном стиле — напиши. Нужно 500 слов, не больше — укажи это.ИИ вообще не против следовать правилам, но если их нет — он накидает шаблонного трёпа. Ну потому что может.🔘 E = ExamplesПокажи пример — и всё встанет на места. Один хорошо подобранный пример лучше любого описания. Ты хочешь текст “как у Максима Ильяхова”? Приложи скрин.И не стесняйся дать анти-пример — "мне не надо как тут", это тоже полезно. ИИ — штука обучаемая, но без данных он будет импровизировать.Итого:Хочешь, чтобы нейросетка работала на тебя, а не наоборот — не ленись формулировать. Промпт — это не “пиши”, это “вот тебе задача, вот вводные, вот ограничения, вот желаемый результат”.Всё как в жизни. Только теперь ещё и с ИИ.Бонус-трек:LLM не любит длинные чаты, с каждым новом сообщением качество ответа будет ухудшаться. Лучше один очень длинный базовый промпт.〰️〰️〰️〰️〰️〰️〰️🗞 @boombah_in_da_house

Про делегированиеКак-то раз один мой знакомый тимлид пожаловался, что его команда постоянно делает не то, что он хочет. "Объясняю же им четко, а они все равно херню какую-то творят".Проблема в том, что большинство менеджеров делегируют как бог на душу положит. Подбегают к человеку в коридоре и на ходу выдают: "Слушай, сделай вот это вот к пятнице, ок?" А потом удивляются, почему результат не тотДелегирование — это не "спихнуть задачу на подчиненного". Это сложный процесс, который требует подготовки и мозгов.Сначала сам разберись, что ты хочешь получить. Не "сделай мониторинг лучше", а четкое понимание: какие метрики, какие алерты, в каком виде, к какому сроку. Если у тебя в голове каша, то в голове исполнителя будет еще большая каша.Дальше подумай: а кому это делегировать? Не тому, кто свободен, а тому, кто может это сделать качественно. У джуна одни компетенции, у сеньора — другие. Одному можешь сказать "сделай как считаешь нужным", другому придется расписать пошагово.И вот тут самое интересное. Способ делегирования зависит от того, кому ты делегируешь:Крутому сеньору: "У нас проблема с производительностью базы. Можешь разобраться и предложить варианты решения?" Все, отвали от человека и жди результата.Опытному миддлу: "Надо оптимизировать запросы к базе. Вот эти таблицы тормозят. Посмотри на индексы, может быть нормализацию пересмотреть. Через неделю обсудим варианты."Джуну: "Вот тебе конкретная задача — добавить индекс на поле user_id в таблице orders. Вот документация, вот как это делается, вот как проверить результат. Вопросы есть?"Не надо делать это на ходу и вскользь. Сядь с человеком, объясни контекст, убедись что он понял не только что делать, но и зачем. Получи обратную связь: "Так, повтори своими словами, что ты будешь делать?"И да, будь готов к тому, что человек сделает не так, как ты бы сделал. Если результат соответствует техтребованиям — заткнись и не придирайся к реализации. Ты делегировал, а не клонировал себя.Самая частая ошибка: делегировать задачу, а потом микроменеджить каждый шаг. Либо делегируй задачу и отстань, либо делай сам. Третьего не дано. Микроменеджмент разлагает и деморализует команду. Формируется мышление вида "ну зачем мне что-то проверять, придет лид и все проверит", а у слабых духом появляются сомнения в компетентности: "если меня постоянно поправляют даже в мелочах, то, видимо, я не способен на что-то большое". Рождается выученная беспомощность. Да, надо быть готовым, что что-то возможно сломается (а может и нет, кстати), но тут уже надо выбирать: либо сильная и самостоятельная команда, либо ты сам как бутылочное горлышко, и ничего не сломано (спойлер: все равно сломается, нельзя все предугадать)Делегирование — это инвестиция времени в краткосрочной перспективе ради экономии времени в долгосрочной. Первый раз объяснить займет час, второй раз — полчаса, третий раз человек сам все сделает и еще лучше тебя.А если постоянно все делать самому, то ты так и останешься узким местом для всей команды. И будешь ныть, что у тебя нет времени на стратегию😊〰️〰️〰️〰️〰️〰️〰️🗞 @boombah_in_da_house

Про change managementНедавно на конфе меня спросили, как правильно внедрять изменения в команде и процессах. Мол, люди сопротивляются, ничего не хотят менять, а надо же развиваться.Блять, да они правы что сопротивляются😁 Большинство "улучшений", которые я видел за свою карьеру, были либо модой на очередной хайповый фреймворк, либо попыткой нового руководителя показать, что он что-то делает. В результате люди меняют рабочие инструменты, как перчатки, а толку ноль.Поэтому первое правило change management: а зачем вообще что-то менять? Если ответ "потому что все так делают" или "надо идти в ногу со временем" — идите нахуй со своими изменениями. Серьезно.Изменения оправданы только тогда, когда текущее решение реально не справляется. Не гипотетически в будущем, а прямо сейчас болит. У вас постгрес падает под нагрузкой? Окей, давайте думать про шардинг. У вас команда из 50 человек работает без процессов и все друг друга убивают? Давайте внедрять методологию.А вы хотите "улучшить Developer Experience"? Ну так а какой он сейчас и что конкретно болит? Если разработчики не жалуются, то, возможно, проблема не в инструментах, а в вашей потребности что-то поменять.Второй момент: люди не любят изменения не потому что они ретрограды. Люди не любят неопределенность. Им страшно, что новое решение будет хуже старого, что им придется переучиваться, что они временно станут менее эффективными.И это нормальные опасения! Я сам видел, как команды месяцами мучались с кубернетесом, который внедрили вместо нормально работающих виртуалок "для современности". Видел, как разработчики неделями настраивали новую CI/CD систему, которая в итоге работала медленнее старой.Поэтому если уж решили что-то менять, то:🔘Начинайте с малого. Не надо сразу весь стек переписывать. Возьмите один сервис, одну команду, один процесс. Докажите на нем, что новое решение реально лучше.🔘Вовлекайте команду в процесс принятия решения. Не спускайте решения сверху, а обсуждайте проблемы и варианты их решения. Люди гораздо охотнее внедряют то, что сами выбрали.🟢Обеспечьте план Б. У людей должна быть возможность откатиться к старому решению, если что-то пойдет не так. Это снижает стресс и сопротивление.🔘Инвестируйте в обучение. Да, это время и деньги. Но если вы хотите, чтобы изменения прижились, а не остались очередным буллшитом типа "там барин опять капусту косит, да кто их образованных поймет", то надо инвестироватьИ самое главное: будьте готовы признать, что ошиблись. Если через месяц-два становится понятно, что новое решение хуже старого — откатывайтесь и не стесняйтесь. Упертость в неправильных решениях — это не лидерство, это просто глупость.Change management в IT — это не про технологии. Это про людей. А люди, как известно, существа привычки. И это нормально, не надо с этим бороться. Надо это учитывать и работать с этим, а не против этого.〰️〰️〰️〰️〰️〰️〰️🗞 @boombah_in_da_house

Дотягивать отстающихСегодня пост, который многим не понравится😊В нас со школы вбили мысль, что отстающих надо подтягивать и заниматься ими: помогать, поддерживать и всячески товарищески способствовать их развитиюУ этого есть вполне понятное объяснение: KPI преподавателя сильно завязан на успеваемость учеников в целом и это ему выгодно. Ну и командный дух, типа, растетВ бизнесе такое не работает, к сожалению. Поэтому да, забудьте все, чему вас учили в школеОт лоу-перфомеров надо избавляться, а ставить надо на тех, кто херачит и делает все, что должен, и даже чуть-чуть больше. Вот их надо тянуть, ставить хорошие оценки на ревью и всячески поддерживатьЛоу-перформеры заражают всю команду, потому что средний человек видит так: я работаю, вкладываюсь тут на всю катушку, а внимание и поддержку получает чел, который работает откровенно слабо. Доколе?Поэтому выдавать поощрения авансом — херовая идея, прям вот откровенно херовая. Человек может быть очень классным, добрым, компанейским, прекрасным в общении. Но хороший человек — это не профессияНа работе надо работать, разбираться, учиться и изучать и вообще, вкладываться посильнее. В эксплуатации и инфраструктурной разработке это особенно важно.〰️〰️〰️〰️〰️〰️〰️🗞 @boombah_in_da_house

Не получилось из меня медиамагната, короче😊 Такая вот печальная историяНесколько лет я закопал в мечты о контентных проектах и работу над ними и теперь пришло время признать, что не получилось. По крайней мере в том виде, в котором я все это планировалПризнавать поражения всегда трудно. Я очень много сил во все это закопал и теперь, как говорят финансисты, пришло время зафиксировать убыток и двигаться дальше. Я, конечно, хочу все это зарестартить, все-таки это мечта, а от мечты отказываться совсем не хочетсяОсновная моя ошибка прям по классике: начало любого проекта заключается в том, чтобы сильно недооценить его объем и сложность. Уроки, которые я извлек:🔘 Для полноценного запуска контентых проектов недостаточно, собственно, контента. Более того, контент — это вообще процентов 10 той работы, которую надо делать🔵 Контент может быть говном. Но если он точно попадает в аудиторию, на которую рассчитан, то проект вполне себе полетит. И вообще, говно — метрика субъективная. Но я не хочу делать то, что я считаю говном, даже если оно и будет продаваться и продавать. Для меня это важно.🔘 Без команды не потянуть. В Озоне у меня очень много работы, а свои проекты — это вторая, по сути, работа. У меня в одного тупо не хватает сил. Постоянно работать по 16 часов в сутки я не могу, я уже старый. 🟡 Если бы надо было только заниматься стратегией, коммуникациями и менеджить команду, я бы справился. Но команды у меня нет и собрать ее без бюджета не получилось. Делать все в одну каску оказалось суперсложно и часто не хватало компетенций.🟣 Необходимо четко определяться с целями и бюджетами, иначе это просто слив времени и денег (хаха, капитан очевидность вошел в чат). Я слил достаточно времени и денег и не добился ничего, просто потому, что не знал, чего вообще надо добиваться. Теперь знаю, но у меня кончились силы🟢 Я узнал и впитал ебическое количество информаци по медиа и продакшену всех видов. Голова теперь забита теорией под завязку, надо как-то превращать ее в практикуНу штош, никто, конечно, не обещал, что будет легко. Уйду пока в размышления и планирование. Да и просто надо отдохнуть. Буду пока писать тексты и делать эксперименты в каком-то ненапряжном режиме, без каких-либо ожиданийЕсли кто-то вдруг хочет поработать со мной в ключе создания технологического медиа, то напишите мне на andrey@sinits.in, обсудим. Пока что я ничего не могу предложить, кроме вороха идей и своего опыта. Даж плана нового пока нет.〰️〰️〰️〰️〰️〰️〰️🗞 @boombah_in_da_house