diff --git a/_posts/mini_posts/2024-01-23-tls-packets.md b/_posts/mini_posts/2024-01-23-tls-packets.md
new file mode 100644
index 0000000..1841802
--- /dev/null
+++ b/_posts/mini_posts/2024-01-23-tls-packets.md
@@ -0,0 +1,6 @@
+---
+layout: post
+title: Структура TLS
+tags: [net, tutorial]
+---
+Очень хорошая [детализация протокола TLS](https://tls13.xargs.org/) прямо до байтов. Есть такое же для QUIC и DTLS (который используется, например, в WebRTC). 
diff --git a/_posts/mini_posts/2024-01-25-prioritization.md b/_posts/mini_posts/2024-01-25-prioritization.md
new file mode 100644
index 0000000..7a1717c
--- /dev/null
+++ b/_posts/mini_posts/2024-01-25-prioritization.md
@@ -0,0 +1,15 @@
+---
+layout: post
+title: Приоритизация продуктовых задач
+tags: [teamlead, мысли]
+---
+Интересно, есть ли где-то хоть сколько-нибудь адекватно систематизированное планирование? У меня по этому поводу в основном не очень позитивный опыт.
+
+Чаще всего встречался подход "делаем, потому что надо" и HiPPO (Highest Paid Person Opinion). Это кстати не такой уж и плохой вариант, если ответственное лицо адекватное, да и меньше времени требует. Есть чуть более формальные вариации (например, MoSCoW, Kano model), но это примерно то же самое в итоге. 
+
+Но мы же сейчас в бигдате, надо data-driven! (И телеметрия!) Тут легко обмазаться метриками в комбинации с экспертными оценками и "предсказывать", как эти метрики улучшатся при добавлении фичи. И из всего этого получить для каждой фичи какое-нибудь число, например, линейной комбинацией нескольких параметров (так еще некоторые студенты в дипломе делают, чтобы обосновать превосходство своего решения). Коэффициенты обычно рожаются "экспертной оценкой" и соответствуют текущей стратегии. Есть несколько стандартных шаблонов для этого — например, [RICE](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/) с [кучей вариаций](https://freedium.cfd/https://jordanlamborn.medium.com/rice-prioritization-alternatives-for-projects-and-features-8-scoring-frameworks-to-replace-rice-4a928b5940ce). У такой формализации есть преимущество, что можно "поиграться" с коэффициентами при смене стратегии, и тяжелее ошибиться в раздробленных экспертных оценках, но все равно экспертность никуда не делась.
+
+С другой стороны, упарываться data-driven тоже не стоит: если ориентироваться на прибыль, то пользователю обычно от этого [только хуже](https://en.wikipedia.org/wiki/Enshittification). Вообще, о конечном пользователе часто забывают (хотя тут можно отрицать все по методике, [предписываемой Форду](https://vc.ru/s/proddev/571177-bystraya-loshad-kotoroy-ne-bylo-ili-pochemu-produkt-dolzhen-reshat-problemy-polzovateley)) или, что еще хуже, превращают его в [тупую метрику](https://nothinghuman.substack.com/p/the-tyranny-of-the-marginal-user).
+
+Возвращаемся к простым экспертным оценкам...
+
diff --git a/assets/gags/2024-01-19-chrome.png b/assets/gags/2024-01-19-chrome.png
new file mode 100644
index 0000000..7c9bb16
Binary files /dev/null and b/assets/gags/2024-01-19-chrome.png differ
diff --git a/assets/gags/2024-01-23-prs.png b/assets/gags/2024-01-23-prs.png
new file mode 100644
index 0000000..674c641
Binary files /dev/null and b/assets/gags/2024-01-23-prs.png differ