Дизайн в разработке IT-решений и цифровых сервисов играет очень важную роль. Вы даже не представляете, какие ужасные интерфейсы делают разработчики, если им не будут готовить макеты дизайнеры. Не любой дизайнер сможет придумать интерфейс, который будет сочетать в себе красоту и удобство использования (UI/UX). Я встречал примеры хорошо выглядящего дизайна, но совершенно не удобного в повседневном использовании, уверен, что и ты тоже. Красивый дизайн, который еще и удобен — это очень сложно, разработка таких макетов может занимать сотни часов и является очень тяжелой задачей.

Шаг 2: Актуализация макетов

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

Шаг 3: Согласование макета с PM

Если выстроен процесс, то дизайнер дожидается согласования цвета кнопки, если нет — то дизайнер ставит встречу с PM и показывает изменения уже на макете, в процессе может выясниться, что доступный из палитры брендбука синий цвет не подходит, но есть другой. Они могут привлечь еще дизайнера или еще одного PM, обсудить это еще на одной встрече. В конечном итоге одна из них (если повезет — первая) все-таки заканчивается согласованием цвета.

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

Один из главных вопросов, который должен задать себе PM, — а возможно ли вообще внести планируемые изменения в сервис? Как дорого и сложно их будет сделать? В случае простого изменения цвета кнопки рисков того, что это займёт недели или месяцы, практически нет, но в случае более масштабных изменений или планах создания нового функционала такие риски всегда нужно учесть. PM должен держать в голове мысль, что стоимость внесения изменений в продукт может быть существенно больше, чем та польза и выгода, которую они принесут, другими словами, нужно убедиться, что «игра стоит свеч».

Шаг 4: Первоначальная оценка от разработки

На этом этапе PM, в рамках существующего процесса или просто отдельной встречей, собирается с лидами разработки для оценки первоначальных требований. Это должны быть не просто первые попавшиеся высокоуровневые разработчики, а непосредственно владельцы кода, которые очень глубоко понимают, как все устроено в тех частях сервиса, где планируются изменения. Лиды разработки должны ответить на следующие вопросы:
— Достаточны ли требования, описанные в задаче?
— Есть ли «подводные камни» и прочие граничные условия, которые не смог заметить PM?
— Как сложно будет внести предложенные изменения, оценить в часах или SP(story points)?
Если от разработки поступят замечания, PM должен внести их в требования и повторять шаги 1–4 до тех пор, пока требования не будут согласованы с реальностью и всеми участниками процесса. 
Будем считать, что требования согласованы, наконец-то можно нести задачу в команду для ее реализации.

PM подготовил требования, согласовал их с дизайном, лидами разработки и реальностью, самое время отдать задачу в разработку. Но разработчики не сидят без дела, у них есть ранее запланированные задачи, которыми они заняты в текущий момент. Но как отдать им задачу в разработку?
Существуют разные методологии и целые философии управления жизненным циклом проекта, но нам важны именно методологии. Наиболее популярные сейчас это Scrum и Kanban - они используются практически повсеместно, но это отдельная тема, причем не просто для цикла постов, но и целых книг.

Очень коротко об этих методологиях

Scrum - ритмичная работа с временными отрезками - спринтами
- Жёсткая структура: фиксированные спринты (2-4 недели)
- Чёткие роли: Scrum Master, Product Owner, команда
- Планирование объёма работ на спринт

Kanban - непрерывный поток без разделения по времени, когда задачи добавляются в самый конец или в соответствии с их приоритетами
- Задачи поступают и завершаются непрерывно
- Нет строгих ролей/сроков
- Ограничение количество задач в работе одновременно
- Фокус на оптимизацию потока

Я привык работать по Scrum, потому будем считать, что в текущем примере используется он, тогда нам потребуется этап планирования, но если бы использовался Kanban - то PM просто положил задачу на некую доску, в соответствии с ее приоритетом или в рамках какого-то утвержденного процесса, и команда до нее со временем добралась.

Шаг 5: Планирование спринта

В один прекрасный день вся команда разработки и PM собирается на встрече, на которой они совместно планируют объем работ на ближайший спринт. PM показывает команде уже согласованные и уточненные требования, так что команде остается их внимательно изучить, задать вопросы и уточнения, если они появятся, и дать оценку сложности реализации в часах или Story Point (SP). После чего формируется объем задач на следующий спринт, где интересующая нас задача займет в нем свое место в соответствии с ее приоритетом относительно других задач.

Спустя какое-то время разработчик добрался до задачи, она хорошо описана, согласована всеми, кем только можно, он берет ее и делает.

Шаг 6: Разработка

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

Шаг 7: Ревью кода

Другой разработчик получает код, в котором реализованы все необходимые требования, если ему что-то не нравится, оставляет комментарии или предложения, как что-то можно исправить или улучшить, этот процесс может происходить итерациями довольно продолжительное время. Это зависит от объема кода, от сложности изменений, которые были внесены, от правил проведения ревью кода, которые приняты в команде.

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

Всё не так просто, разработчикам верить нельзя, правда. Даже если они со слезами на глазах утверждают, что всё отлично, изменения простые и не содержат багов. Они точно врут! Сами того не ведая.

Врал ли я хоть раз тестировщикам? Да. Делал ли я это осознанно? Каюсь, но да, было. Хотя в большинстве случаев я просто наивно полагал, что там всё действительно хорошо.

Точно ли там нет багов и как новый функционал соответствует требованиям, определяет служба качества (QA). Иногда пройти тестирование — отдельный сложный квест.

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

CI/CD (Continuous Integration/Continuous Delivery) — если очень коротко - автоматизация сборки, тестирования и развертывания кода для быстрого/безопасного обновления ПО.

Шаг 8: Развертывание на тестовом окружении

Допустим, CI/CD все-таки существует и изменения можно доставить на стенд, тогда разработчик нажимает кнопку в системе управления версией (GitHub/GitLab/Bitbucket/Another) и оно само магически разворачивается в некое окружение, в зависимости от уровня колдуна, который настраивал CI/CD, после этого может запуститься процесс тестирования или дизайн-ревью, все нужные люди призовутся сами в задачи и им придут уведомления

Шаг 9: Дизайн-ревью

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

Дизайнер получает ссылку на тестовый стенд и, возможно, тестовые доступы, чтобы он мог пойти и посмотреть, чего там напрограммировали разработчики интерфейсов. Если дизайнер найдет проблемы, то заведёт задачу, в которой опишет, что именно ему не понравилось, тогда шаги 6–8 будут повторяться, пока дизайн не согласует то, что было сделано.

Внимание, анекдот!

Заходит тестировщик в бар. Заказывает кружку пива. Заказывает 0 кружек пива. Заказывает 999999999 кружек пива. Заказывает -1 кружку пива. Заказывает ФАОЛФВОЫЛ. Тут заходит реальный пользователь. Спрашивает, где здесь туалет. Бар сгорает в адском пламени, убивая всех вокруг.
Тестирование действительно важный этап, который помогает существенно улучшить качество сервиса. Тестирование — это отдельная огромная тема, в которую, я уверен, когда-нибудь я зароюсь с головой и расскажу интересные штуки.

Шаг 10: Тестирование

После дизайн-ревью подключается команда тестирования. Они (или это вообще один человек) детально исследуют стенд, который передали разработчики, для того чтобы подтвердить следующие гипотезы:
- То, что сделал разработчик, соответствует требованиям.
- Требования, которые он внес, не влияют на другие части продукта.
- Учтены все граничные условия.

Если тестирование устроено по-взрослому, есть автотесты, тест-планы, регрессионные тестирования разной глубины, то команда тестирования должна запланировать себе задачи, в которых должна сделать следующее:
- актуализировать внутреннюю документацию;
- покрыть приемочными тестами новый функционал;
- включить новый функционал в тест-планы и сценарии регрессионного тестирования. Всё сильно различается от процессов, которые приняты внутри команд тестирования, но, как правило, у всех команд, которые серьезно относятся к тестированию, примерно одни и те же подходы. Может звучать грустно, но чем больше разработчик будет страдать на тестировании, тем стабильнее и качественнее будет сервис.

Тестирование какое-то время измывалось над разработкой, находило старые баги, выдавая их за новые, они задавали тонны вопросов и прочих уточнений, и, спустя все стадии, начиная от отрицания, кончая принятием, все-таки поставили резолюцию «протестировано».

Шаг 11: Планирование релиза

Все очень зависит от процессов, которые приняты у разработки, иногда QA раскатывают релиз, иногда разработчики, где-то девопсы, но релиз должен быть подготовлен, какие-то действия должны быть выполнены, слиты ветки, запущены нужные пайплайны CI/CD.

Шаг 12: Релиз

Очень хорошо, если релиз осуществляется одной кнопкой через CI/CD. Допустим, эта кнопка есть, ответственный за это человек ее нажимает, происходит очень сложная магия, и в конечном итоге изменения доставляются на прод. Но! Никто ничего не видит!
Но в этом и план, как ранее планировалось, релиз выполнялся с экспериментом, а это значит, чтобы понять, будет ли эффект от внесенных изменений, нужно «включить» эти изменения на определенную долю пользователей.

Шаг 13: Проведение эксперимента

Перед началом эксперимента, буквально для его чистоты, нужно убедиться, что никаких событий поступать не начало, после чего, опять же, через CI/CD или свои собственные технические решения нужно начать показывать кнопку с новым цветом на 10% пользователям.
В условиях эксперимента были следующие требования: «В случае падения количества кликов более чем на 10% в течение первых 24 часов — сворачиваем эксперимент досрочно», потому если на следующие сутки это требование не будет выполнено, эксперимент будет свернут досрочно, флаги через CI/CD будут сняты, и пользователи не будут видеть эти изменения совсем. Но будем надеяться на хорошее.

Казалось бы, всё сделано: кнопка перекрашена, релиз прошёл успешно, эксперимент запущен. Но самое интересное только начинается. Ведь теперь нужно понять — а сработала ли наша гипотеза? Или мы просто потратили кучу времени и ресурсов на то, что в итоге окажется бесполезным?

Шаг 14: Анализ результатов эксперимента

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

Что они ищут?

- Изменение конверсии — сколько пользователей из экспериментальной группы (тех, кто видел синюю кнопку) нажали на кнопку по сравнению с контрольной (теми, кто видел старую серую).
- Статистическую значимость — не случайны ли эти 5–10%? Возможно, просто в эти две недели люди просто хотели больше хлеба, чем обычно?
- Побочные эффекты — не упали ли другие метрики? Например, если синяя кнопка отвлекает от других важных элементов интерфейса.

Если всё хорошо и гипотеза подтвердилась (кликов действительно стало больше), то PM радостно потирает руки и готовится к финальному шагу.

Если же эффекта нет или, хуже того, метрики упали — значит, эксперимент провалился. В этом случае все вздыхают, закрывают задачу и возвращаются к серой кнопке. При этом в беклог ляжет задача на то, чтобы убрать эксперимент и фича-флаг.

Шаг 15: Вывод функционала из-под эксперимента

Допустим, всё прошло успешно. Тогда:

- Финальный релиз — через CI/CD или вручную изменения раскатываются на 100% пользователей.
- Удаление экспериментального кода — задача в беклог, чтобы свернуть эксперимент и удалить фича-флаги, ну и серую кнопку тоже.
- Документирование — где-то в недрах проектной документации появится запись: _«Синяя кнопка увеличила конверсию на X%»_. Теперь это знание можно использовать в будущем.

И вот она — победа! Кнопка синяя, кликов больше, бизнес доволен, PM получает премию (или нет), а разработчики… Ну, разработчики просто идут делать следующую задачу.

Эпилог

Просто поменять цвет кнопки. Что может быть проще. Но за этим стоит огромное количество процессов, людей и решений. И это ещё относительно простой пример!

А теперь представьте, что будет, если нужно не кнопку перекрасить, а, скажем, полностью переделать процесс заказа. Но это уже совсем другая история…
Вот тут я попросил помощи нейросетей и предложил посчитать стоимость в человеко-часах этих работ с разбивкой на действующих лиц, приведу ответ без изменений.

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

Ключевые этапы и роли

1. Product Manager (PM) – 14–29 часов  
   - Анализ метрик, гипотеза, требования, согласования, контроль релиза и анализ результатов.  

2. Дизайнер – 4–11 часов  
   - Подбор цвета, правка макетов, дизайн-ревью.  

3. Фронтенд-разработчик – 5–11 часов  
   - Внесение изменений в код, добавление аналитики, доработки после ревью.  

4. QA (тестировщик) – 4–12 часов  
   - Проверка функционала, регрессионное тестирование, выявление багов.  

5. DevOps – 1.5–6 часов  
   - Настройка CI/CD, деплой на тестовое и продакшен-окружение.  

6. Аналитик – 4–8 часов  
   - Оценка результатов A/B-теста, проверка статистической значимости.  

7. Другие разработчики (ревью кода) – 1–3 часа  
   - Проверка кода перед мержем.  

Общие трудозатраты
- Минимально: ~35 часов (если всё идеально).  
- Реалистично: 50–70 часов (стандартный процесс с согласованиями).  
- Максимально: 80+ часов (если возникли доработки, баги или споры о цвете).  

Вывод
Изменение цвета кнопки – это не просто правка CSS, а сложный процесс с участием 5–7 специалистов. В среднем он занимает 1–2 недели работы всей команды. Чем крупнее продукт, тем больше времени уходит на согласования и тестирование.  

Так что в следующий раз, когда скажут «ну это же просто поменять цвет», можно смело отвечать: «Да, всего-то 50+ часов работы» 😉

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

Вы легко можете прикинуть среднюю ЗП за средний час среднего IT сотрудника и получить сколько это стоит денег.

А теперь представьте, сколько займет времени переделать целиком какой-то экран или добавить большую фичу.

У меня есть мемный бот, я даже грозился рассказать, что это такое и зачем он мне. И я расскажу!

Началось все довольно тривиально, я давно люблю смешные картинки, как и многие, занимался их коллекционированием, рассылаю по чатикам друзьям и всем, кому посчитаю нужным. Со временем таких чатиков стало много, многим я слал одно и то же, и из этого вполне органично возникла идея завести мемный канал. Я это и сделал, начал накидывать мемесы туда. Но со временем этот ритуал превратился в рутину, причем с весьма четкой схемой действий:
- увидел мем
- сохранил или репостнул в избранное
- отправил в канал в отложенную публикацию, сделал какую-то подпись
При этом в телеге совершенно неудобный механизм указания времени отложенной публикации. Для постинга с частотой 1–3 поста в день это в целом норм, но когда мемы на тебя сыплются как из рога изобилия, то сложно держать в голове интервалы между соседними постами, приходится это как-то анализировать и помнить. Тогда родился простой план. Я же программист или кто? Я могу это все взять и автоматизировать.

Были такие потребности:
- Репостить в бота мемасики
- Публиковать записи с интервалом
- Парсить интересные мне каналы

На первом этапе я все это и сделал, и это даже какое-то время работало, но позже я понял, что не хватает еще некоторых вещей:
- Поиск дубликатов
- Равномерное заполнение сетки по временам суток (утро, день, вечер, ночь)
- Предложка с полноценной разметкой и анонимностью
- Статистика по предложке

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

Я люблю разные мемы и даже лютый кринж, там, где или непонятно, или отталкивающе мерзко, я начал это постить по ночам, но утром люди просыпались, видели все это, отписывались от канала, а те, кто знали мои контакты, писали в личку: «Ах ты больной ублюдок», я перестал это делать, тогда те, кому это было норм, начали писать: «Эй, а где кринж? Мне нравилось!».
Я думал, как усидеть на двух стульях, и нашел решение!

Через бота я могу опубликовать канал в отдельную рубрику, и посты появляются в основном канале ночью в интервале с 01:00 до 07:00 мск, но чтобы не травмировать нежную аудиторию, ровно в 7 утра они собираются и уезжают вообще в отдельный канал!

Мемный бот, которого я сам написал для себя, горбатится не покладая рук (у ботов есть руки?) вот уже пару лет, он воплотил в себе сочетание любви к мемам и технологиям, и да, он написан на Node.js, использует в качестве хранилища Postgress
он даже лежит в публичном доступе, вот в этом вот репозитории
И там есть парсер, вы можете даже сами посмотреть по коду как он работает. Ну или я как нибудь расскажу, там все просто

Питер наконец-то дошел до автобусов на конной тяге

А кто нибудь хоть раз подписывался на таких людей или хотя бы находил их в твиторе? Люди, которые в мемах фигурируют обычно вообще мимо глаз проходят, я так понял это какой-то способ вирусного пиара для твитора, но интересно, насколько это вообще жизнеспособно?

Я одно время пытался замазывать это, но потом как-то смирился

https://t.me/filipp_memes/14943

Ну конечно все пошло не так как я планировал, посты нахлестнулись, в итоге сегодня в @filipp_memes_best попал пост который был опубликован не за последние сутки а за более чем два дня. И пост который попал уже вчера, и я его благополучно снес. Ох уж это телеграмовское апи. В целом я разобрался как это все работает, завтра посты будут по расписанию и как надо, за последние 24 часа. И самое главное, не будут попадать текстовые посты и анонсы, только видосы или изображения. Сегодня уже не буду постить их, пропустил, значит пропустил. Будем считать правило 2х постов в сутки непреклонным, т.к. некоторые подписались именно под этим условием

как то мемый проект вырос из под контроля

по сути есть первый, основной канал - @filipp_memes
есть новый канал с лучшими мемесами - @filipp_memes_best
и кринге
Есть бот - @filipp_memes_bot

и еще два служебных канала, один модераторский, второй для парсера!
И парсер, который является обычным пользовательским аккаунтом, который управляется программно

Целый мемный энтерпрайс

Далее, как будет время, сделаю механизм рационального включения комментов под постами, добавится еще канал - чятик, и флаг в модераторской - "включить коменты" и тогда под постом будут активны комментарии, иначе бот будет сносить репост в чатике коментов и собственно комментарии не будут прорастать под пост в основной канал

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

Чета я давно ничего не писал, были на это причины 🙃

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

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

И тут, неожиданно, на встречу приходит он, сияя своим цифровым следом, его величество, ИИ, я даже представить не мог насколько это удобно, пробовал несколько схем

Первая:

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

Второе, меня это порвало в клочья просто, я чуть не заплакал от счастья

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

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

Я даже довел все до абсурда, как я люблю и попросил пересчитать рецепт на много тысяч кило исходного продукта

ИИ такой: «говно вопрос бро, вот тебе промышленный рецепт, не забудь арендовать автоклав, дурачок»

Вывод прост, ИИ убьет все эти ваши всратые кулинарные сайты один раз обучившись на них они больше не нужны, удоляйте

В процессе реализации комплекса мероприятий по обеспечению санитарно-гигиенических и эргономических стандартов был зафиксирован инцидент, характеризующийся грубым нарушением установленных норм организации пространства. Конкретный случай представлял собой нарушение санитарных и эргономических принципов, выраженное в акте дефекации в непосредственной близости от дверного проема.
Этот феномен требует проведения междисциплинарного исследования, включающего детальный анализ с применением современных достижений в области санитарии, антропометрии и поведенческой психологии. Необходимость такого подхода обусловлена потребностью в комплексной оценке потенциального воздействия инцидента на эпидемиологическую безопасность и качество пространственной среды, что имеет прямое влияние на общественное здоровье и благосостояние.
Для адекватного понимания причин и последствий наблюдаемого явления необходимо проведение многофакторного исследования, включающего анализ антропометрических параметров, поведенческих паттернов и комплекса факторов, определяющих выбор места для удовлетворения физиологических потребностей. Результаты этого анализа позволят разработать рекомендации по оптимизации санитарно-гигиенических и эргономических стандартов, что, в свою очередь, будет способствовать повышению уровня эпидемиологической безопасности и улучшению качества пространственной организации как в общественных, так и в жилых помещениях.
Таким образом, проведенное исследование подчеркивает значимость интеграции научных достижений различных дисциплин для решения актуальных проблем, связанных с обеспечением гигиенических и эргономических норм в повседневной жизни.

Если в кране нет воды - значит выпили фронты

Мемы, код и выбор

Я долго думал: может, пора отдать управление каналом ИИ?
Он бы всё отсортировал, убрал спам, даже виральность предсказал.
И всё стало бы… идеально.

Но потом я понял одну простую вещь:
ИИ не смеётся.

Он не чувствует той тонкой грани
между «смешно» и «стыдно»,
между «мем для своих» и «мемом, после которого молча отписываются».

ИИ не пребывает в мире.
Он не слышит крика, спрятанного за каждым мемом -
крика усталости, иронии, абсурда.
или просто тихого «чёрт, это же про меня».

Он может лишь повторить его.
Как эхо.
Точное - но безжизненное.

А решение «публиковать или нет» - это не про правила.
Это про человеческое суждение.
Про то, что даже в мире алгоритмов
последнее слово должно оставаться за вкусом, стыдом и интуицией.

Поэтому я верю:
мемы - это то, что ИИ не сломает. Никогда.

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

Филипп Семиров
Доклад на Vertis Tech Party, 14 ноября 2025

Закончил смотреть сериал THE PITT

Я видел много сериалов на медицинскую тематику. Клиника, Доктор Хаус, Скорая помощь, Хороший доктор, ещё пару мимо проходящих. Но это что-то другое. Другой уровень.

Здесь всё цепляет. Как подаётся история. Как держится напряжение. Как работает тревога. Это не та тревожность, когда хочешь глянуть в телефон или налить воды. Здесь сцена хватает тебя и не отпускает. Пока не закончится.

После такого понимаешь. Твоя работа не такая уж тяжёлая. Даже самый сложный день не катастрофа. И ты рад. Что не оказался в этой клинике ни как пациент, ни как персонал

10/10