🎉 Ретро недели: классический подход провалил проверку реальностью
Начали неделю с эксперимента: "А давайте сделаем правильно — сначала согласуем, потом разработаем!"
Финальные цифры:
📊 Путь "по учебнику":
— 4 рабочих дня на согласования
— ~25 человеко-часов команды на документацию
— Почти готовое коммерческое ТЗ для... теста гипотезы
— Финальное согласование: еще в процессе
⚡️ Путь "параллельный" (как мы обычно):
— 3 дня разработки → рабочий MVP
— Демо руководству с результатом
— Оставшиеся согласования закрылись за 1 день
— Причина: согласовывали уже не идею, а готовый продукт
Вывод эксперимента:
Наш "хакерский" подход — сначала делать, потом спрашивать — для нашей корпоративной реальности работает ЭФФЕКТИВНЕЕ классического.
Почему?
✅ Работающий MVP убирает 90% абстрактных опасений
✅ Бизнес видит ценность, а не обещания
✅ Согласования конкретики идут в 5 раз быстрее
✅ Риск "потратили 3 дня зря" < риск "застряли в согласованиях на месяц"
Важно:
Это НЕ призыв игнорировать процессы. Это про понимание контекста.
Если в вашей компании:
→ Согласование плана = 2 недели бюрократии
→ Согласование результата = 2 дня формальностей
→ Тестовый MVP можно сделать за 3-5 дней
То ваш "неправильный" способ и есть оптимальный для этих условий 🎯
Урок недели: Иногда нарушение правил — это не бунт, а прагматичная адаптация к реальности системы.
Проверено экспериментом. Провалидировано цифрами. Возвращаемся к рабочему процессу 😎
А у вас в компании как работает? "Сначала одобрение" или "сначала результат"? 👇
#ретро #процессы #интрапренёрство #mvp #pragmatic #codetogo #itshchen
Начали неделю с эксперимента: "А давайте сделаем правильно — сначала согласуем, потом разработаем!"
Финальные цифры:
📊 Путь "по учебнику":
— 4 рабочих дня на согласования
— ~25 человеко-часов команды на документацию
— Почти готовое коммерческое ТЗ для... теста гипотезы
— Финальное согласование: еще в процессе
⚡️ Путь "параллельный" (как мы обычно):
— 3 дня разработки → рабочий MVP
— Демо руководству с результатом
— Оставшиеся согласования закрылись за 1 день
— Причина: согласовывали уже не идею, а готовый продукт
Вывод эксперимента:
Наш "хакерский" подход — сначала делать, потом спрашивать — для нашей корпоративной реальности работает ЭФФЕКТИВНЕЕ классического.
Почему?
✅ Работающий MVP убирает 90% абстрактных опасений
✅ Бизнес видит ценность, а не обещания
✅ Согласования конкретики идут в 5 раз быстрее
✅ Риск "потратили 3 дня зря" < риск "застряли в согласованиях на месяц"
Важно:
Это НЕ призыв игнорировать процессы. Это про понимание контекста.
Если в вашей компании:
→ Согласование плана = 2 недели бюрократии
→ Согласование результата = 2 дня формальностей
→ Тестовый MVP можно сделать за 3-5 дней
То ваш "неправильный" способ и есть оптимальный для этих условий 🎯
Урок недели: Иногда нарушение правил — это не бунт, а прагматичная адаптация к реальности системы.
Проверено экспериментом. Провалидировано цифрами. Возвращаемся к рабочему процессу 😎
А у вас в компании как работает? "Сначала одобрение" или "сначала результат"? 👇
#ретро #процессы #интрапренёрство #mvp #pragmatic #codetogo #itshchen
👍1🔥1💯1
💥 Факап понедельника: отпуск с ноутбуком
Понедельник.
Я в отпуске.
И это два факта, которые почему-то не исключают друг друга 😅
Формально — out of office.
Фактически — ноутбук в рюкзаке "на всякий случай", рабочий чат не замьючен — "ну вдруг что-то важное".
И вот ты уже:
— "одним глазом" смотришь алерт,
— "на пять минут" отвечаешь в чате,
— "быстро проверяешь", что там произошло.
Факап в том, что отпуск незаметно превращается в режим фоновой поддержки продакшена. Без ответственности. Без компенсации. И без ощущения, что ты реально отдыхаешь.
💡 Вывод понедельника: отпуск с ноутбуком — это не отдых, а иллюзия контроля. Настоящий перерыв начинается там, где ты позволяешь системе пожить без тебя.
А у вас отпуск — это реальный оффлайн или тоже "на всякий случай гляну"? 😅👇
#факап #понедельник #отпуск #itlife #баланс #codetogo #itshchen
Понедельник.
Я в отпуске.
И это два факта, которые почему-то не исключают друг друга 😅
Формально — out of office.
Фактически — ноутбук в рюкзаке "на всякий случай", рабочий чат не замьючен — "ну вдруг что-то важное".
И вот ты уже:
— "одним глазом" смотришь алерт,
— "на пять минут" отвечаешь в чате,
— "быстро проверяешь", что там произошло.
Факап в том, что отпуск незаметно превращается в режим фоновой поддержки продакшена. Без ответственности. Без компенсации. И без ощущения, что ты реально отдыхаешь.
💡 Вывод понедельника: отпуск с ноутбуком — это не отдых, а иллюзия контроля. Настоящий перерыв начинается там, где ты позволяешь системе пожить без тебя.
А у вас отпуск — это реальный оффлайн или тоже "на всякий случай гляну"? 😅👇
#факап #понедельник #отпуск #itlife #баланс #codetogo #itshchen
👍2🔥1💯1
🧠 Наблюдение среды: отпуск ≠ выключение по кнопке
Самое странное в отпуске — даже не ноутбук в рюкзаке.
Самое странное — что голова всё равно работает в рабочем режиме.
Ты идёшь гулять, а в фоне:
— "а если тот алерт всё-таки был не шумом или его никто не увидел?"
— "надо бы потом проверить логи"
— "интересно, задеплоили или отложили?.."
Поймал себя на мысли: за годы в IT мы так привыкли быть доступными, что отсутствие задач начинает ощущаться как баг в системе.
💡 Маленький инсайт: настоящий отдых — это не когда нет задач, а когда ты разрешаешь себе не знать, что там происходит без тебя.
И да, это навык. Не встроенный. Его тоже приходится прокачивать 😅
А у вас как — голова в отпуске реально отдыхает или всё ещё "на проде"? 👀
#itlife #мысли #отпуск #баланс #codetogo #itshchen
Самое странное в отпуске — даже не ноутбук в рюкзаке.
Самое странное — что голова всё равно работает в рабочем режиме.
Ты идёшь гулять, а в фоне:
— "а если тот алерт всё-таки был не шумом или его никто не увидел?"
— "надо бы потом проверить логи"
— "интересно, задеплоили или отложили?.."
Поймал себя на мысли: за годы в IT мы так привыкли быть доступными, что отсутствие задач начинает ощущаться как баг в системе.
💡 Маленький инсайт: настоящий отдых — это не когда нет задач, а когда ты разрешаешь себе не знать, что там происходит без тебя.
И да, это навык. Не встроенный. Его тоже приходится прокачивать 😅
А у вас как — голова в отпуске реально отдыхает или всё ещё "на проде"? 👀
#itlife #мысли #отпуск #баланс #codetogo #itshchen
👍1🔥1💯1
🎉 Пятница: вывод недели "отпуск с ноутбуком"
Неделя в режиме отпуска показала одну простую вещь:
проблема не в ноутбуке. И даже не в чатах.
Проблема в том, что система слишком долго опиралась на одного человека — и этим человеком часто был ты сам.
И когда ты уходишь, система:
— либо начинает скрипеть,
— либо всё-таки… продолжает работать 🤯
💡 Вывод недели:
если без тебя всё падает — это не героизм, а сигнал.
Если без тебя всё работает — значит, отпуск наконец-то можно считать отпуском.
Иногда лучший вклад в проект — это выйти из него на время и посмотреть, что будет.
Хороших выходных.
И пусть хотя бы в них прод живёт своей жизнью 😎
#itlife #пятница #отпуск #выводы #codetogo #itshchen
Неделя в режиме отпуска показала одну простую вещь:
проблема не в ноутбуке. И даже не в чатах.
Проблема в том, что система слишком долго опиралась на одного человека — и этим человеком часто был ты сам.
И когда ты уходишь, система:
— либо начинает скрипеть,
— либо всё-таки… продолжает работать 🤯
💡 Вывод недели:
если без тебя всё падает — это не героизм, а сигнал.
Если без тебя всё работает — значит, отпуск наконец-то можно считать отпуском.
Иногда лучший вклад в проект — это выйти из него на время и посмотреть, что будет.
Хороших выходных.
И пусть хотя бы в них прод живёт своей жизнью 😎
#itlife #пятница #отпуск #выводы #codetogo #itshchen
👍1🔥1💯1
🎉 Последний рабочий день (официально)
Сегодня по производственному календарю — последний рабочий день.
Не пятница, но ощущается почти так же 😌
В такие дни в IT включается особый режим:
— задачи формально есть,
— митинги как будто короче,
— деплои откладываются "до после праздников" (и это правильно 😅).
Код пишется осторожно, решения принимаются мягче, а фраза
"давай после праздников"
внезапно становится самой здоровой инженерной практикой.
💡 Маленькое наблюдение: предпраздничные дни — это редкий момент, когда скорость уступает место здравому смыслу. И, возможно, если бы мы чаще работали в таком режиме, багов было бы меньше.
Пусть всё важное подождёт пару дней.
Прод — постоит.
А голова — отдохнёт.
Хороших праздников 🎄✨
#itlife #праздники #последнийрабочийдень #мысли #codetogo #itshchen
Сегодня по производственному календарю — последний рабочий день.
Не пятница, но ощущается почти так же 😌
В такие дни в IT включается особый режим:
— задачи формально есть,
— митинги как будто короче,
— деплои откладываются "до после праздников" (и это правильно 😅).
Код пишется осторожно, решения принимаются мягче, а фраза
"давай после праздников"
внезапно становится самой здоровой инженерной практикой.
💡 Маленькое наблюдение: предпраздничные дни — это редкий момент, когда скорость уступает место здравому смыслу. И, возможно, если бы мы чаще работали в таком режиме, багов было бы меньше.
Пусть всё важное подождёт пару дней.
Прод — постоит.
А голова — отдохнёт.
Хороших праздников 🎄
#itlife #праздники #последнийрабочийдень #мысли #codetogo #itshchen
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1🎉1
Новый год — хороший повод отсечь лишнее
и оставить то, что действительно имеет значение.
За прошлый год накопилось много кода, идей, сомнений
и неидеальных решений.
«Код на вынос» — про то, как решения сталкиваются с реальностью.
Я не привык верить в идеи без реализации.
Любая концепция пуста, если она не прошла проверку хотя бы PoC.
Здесь — о том, как принимаются решения:
– что сделано и почему именно так
– какие были ограничения и сомнения
– что сломалось и что выжило
– что имеет смысл делать сразу, а что — потом
Идеальных решений не бывает.
Факапы случаются всегда — и чаще всего именно они дают больше всего опыта.
В этом году продолжим, как и прежде,
выносить самые запоминающиеся из них —
и даже те, которые не случились, но могли.
Каждый сможет что-то вынести — в меру своего опыта.
На то он и «Код на вынос».
и оставить то, что действительно имеет значение.
За прошлый год накопилось много кода, идей, сомнений
и неидеальных решений.
«Код на вынос» — про то, как решения сталкиваются с реальностью.
Я не привык верить в идеи без реализации.
Любая концепция пуста, если она не прошла проверку хотя бы PoC.
Здесь — о том, как принимаются решения:
– что сделано и почему именно так
– какие были ограничения и сомнения
– что сломалось и что выжило
– что имеет смысл делать сразу, а что — потом
Идеальных решений не бывает.
Факапы случаются всегда — и чаще всего именно они дают больше всего опыта.
В этом году продолжим, как и прежде,
выносить самые запоминающиеся из них —
и даже те, которые не случились, но могли.
Каждый сможет что-то вынести — в меру своего опыта.
На то он и «Код на вынос».
1🤩1💯1
Зависимость — это всегда принятый компромисс.
И чаще всего чужой.
В разработке с этим сталкиваются постоянно: любая библиотека, сервис или API — это чужое решение с чужими приоритетами и ограничениями. И если зависимость критична — её либо изолируют, либо страхуют.
С контентом происходит ровно то же самое.
Просто об этом реже думают в таких терминах.
Telegram — удобный продукт. Быстрый, простой, почти без порога входа. Но это всё ещё продукт со своей моделью распространения, хранения и жизни контента.
Как и любая платформа, он оптимизирован под свои цели: ленту, скорость, вовлечение.
Не под архив. Не под внешний контур знаний. Не под долгую жизнь текста.
У него нет цели быть архивом знаний.
Нет цели обеспечивать полноценную индексацию.
Нет цели сохранять контент как устойчивый внешний источник.
Это не недостаток. Это осознанный продуктовый выбор.
Проблема начинается там, где этот выбор принимается молча.
И именно здесь возникает зависимость: контент вынужден жить по правилам, которые не предназначены для его долгой жизни.
Посты читаются здесь и сейчас, но плохо существуют вне платформы.
Их сложно цитировать как устойчивый источник.
Они почти не индексируются.
Они не образуют накопленного слоя опыта.
Кросспостинг расширяет охваты, но не решает архитектурную проблему и не снимает платформенный компромисс. Контент по-прежнему живёт по чужим правилам, просто на нескольких площадках сразу.
И если цель не просто публиковать, а сохранять, накапливать и контролировать результат, фиксировать решения и оставлять после себя что-то большее, чем лента, приходится честно признать зависимость и начинать думать, как с ней работать.
Риск очевиден: однажды платформа может измениться, исчезнуть или закрыть доступ. Контент станет недоступным. Архив потерянным. Контроль утраченным.
На практике вариантов немного.
Обычно всё сводится к двум направлениям.
Сохранение и фиксация контента как архива.
Первое, что приходит на ум: системы контроля версий и репозитории. Классический подход из разработки. Зафиксировал, задокументировал, сохранил.
Вывод контента во внешний, доступный и контролируемый контур.
Сайт-хаб: снижение порога входа до минимума, полная индексация, полный контроль. Твой контент. Твои правила. Твой архив.
Оба пути с разными плюсами, рисками и ценой входа.
И оба требуют как минимум PoC, прежде чем во что-то инвестировать. Даже время.
Именно об этом сейчас и идёт размышление: не о платформе, а о том, как изолировать её ограничения и вернуть себе полный контроль.
Я нахожусь на этапе определения пути и формирования гипотезы для PoC — проверяю, что работает, а что нет, и подбираю наиболее простой и подходящий для моего случая вариант реализации.
Сначала важно честно назвать боль и понять, с чем именно приходится иметь дело.
А о конкретных вариантах и реализации — в следующем посте.
На то он и «Код на вынос»
Приглашаю к обсуждению в комментариях, если тема отзывается.
Подписывайтесь, чтобы не пропустить продолжение.
#зависимости #платформы #контроль #архитектура #контент #индексация #poc #разработка #мысли #itshchen #codetogo
И чаще всего чужой.
В разработке с этим сталкиваются постоянно: любая библиотека, сервис или API — это чужое решение с чужими приоритетами и ограничениями. И если зависимость критична — её либо изолируют, либо страхуют.
С контентом происходит ровно то же самое.
Просто об этом реже думают в таких терминах.
Telegram — удобный продукт. Быстрый, простой, почти без порога входа. Но это всё ещё продукт со своей моделью распространения, хранения и жизни контента.
Как и любая платформа, он оптимизирован под свои цели: ленту, скорость, вовлечение.
Не под архив. Не под внешний контур знаний. Не под долгую жизнь текста.
У него нет цели быть архивом знаний.
Нет цели обеспечивать полноценную индексацию.
Нет цели сохранять контент как устойчивый внешний источник.
Это не недостаток. Это осознанный продуктовый выбор.
Проблема начинается там, где этот выбор принимается молча.
И именно здесь возникает зависимость: контент вынужден жить по правилам, которые не предназначены для его долгой жизни.
Посты читаются здесь и сейчас, но плохо существуют вне платформы.
Их сложно цитировать как устойчивый источник.
Они почти не индексируются.
Они не образуют накопленного слоя опыта.
Кросспостинг расширяет охваты, но не решает архитектурную проблему и не снимает платформенный компромисс. Контент по-прежнему живёт по чужим правилам, просто на нескольких площадках сразу.
И если цель не просто публиковать, а сохранять, накапливать и контролировать результат, фиксировать решения и оставлять после себя что-то большее, чем лента, приходится честно признать зависимость и начинать думать, как с ней работать.
Риск очевиден: однажды платформа может измениться, исчезнуть или закрыть доступ. Контент станет недоступным. Архив потерянным. Контроль утраченным.
На практике вариантов немного.
Обычно всё сводится к двум направлениям.
Сохранение и фиксация контента как архива.
Первое, что приходит на ум: системы контроля версий и репозитории. Классический подход из разработки. Зафиксировал, задокументировал, сохранил.
Вывод контента во внешний, доступный и контролируемый контур.
Сайт-хаб: снижение порога входа до минимума, полная индексация, полный контроль. Твой контент. Твои правила. Твой архив.
Оба пути с разными плюсами, рисками и ценой входа.
И оба требуют как минимум PoC, прежде чем во что-то инвестировать. Даже время.
Именно об этом сейчас и идёт размышление: не о платформе, а о том, как изолировать её ограничения и вернуть себе полный контроль.
Я нахожусь на этапе определения пути и формирования гипотезы для PoC — проверяю, что работает, а что нет, и подбираю наиболее простой и подходящий для моего случая вариант реализации.
Сначала важно честно назвать боль и понять, с чем именно приходится иметь дело.
А о конкретных вариантах и реализации — в следующем посте.
На то он и «Код на вынос»
Приглашаю к обсуждению в комментариях, если тема отзывается.
Подписывайтесь, чтобы не пропустить продолжение.
#зависимости #платформы #контроль #архитектура #контент #индексация #poc #разработка #мысли #itshchen #codetogo
💯2👍1🔥1
Контент без компромиссов (PoC)
В пятницу мы говорили о зависимости: контент живёт по чужим правилам платформ, а кросспостинг лишь переносит её на несколько площадок.
В прошлом посте я обозначил два пути: архив или доступность.
Оказалось, это ложная дихотомия.
Архив в сети — это и есть решение, если правильно выстроить архитектуру.
Эксперимент уже запущен.
Этот пост уже на сайте.
С чего началось
У меня был личный архив в Obsidian — Markdown-файлы и структура.
Работало, но не давало внешнего контура. Telegram не давал ни индексации, ни органики.
Что сделал
Markdown — источник истины.
Git — версионность и история.
Статический генератор — читает файлы, собирает сайт.
Сайт на бесплатном хостинге. Telegram — канал доставки, а не хранилище.
Результат:
Никаких серверов, баз данных и других дополнительных платформенных зависимостей.
Почему именно так
У меня уже был Obsidian с Markdown — использовал как базу.
CMS или кастомное решение = новые зависимости. Я выбрал минимум.
Markdown переживёт любой сервис.
Сайт переносится одним коммитом.
Telegram может исчезнуть — контент останется.
Плачу только за домен.
Что это даёт
Долговечность: текстовые файлы + Git
Доступность: индексация, постоянные ссылки
Контроль: я решаю где, как и когда публиковать
Масштабируемость: новый канал — один коммит
Что отсутствует в PoC
Автопостинг пока вручную.
Комментарии — в Telegram.
Фильтры заложены через тэги.
Работает ли это? Да — основные проблемы решены!
Это решение для всех? Нет!
Разный контекст = разные решения.
Но если боль совпадает — зависимость от платформ, потеря контроля и отсутствие внешнего контура — подход Content as Code может сработать.
Сейчас PoC-сайт работает: itshchen.ru
Это не продукт, а эксперимент.
Делюсь процессом и опытом, а не готовым решением.
Дальше будет развитие: версионирование изменений, изображения, миграция старого контента.
Об этом — в комментариях и следующих постах.
Обсудим в комментариях:
Как вы храните и распространяете свой контент? Какие факапы встречались?
#contentascode #эксперимент #контроль #git #платформы #poc #разработка #codetogo
В пятницу мы говорили о зависимости: контент живёт по чужим правилам платформ, а кросспостинг лишь переносит её на несколько площадок.
В прошлом посте я обозначил два пути: архив или доступность.
Оказалось, это ложная дихотомия.
Архив в сети — это и есть решение, если правильно выстроить архитектуру.
Эксперимент уже запущен.
Этот пост уже на сайте.
С чего началось
У меня был личный архив в Obsidian — Markdown-файлы и структура.
Работало, но не давало внешнего контура. Telegram не давал ни индексации, ни органики.
Что сделал
Markdown — источник истины.
Git — версионность и история.
Статический генератор — читает файлы, собирает сайт.
Сайт на бесплатном хостинге. Telegram — канал доставки, а не хранилище.
Результат:
Никаких серверов, баз данных и других дополнительных платформенных зависимостей.
Почему именно так
У меня уже был Obsidian с Markdown — использовал как базу.
CMS или кастомное решение = новые зависимости. Я выбрал минимум.
Markdown переживёт любой сервис.
Сайт переносится одним коммитом.
Telegram может исчезнуть — контент останется.
Плачу только за домен.
Что это даёт
Долговечность: текстовые файлы + Git
Доступность: индексация, постоянные ссылки
Контроль: я решаю где, как и когда публиковать
Масштабируемость: новый канал — один коммит
Что отсутствует в PoC
Автопостинг пока вручную.
Комментарии — в Telegram.
Фильтры заложены через тэги.
Работает ли это? Да — основные проблемы решены!
Это решение для всех? Нет!
Разный контекст = разные решения.
Но если боль совпадает — зависимость от платформ, потеря контроля и отсутствие внешнего контура — подход Content as Code может сработать.
Сейчас PoC-сайт работает: itshchen.ru
Это не продукт, а эксперимент.
Делюсь процессом и опытом, а не готовым решением.
Дальше будет развитие: версионирование изменений, изображения, миграция старого контента.
Об этом — в комментариях и следующих постах.
Обсудим в комментариях:
Как вы храните и распространяете свой контент? Какие факапы встречались?
#contentascode #эксперимент #контроль #git #платформы #poc #разработка #codetogo
👍2🔥1