Планирование, отслеживание и контроль
Плагин Tasks. Часть 1
Этот плагин лежит в основе моей системы планирования.
Представляет собой простой, но мощный инструмент для работы с задачами.
1. Создаём в заметке задачу:
- [ ] Задача
2. Появляется выпадающее меню, в котором можно назначить даты начала и завершения задачи, выбрать приоритет.
3. С помощью палитры команд или горячих клавиш открываем расширенные настройки. Там можно сделать задачу повторяющейся.
💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале
Разработчик публично сообщил, что ему не нравится обновление для Obsidian, но не рассчитал свои силы. В реплаи пришёл CEO проекта и по-русски написал, что разработчик просто «не прочитал документацию». Ответ разработчика: да, я реально её не читал.
Добрый день, друзья! Меня зовут Грачья, мне полных 38 и я запустил свой первый серьезный бизнес в Армении. Кто-то скажет: "Поздновато", а я скажу: "Лучше поздно, чем никогда!"
За плечами у меня 15-и летний стаж работы в разных инженерных компаниях на разных должностях от инженерных до управленческих. Последние 7 лет я руководил комплексными проектами по созданию различных систем, включающих в себя разработку софта, схемотехнических решений и железа.
А сейчас понял, что пришло время работать на себя, создавать рабочие места, а не занимать их.
Буду писать о том, как я свою первую компанию основал, инженерный стартап по разработке интеллектуальных систем, об успехах и неудачах первого бизнеса, о проектах и технологиях.
Формат ведения будет смешанным. Буду ставить себе цели и показывать путь их достижения, рассказывать о сложностях и подводных камнях, делиться мыслями, советоваться, проверять с вашей помощью гипотезы и показывать реализованные проекты.
Как сказал Гагарин: "Поехали!"
Учитывая все ошибки, которые допустила прежняя компания, в которой работал по найму, я первым делом начал собирать виртуальную команду менеджеров по продажам. Ошибка заключалась в том, что руководство не признавало маркетинг, продажи, выставки, соц. сети.
Инженерный костяк у нас есть, не подумайте, что я начал с продажников, не побеспокоясь о самом главном. У меня 2 партнера в доле, которые полностью обеспечивают техническое сопровождение, разработку, сборку и тестирование.
За неимением бюджета на штатных специалистов и нежеланием брать кредиты я решил поступить нестандартно. Написал порядка 50 кандидатам в LinkedIn предложение о сотрудничестве, обещающее процент с продажи. Начал с 5%, но понял, что рынок требует 15-20%. С учетом средней стоимости инженерного проекта в 15000-20000$, получается хороший бонус. Даже если будет подписан всего 1 контракт в месяц, это выходит в 1.5-2 раза выше средней ЗП по Еревану.
На сегодня, откликнулись несколько человек, с двумя начинаем работать. Кстати, если среди читателей есть желающие, то я не ограничиваю себя количеством.
Что я сделал в первую очередь - написал всем контактам из записной книжки с предложением о сотрудничестве. В результате смог заключить 2 договора на создание автоматизированных измерительных систем. Их я опишу в отдельных постах. Это важный шаг, который позволит поддержать штаны команды на 3 месяца.
Далее я создал удобную систему для учета всего и вся. Перепробовав уйму PMских инструментов остановился на Coda.io Ее бесплатные функции вполне достаточны даже для командной работы. Скрины с коротким описанием выложу отдельно. Это полноценный аналог Notion, но мне понравился больше.
Выше я писал о двоих менеджерах, которые согласились с нами поработать. Метод их работы состоит в поиске заказов на таких площадках, как Upwork, LinkedIn. Надеюсь, что работа с этими ребятами даст нам постоянный денежный поток.
Вторая глобальная цель на ближайшие полгода, это создание концепции и MVP продукта, рассчитанного на массовое производство. Я думал так: "Eсли я найду 2-3 проекта на стороне, то у меня будет запас денег и возможность создать MVP продуктовой идеи." Звучит, как хороший план, учитывая тот факт, что уже есть 2 подписанных контракта и переработано порядка 6 идей.
Об успехах и неудачах буду регулярно тут отчитываться, что бы рука всегда была на пульсе.
Если у вас есть предложения о сотрудничестве/партнерстве, всегда буду рад обсудить.
PS Есть варианты смены имени аккаунта?) Возможно было бы правильней зарегистрироваться заново, но этот аккаунт был создан довольно давно и несет для меня определенную ценность.
Трамписты решили сделать королевский подарок многополярному миру в лице Индии, Китая и в меньшей степени России и Ирану с помощью остановки программы рабочих H-1 виз. Поясню свою мысль (я в курсе, что половина людей комментирует по заголовку, а 75% не читают дальше первого абзаца, но тем не менее):
Я тертый калач и не идеализирую получателей рабочих H-1 виз (сам был таким в 1991 году). Большинство из них так же мухлюет в резюме как и местные, и не являются светочами технологической мудрости или трудовой этики. Кроме этого время ожидания гринкарты по labor certification сидя на H-1 визе перешло любые разумные пределы: в середине 1990-х оно было 3 года, сейчас некоторые больше 10 лет ждут. Я уже не говорю что H-1 визы разбираются аутсорсерами, и даже большим компаниям остается таких виз с гулькин нос. Короче сейчас большинство предприимчивых технарей старается сделать O-1 (особые способности) и некоторые L-1 (перевод из иностранного отделения компании в американское).
Тем не менее для меня очевидно, что полный бан на такие визы - это выстрел Америки себе в ногу и начало фундаментального изменения отношения ученых и инженеров других стран к эмиграции в Америку. Они будут оставаться на родине и перестанут мечтать про прекрасное далеко. Так как прекрасное далеко станет фундаментально недоступно, они начнут делать не на отцепись в других странах. Уйдет мысль "то что я тут в Индии/Китае/России/Иране лабаю - это так, временно, а вот уеду в Америку - там буду работать на совесть по гамбургскому счету. Буду слать фотки себя в кампусе Гугла/Микрософта, друзья детства будут мне завидовать, а бабушка всхлопывать ладошами при виде моего дома в Редмунде или Купертино и говорить "какое богатство!"
Улучшится ли от этого уровень американских студентов, которые заместят иностранцев и с помощью ИИ будут показывать чудеса производительности и качества на рабочем месте? Есть конечно масса способных американских студентов. Но есть и масса неспособных. Может даже Вэнс притащит в Силикон-Вэлли молодежь из гор Аппалач и других неблагополучных районов своего детства и они вместо наркомании и сидения на пособиях станут писать код или делать дизайн. Как говорила Верочка из "Служебного романа": "Можно и зайца научить курить". А вы как думаете?
Зима в разгаре, а мы нанимаем: новые вакансии в SSP SOFT
Кто мы и чем занимаемся? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке — за прошлый год мы наняли 179 сотрудников, и уже в январе 2026 к нам присоединились 11 новых гуру!
Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.
Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.
Самые горячие вакансии прямо сейчас:
(а всего их 11 на начало февраля 2026 - см. ссылку ниже на ХХ-ру)
1️⃣ Fullstack QA Engineer (Node.js)
2️⃣ Java-разработчик
3️⃣ Системный аналитик (ритейл)
4️⃣ Data Разработчик (Oracle, Greenplum)
Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашей HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀)
Как развивать документацию и продвигать техписателей
В продуктовой команде документацией пользуются все, но ожидают от нее разного. Аналитику важно одно, разработчику — другое, поддержке — третье. Если не учитывать контекст, можно бесконечно что‑то улучшать и все равно не попадать в цель.
Даша, технический писатель Naumen SMP, рассказала о том, как через коммуникацию с командой она разбиралась в реальных ожиданиях от документации и выстраивала направление ее развития.
С чего вообще началась эта работа и какую задачу вы перед собой ставили?
Мы начали с целей. Во‑первых, хотелось сформировать понятное представление о роли технических писателей внутри команды. Во‑вторых — понять, чего заказчики действительно ждут от документации.
Как вы к этому подошли на практике?
Первым шагом мы составили каталог услуг технических писателей. Если ты хочешь, чтобы коллеги понимали твою роль, важно сначала самим зафиксировать, что именно ты делаешь и в каком объеме.
Еще мы выделили ключевых заказчиков и сгруппировали их. Это были аналитики и руководители продуктов, разработчики и тестировщики, поддержка, инженеры инфраструктуры, коллеги из маркетинга и дизайна. Благодаря этому вместо 51 интервью получилось провести 19, этого оказалось достаточно.
Как проходили интервью и что оказалось самым сложным?
Мы начинали с обсуждения каталога услуг. Потом говорили о проблемах с документацией и процессами, а в конце проверяли наши гипотезы.
Сложнее всего было работать с эмоциональными запросами. Потому что важно не останавливаться на эмоции, а докапываться до сути. Очень помогал метод «5 почему»: позволяет превратить раздражение в конкретное и решаемое требование.
Что получилось после обработки всех интервью?
Мы сгруппировали потребности и получили 12 направлений. Самые заметные — это нехватка понимания роли технических писателей, запрос на обновление интерфейса документации и очень сильная боль у разработчиков по поводу документации по API.
Как вы поняли, за что браться в первую очередь?
Использовали простой фреймворк приоритизации «ценность / усилия». Смотрели не только на то, как часто звучит проблема, но и на силу боли. Поэтому, например, поиск в документации стал приоритетнее аналитики — о нем говорили реже, но намного острее.
Какие результаты уже есть?
Мы собрали регламенты и знания о работе технических писателей в одном месте, сделали публичный каталог услуг, обновили интерфейс документации вместе с дизайнерами и разработчиками, а документацию по API переработали совместно с командой разработки: улучшили навигацию и примеры.
Твой главный вывод из этого опыта?
Документация развивается не сама по себе: она развивается через диалог. Коммуникация помогает не только улучшать тексты, но и выстраивать понимание роли, ожиданий и зон ответственности. Когда это появляется, становится проще принимать решения и двигаться дальше и в документации, и в продукте.
Роль Agile Coach мертва… да здравствует агент изменений
TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать такие спецы должны не "вечно", а проектно - как спецназ внедрения изменений.
Здесь и далее: скрам-мастер и аджайл коуч тождественны.
1. Выделенная роль в команде — это кража ответственности
Постоянно приставленный к команде Agile Coach (или Scrum Master, или Delivery Manager в роли «няньки») - это прямое забирание ответственности у руководителей.
Зачем компания платит продактам и тимлидам хорошие деньги? Наверное, не для того, чтобы кто‑то другой создавал атмосферу безопасности, фасилитировал и работал с людьми.
Если руководитель не умеет управлять динамикой команды — значит, его надо учить, а не ставить ему «костыль» в виде коуча (ну и спрашивать с него соответственно). Соответственно, большая часть работы Agile Coach → Change Agent это обучение тем навыкам, которых не хватает руководителям. Скорее всего в больших организациях уже есть T&D‑отдел, который и занимается обучением. Наша задача состыковать системно прокачивание самых актуальных навыков.
2. Коуч для руководителей и архитектор среды
Роль трансформируется в коуча для руководителей и человека, который проводит изменения (зачастую проектно).
Чаще всего наболее активная часть работы - это движение системы к зрелости через работу с лидами. Агенты по изменениям - архитекторы среды обмена опытом. Даже на разборах ситуаций по хорошему (и когда получается) надо молчать и давать слово коллегам руководителя, даже если знаешь «правильный» ответ. Система должна уметь саморегулироваться, когда нас не будет.
Тут еще есть научная обоснованность: в модели проведения изменений ADKAR доказательно видно как CLARC (people менеджеры) это те, через кого мы проводим изменения.
3. Тест на прочность: «А что, если я уйду?»
Agile Coach делает хорошую работу, если после его ухода система радикально не ломается. Посмотрите, как быстро команды откатываются назад и насколько (например, по метрикам), когда из них убирают скрам‑мастера.
Стабильная привычка, как известно, формируется около 3 месяцев. В зависимости от масштаба изменений вы можете работать 3-6 месяцев и довести команду до определенного целевого состояния.
Нет предела совершенству, но нам с вами не туда: доводить процессы и майндсет до идеальных состояний почти никогда не стоит. Команды после нашего ухода все равно откатятся (и это нормально, главное чтоб не до нуля). С точки зрения всей системы, нам важнее дотягивать другие команды, процессы, взаимодействия, целеполагание до базового и достаточного уровня (который каждая организация определяет сама). Это даст намного более сильный результат по всей организации.
Более того, если долго работать с одной командой - возникает привыкание и порой выученная беспомощность, вы тратите свое время неэффективно. Нужно зайти, настроить, передать ответственность лидам и выйти. А потом трекать (как в настоящем стартапе) - что получается у лидов и команды, что нет - и точечно консультировать.
4. Мы наняты бизнесом, а не командой
Прошли времена раздутых бюджетов, когда можно было плодить «аджайл ради аджайла» чтобы «оптимизировать процессы». В текущих реалиях (особенно с нынешними ставками ЦБ) каждая копейка на счету.
Мы должны уметь драйвить бизнес‑стратегию, будь то организационная трансформация, радикальная смена концепции стартапа, оптимизация костов. И часто команда будет считать, что это «не по аджайлу».
Балансировать перформанс и здоровье команды (например, удовлетворенность, отток, выгорание) - вот это реальная задача, с которой надо помочь руководителям справиться или продумать оркестрацию изменений.
Софт скилы - это новые хард скилы
Управление изменениями, оргдизайн, работа с сопротивлением и сложная фасилитация - язык не поворачивается назвать это «софт скилами». Сейчас это самые настоящие харды. И именно за эти харды бизнес готов платить.
PS: Больше об этих самых хардах и внедрении ИИ в моем телеграм‑канале.
Бесплатный акселератор, неожиданные грабли и куча выпитых чашек кофе: как мы проверяли гипотезы в IT‑стартапе
Привет, Хабр!
Вы когда-нибудь задумывались, почему команда опытных разработчиков, дизайнеров и QA, годами делающая успешные продукты для других, не может так же легко запустить свой? Мы тоже думали, что знаем ответ. Оказалось, что нет.
Нас четверо: бэкенд, фронтенд, дизайнер и QA. Годами работали в аутсорсе, делали понятные продукты по четким ТЗ. А потом в один день задались вопросом: "А чего это мы всё делаем проекты другим? Пора попробовать своё".
В прошлом году мы залетели в акселератор Южного IT-Парка (бесплатный, что важно). Опыт был яркий: где-то больно, где-то смешно, а где-то мы просто осознали глубину своего заблуждения.
В этом посте речь не об истории успеха. Это raw-опыт перехода из аутсорса в свой продукт и ключевые ошибки, которые мы осознали, когда привычный мир коммерческой разработки перестал работать. Надеемся, наш опыт сэкономит вам время и нервы.
Ошибка №1: Наш "MVP" оказался "MIP" (Minimum Imaginable Product)
В аутсорсе мы привыкли, что продукт должен быть законченным, красивым и работать без косяков. Когда мы начали свой проект, мы по инерции спроектировали и начали разрабатывать то, что сами считали "минимально жизнеспособным продуктом".
Инсайт пришёл, когда ментор спросил: "Вы поговорили хоть с одним потенциальным пользователем?". Мы промолчали. Мы потратили месяц на то, что на деле было "минимально вообразимым продуктом" - тем, что мы могли вообразить и построить, а не тем, что было минимально необходимо для проверки ключевой гипотезы.
Вывод: MVP - это не про ваш технический минимум. Это про максимум неопределенности, который вы готовы закрыть одной итерацией. Теперь наша первая задача для любой фичи - не накидать макетов, а сформулировать гипотезу и придумать самый дешёвый способ её проверить (часто это даже не код, а Landing Page, опрос или эмуляция процесса).
Ошибка №2: Мы недооценили силу еженедельных дедлайнов
Акселератор - это не про деньги (по крайней мере, в нашем случае). Это про дедлайны и сообщество.
Каждую неделю нужно было показывать прогресс. Сначала мы ненавидели этот формат. Он ломает перфекционизм, заставляет выкатывать сырые фичи и признаваться, что "в этот спринт мы не угадали".
Инсайт: Привычка "идеально доделать и потом показать" убивает скорость обучения. "Криво, но сейчас" стало нашим неофициальным девизом. Эти еженедельные отчёты заставляли нас постоянно задавать себе вопросы: «Что мы узнали на этой неделе? Какая гипотеза подтвердилась? Что будем пробовать дальше?».
Ошибка №3: Мы пытались работать "как раньше"
В коммерческой разработке роли четки, процессы отлажены. В стартапе это сломалось в первую же неделю.
Оказалось, что, например, бэкендеру нужно спорить о юзер-флоу, потому что от этого зависит архитектура. А всем вместе нужно каждый день решать, что делать прямо сейчас, потому что "долгосрочный план" меняется раз в неделю.
Инсайт: Стартап - это не проект, это режим работы, где все немножко product owner и немножко предприниматель. Наша привычка "делать свою часть идеально" часто мешала сделать "целое достаточно быстро".
И что в итоге? Стоило ли оно того?
Пока не знаем.
Заработали ли мы на пачку чипсов? Нет.
Кончился ли кофе? Да, много раз.
Получили ли мы то, за чем шли?
Абсолютно да.
Мы поймали тот самый драйв - делать продукт быстро, тестировать гипотезы, спорить и мириться, и чувствовать, что это наше. Мы вышли из зоны комфорта и увидели продукт со стороны бизнеса, а не только технической реализации.
Теперь, вооружённые этими (и парой других) шрамами, мы стартуем новый проект. С тем же энтузиазмом, но с меньшим количеством граблей (надеемся).
P.S. Если вы тоже думаете о своём продукте или уже на этом пути — делитесь в комментариях, с какими граблями столкнулись вы?
Описывайте проблему вместо конкретных рецептов
Обсуждали новую крупную фичу и произошел интересный поворот разговора. Я отвечаю за крупную часть системы и дал поверхностный(тк обзорный разговор), но комплексный взгляд на возможную реализацию. И невольно:) залез в зону ответственности команды фронтенда больше, чем как оказалось мне следовало.
Как "технический" человек я начал складывать пазл из вполне конкретных кубиков. И попал в одну из типичнейших ошибок менеджеров: скатился в "рецепт", сам того не заметив. И получил вполне справедливое возмущение от коллег.
Сам раньше тысячу раз обьяснял разницу между "постановкой проблемы" и выдачей конкретного рецепта ее решения "делай раз, делай два, потом строго направо".
В своем канале о разработке в стартапах делюсь опытом, заходите, буду рад!
Берегите себя и своих коллег от рецептов, ставьте проблему и не сужайте пространство решений.
Работающий продукт невозможен без документации
Работающий продукт — это не тот, который просто запускается. Это тот, который не заваливает поддержку одинаковыми вопросами и не требует больших переработок для новой фичи.
Мой путь в IT привел меня к системному анализу: до этого я пробовал себя и в роли проектного менеджера, и бизнес-аналитика, и даже частично тестировщика. И главная проблема каждого проекта, в разработке которого я участвовал — отсутствие документации.
Не снимаю с себя ответственности: зачастую объем документации зависел от моей работы, однако времени на нее было недостаточно — приходилось совмещать несколько ролей одновременно. Это, конечно же, приводило к путанице и большим проблемам в будущем. Отсутствие покрытия ключевых элементов системы приводит к багам и заваленной вопросами поддержке.
В моем опыте было несколько раз, когда я подхватывал проект за другим аналитиком. К сожалению, каждый раз мне приходилось либо восстанавливать и актуализировать документацию, либо писать ее с нуля. Так, на одном из проектов, была полностью неработающая ролевая система, на что постоянно жаловались пользователи. Пришлось делать, по сути, реверс-инжиниринг, выявляя текущие процессы, согласуя их с заказчиками, а затем передавая задачи разработчикам. На исследование системы пришлось потратить около недели, а дальше согласования, переработка, постановка задач и разработка архитектуры решения — заняло около двух-трех недель. Как только появилась документация и задачи были реализованы по ней — мы перестали получать по этому поводу какие-либо вопросы.
Целью другого проекта было его “возрождение” после полутора лет простоя. Багов — куча. Тестировщик спустя четыре месяца все еще ежедневно приходит ко мне с ошибками, на часть из которых мне сложно дать ответ: документация с прошлой разработки отсутствует полностью. Мне задают вопрос “Как должно быть?”, а мы не знаем даже того, для чего это вообще было реализовано. Разработка решения для устранения бага занимает меньше времени, чем поиск информации по этому функционалу.
Отсутствие документации вредит не только проекту, но и тем командам, которые с вами хотят интегрироваться. Вместо того, чтобы посмотреть Swagger для изучения эндпоинтов, приходится тестировать функционал, так как информация в нем неактуальная. Недавно попался в эту ловушку при интеграции с другим модулем: разработка нашей задачи на бэкенде отложилась минимум на неделю, пока другая команда не починит это у себя.
Важен обмен опытом, поэтому хотел бы узнать, как у вас обстоят дела. Сколько времени ваша команда тратит на задачи, которые можно было бы решить наличием актуальной документации? Какие артефакты вы используете в работе?
В дальнейшем планирую поделиться своим опытом ведения документации: процессы, шаблоны, виды артефактов и другое.
лайкните пост кто сейчас вайбкодит свои продукты и напиши в комментах что делаете. очень интересно!
Сколько я плачу за AI инструменты и как они у меня взаимосвязаны
Claude — мой основной AI инструмент уже как 9 месяцев — Плачу за него 100$
Состоит из Claude Desktop, Claude Code UI и Claude Code CLI
Если хочу работать в приятном UI с текстом → Claude Desktop
Если работаю локально с кодом → Claude Code CLI
Если хочу поправить код с телефона → Claude Code UI
Коротко что все это такое
• Claude Desktop — как чат GPT, но с поддержкой MCP + Skills и еще всякими штуками
• Claude Code — UI для работы с вашим репозиторием
• Claude Code CLI — Command Line Interface Агент. По сути это микс Claude Desktop + Claude Code по функционалу, но без интерфейса и работает внутри вашего компьютера. Мое любимое развлечение последних двух месяцев
Claude Code CLI — пока что самый прокачанный на рынке CLI агентов
———
OpenAI, который chatGPT — за него плачу 20$
• ChatGPT UI — им почти перестал пользоваться, только ради генерации картинок иногда залетаю. Они после недавнего релиза стали их генерировать на уровне с Nano Banana
• Codex UI(Аналог Claude Code) — UI для работы с вашим репозиторием
• Codex CLI (Аналог Claude Code CLI) — чуть менее прокачанный как Command Line Interface, но зато их модель Codex 5.2 Extra-high уделывает OPUS 4.5 в плане UI дизайна и продумывания/рефакторинга сложных вещей
Но в Codex CLI вроде как отсутствует аналог ESC + ESC из Claude Code CLI для откатки написанного кода, без него тяжко жить 🍌
OpenAI недавно признали то, что их гонка с Claude за тем, чтобы сделать лучший кодинг агент, привела к тому, что 5.2 потеряли человечность в общении и стали сильно более директивными и сухими
Это помогает при работе с кодом, но общаться с ней сложнее
———
Экосистема Google — плачу 8$ за Plus подписку
Google у меня для трёх вещей: картинки через Nano Banana, NotebookLM и Antigravity для просмотра кода. Халява за 8$
• Nano Banana, иногда Veo 3 для генерации картинок / видео — лучшие генераторы картинок / видео на рынке
• NotebookLM — прикольный RAG UI, всем советую потестить
• Antigravity — Fork VS Code по типу Cursor, но с продвинутым Agent Workflow. Есть доступ к Gemini Pro + почему-то Claude моделям. Плюс Antigravity может генерировать картинки сразу вам в код через Nano Banana, такой вот бесшовный воркфлоу
Ни Gemini UI ни Gemini CLI я особо не пользуюсь. Мне они кажутся сильно сырыми по сравнению с Claude Code | GPT
———
Как выглядит мой воркфлоу
Claude Desktop для задач, где мне хочется иметь приятный UI и фичи именно Desktop интерфейса. Например написание постов, создание табличек, графиков и всего такого — те задачи, где CLI сильно проседает по UX
Claude Code UI почти не использую, только когда нужно изменить репозиторий с телефона, например на улице или в поездке
Claude Code CLI — мой day to day tool для работы с кодом. Пишу на Opus 4.5. Для сложных задач прошу создать промпт для Codex.
Antigravity юзаю для просмотра кода и папок, иногда запускаю Gemini 3 pro как третье мнение
Codex, как я уже и говорил, требует особого навыка общения. так как она может думать по 40 минут и перековырять вам весь код, но зато она у меня всегда находит те корнер кейсы, которые не находит ни Opus 4.5 ни Gemini 3 pro. По стилю общения вы будто общаетесь с Сеньёром, который вас презирает, зато резалт пушка
———
Прикольные фишки, которые я постоянно применяю
Через Antigravity прошу генерировать изображения со вставкой сразу в код, получается бесшовный воркфлоу Prompt => Generation => Insertion
Используй Claude CLI Opus 4.5 для Day to Day задач
Используй Codex CLI xhigh для задач на рефакторинг или поиск corner cases, он сильно тщательнее это делает
Планируя новую фичу, проси Claude создать локальный MD с планом, а затем Codex xhigh + Gemini 3 pro пусть покритикует этот план и напишет ниже свои комменты
Не забывай про кнопку ESC + ESC в Claude Code CLI
Claude Code CLI в начале сессии загружает себе CLAUDE.MD, Codex загружает в себя AGENTS.MD, а Gemini — GEMINI.MD.
Команда /context покажет контекст текущей сессии, старайся держать его как можно ниже
Good context engineering means
OpenAI запустила корпоративную платформу Frontier, которая упростит компаниям развёртывание ИИ-агентов. Это часть стратегии OpenAI по укреплению позиций на рынке автоматизации рабочих задач.
Frontier позволяет организациям создавать ИИ-агентов и управлять ими с учётом настроенных ограничений и уровней доступа к данным. Идея в том, чтобы снять технические барьеры при запуске таких решений и ускорить их массовое внедрение в корпоративной среде.
Что с Релизом ?!
На днях случайно наткнулся на такую вот интересную картинку с глубокой мыслью про релиз и как говорится "зацепило".
Тема релизов очень отзывается у меня и накопилось много "материала" на эту тему. В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов.
Подписывайтесь, будем вместе создавать синергию знаний !
За 15 лет в разработке я участвовал на разных ролях в создании совершенного разного типа продуктов, как по способу запуска(десктоп, веб и тд), типу поставки(desktop, saas, onprem) так и по зрелости продукта(прототип, mvp, плановое развитие зрелого продукта, полное переписывание внутренней системы крупного банка и тд и тп).
Порефлексировав об этом опыте с точки зрения релиз-менеджмента я нашел несколько явных закономерностей в процессах сдачи релиза в разных типах продуктов и стадий их развития. Было бы очень интересно сравнить мой опыт с опытом читателей и дополнить его.
Дисклеймер: все ниже написанное исключительно мой опыт, он может не совпадать с Вашим и это хорошо. "Пусть расцветают сто цветов", будем учиться друг у друга.
В этом посте расскажу одну историю. Если тема "зайдет", то подробно систематизирую все известные мне архетипы и напишу уже полноценную статью.
В одной из организаций, в которой мне довелось трудиться были очень странные (на мой взгляд и на тот момент) процессы на всех стадиях разработки и it-поддержки(не продуктовой) продукта. Они сложились естественным образом при становлении организации и не подходили под мое определение "правильных", привитых мне в крупной организации.
Часть, относящаяся к менеджменту релиза также удивляла как ни странно своим отсутствием и незримостью и непрозрачностью для большей части команды разработки.
Все это происходило из за сочетания типа поставки: saas (вернее отсутствия onprem поставки и строгих проверок на стороне клиентов, как говорится "все свое" ) и факта сосредоточения функций релиза в умах 1.5 человек, 0.5 из которых уже давно не относилось к отделу разработки.
Назовем такой тип релиз-менеджмента "one man release managment". Он неплохо работал, пока разработка шла по привычному процессу в рамках небольших изменений логики. Все быстро и удобно. Один человек знает и код и деплой, описывать ничего не надо, планов развертывания строить не надо, планов отката также. И ответственность тоже шарить не надо ;)
Все конечно изменилось по мере роста сложности системы и вызовов перед командой разработки, но это как говорится "уже совсем другая история". Был ли у вас похожий опыт и как вы относитесь к такому устройству процесса релиза? видите ли все таки в нем плюсы или это "не правильно\в книжках пишут не так" ?
Всем добра и тихих релизов !
Новые вакансии в SSP SOFT на конец января
Кто мы? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке — за прошлый год мы наняли 179 сотрудников! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удалёнку из любой точки России.
Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
1️⃣ Python AI разработчика
2️⃣ Java Tech Lead
3️⃣ Data Разработчика (Oracle, Greenplum) (https://vk.cc/cTLO9g)
4️⃣ Системного аналитика (ритейл) (https://vk.cc/cTLOcv)
Что вас ждет в SSP SOFT:
✅ Рост: Центр компетенций для максимального апгрейда скиллов.
✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис.
✅ Баланс work-life: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀)
Представлен бесплатный открытый проект HeartMuLa, который генерирует музыку на уровне платных ИИ-студий. Это полноценная музыкальная «студия всё в одном»: можно создавать треки по описанию, делать песни в стиле любимых артистов и работать с готовым аудио.
Что умеет HeartMuLa:
пишет тексты песен через встроенный чат-бот;
генерирует треки с вокалом и текстом длиннее 4 минут;
можно загрузить любой аудиофайл, и ИИ перенесёт его вайб и стиль в новый трек;
работает даже на слабом железе: локальная версия требует всего ~3 ГБ видеопамяти;
простой и понятный интерфейс. Фактически: бесплатный аналог Suno, но без подписок, ограничений и облака;
можно ставить локально и делать музыку прямо на своём ПК.
Интуитивные управленческие решения и значение контекстного интеллекта для управленца
Приветствую!
Хочу поделиться с вами статьёй, которая стала для меня настольной. Её написала моя руководительница диплома из Высшей школы экономики, Светлана Жоржевна Гончарова. И что удивительно — материал не теряет актуальности, а, как это ни странно, становится лишь более востребованным.
За годы работы в аудите, консалтинге и разных компаниях я часто задумывался и наблюдал за тем, как принимаются управленческие, а нередко и ключевые для бизнеса решения. Мысли из этой статьи находят стопроцентный отклик в моём опыте. Моя практика постоянно подтверждала идеи, изложенные в ней, и мне захотелось поделиться ими с вами — вдруг и вам будет полезно!
Задавались ли вы когда-нибудь вопросом: что является продуктом управленца? Чем измеряется его эффективность? Один из основных вариантов ответа — в конце поста.
Сталкивались ли вы с такими ситуациями?
Постепенная эрозия рыночной доли компании. Например, на рынке ИТ при наличии благоприятных экономических обстоятельств бизнес теряет позиции, а причина неочевидна.
Ваши ИТ-продукты теряют конкурентоспособность. Успешные когда-то программные решения лишаются своего конкурентного преимущества (product edge).
Уходят самые ценные сотрудники. Наблюдается необъяснимый и неконтролируемый отток талантов, ключевых разработчиков, архитекторов.
Все ресурсы брошены на один «мега-ультра-проект» в ущерб остальным процессам и деятельности компании.
Вы заключаете «супер-контракт» на разработку, а через несколько лет понимаете, что попали в зависимость от партнёра. «Кабальные» условия долгосрочных соглашений становятся ясны лишь спустя годы, и разработка некогда рыночного B2C-продукта превращается в обслуживание одного B2B-клиента.
Знакомо, правда? Часто руководители принимают решения на основе интуиции, «чуйки» и веры в свою удачу, руководствуясь иными мотивами, выходящими за рамки данного поста. А вот своевременные решения, основанные на глубоком понимании контекста, людей, на качественно собранных и проанализированных данных, я, к сожалению, встречал гораздо реже.
Именно поэтому я полностью поддерживаю основную мысль статьи и даже предлагаю дополнить идеальный портрет современного управленца навыком «контекстного интеллекта» — умения «считывать» обстановку и принимать взвешенные решения.
Более того, я бы рекомендовал включать в контракты, договоры или должностные инструкции топ-менеджеров пункт об обязательном всестороннем изучении контекста, совокупности информации и мнений для принятия взвешенных управленческих решений.
Если тема близка, очень рекомендую к прочтению саму статью: «Значение контекстного интеллекта для обучения руководителей».
Для справки: Contextual intelligence is the ability to understand the full situation (context)—including history, culture, environment, and human factors—to make wise decisions, adapt behavior, and act effectively, rather than just applying knowledge blindly. It bridges "knowing how" with "knowing what to do," blending technical skill with intuitive awareness of surrounding circumstances to achieve desired outcomes.
Сталкивались с подобными кейсами? Буду рад услышать ваше мнение в комментариях — делитесь мыслями и примерами!
И да, ответ на вопрос о том, что есть продукт управленца и чем он измеряется. Ответ предельно прост: своевременными, качественными и эффективными управленческими решениями. Продукт любого управленца, в первую очередь, — это управленческое решение.
Удачи в построении эффективных и устойчивых процессов.
С уважением,
Максим Торнов
Инструментальное средство PVS-Studio разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207—2024. Выявляет критические ошибки и может использоваться при разработке безопасного программного обеспечения по ГОСТ Р 56939—2024.
Я подготовил развёрнутый материал, посвящённый функциональным возможностям PVS-Studio на начало 2026 года с точки зрения перечисленных стандартов, приказа ФСТЭК №117, методического документа "Профиль защиты" и т. д.
Обзор PVS-Studio получился большой и явно не формата статьи для Хабра. Это вообще, скорее, мини-справочник на 66 страниц. В общем, я вас предупредил :) Тех, кто не испугался, а наоборот, заинтересовался, приглашаю познакомиться с материалом по ссылке:
Статический анализатор кода PVS-Studio в 2026: ГОСТ Р 71207, ГОСТ Р 56939, приказ ФСТЭК №117
Что можно найти в документе:
как связаны между собой PVS-Studio и различные ГОСТы;
требования к статическим анализаторам кода и насколько им соответствует PVS-Studio;
разбор технологий анализа, реализованных в PVS-Studio;
примеры выявляемых критических ошибок и что это такое;
характеристики анализатора: языки, поддерживаемые операционные системы, скорость работы, форматы отчётов;
и т. д.
Если вас заинтересовали озвученные здесь темы или у вас появились вопросы, то напишите нам.
P.S. Команда PVS-Studio будет со стендом на ТБ Форум 2026 (18–20 февраля 2026, МВЦ "Крокус Экспо", павильон 2, зал 10). Я там тоже буду. Приходите задавать вопросы на тему публикации, стандартов и вообще.
Электронные таблицы
Первая компания, где я работал, производила программное обеспечение и доставляла его на компакт-дисках. Курьеры-студенты периодически приезжали в офис, чтобы сдать выручку и получить очередную пачку дисков. Учёт велся в большом бумажном журнале. Постоянно возникала путаница: кто из курьеров сколько дисков взял и сколько денег должен.
Посмотрел я на это дело, открыл Эксель и набросал пару таблиц: журнал выдачи дисков и журнал расчётов. Получился инструмент, который сам считает, сколько дисков и денег на руках у каждого курьера. Задача была несложной, т.к. ещё в старших классах я где-то нашёл учебник по Экселю и прочёл от корки до корки. В итоге электронная таблица заменила бумажный журнал, а я прослыл в офисе главным автоматизатором.
Прошло четыре года, я уже пару лет как работал в другой компании. Раздаётся звонок. «Азат Лаисович, ваша таблица распухла и начала тормозить, можете помочь?» Я не поверил своим ушам. Они до сих пор её используют! Объяснил бывшим коллегам, как удалить исторические данные, таблица снова начала летать.
Умение пользоваться электронными таблицами — один из важнейших навыков. В личной жизни Эксель помогает настроить учёт коммуналки, запланировать путешествие и составить смету свадьбы. Стартапу или малому бизнесу электронные таблицы могут заменить дорогостоящие CRM и ERP. В большой компании Эксель позволяет выгрузить данные из сложной системы и быстро составить необходимый отчёт для аудита.
К сожалению, большинство людей осваивает Эксель методом тыка и продвигаются не дальше красивого раскрашивания ячеек. Хотите за пять минут делать работу, на которую ваши коллеги тратят часы — найдите учебник или курс по электронным таблицам.
А так ли надежен AI от Google?
Я публично веду исследование и собираю статистику причин провалов игровых проектов. Часто, как первичную точку для анализа того или иного игрового проекта я использую Google.
Однако, сегодня google меня немного удивил. На мой запрос: "What were the key issues with civilization vii game at the release"? Вот что сегодня, 20.01.2026 выдал Google:
AI Overview
Sid Meier's Civilization VII is scheduled for release on February 11, 2025 [1, 2]. As of today, January 20, 2026, the game has not been released, and therefore, it is impossible to identify key issues from its actual launch.
Однако, скорректировав запрос с уточнением "What were the key issues with civilization vii game at the release in 2025", я уже получил более разумный ответ:
AI Overview
Sid Meier's Civilization VII faced a rocky, "mixed" reception upon its February 2025 release, with many players describing it as unfinished and in a "rough" state. The launch was marked by complaints regarding fundamental gameplay changes, a poor user interface (UI), and missing quality-of-life features that left many long-term fans disappointed.
Обратил внимание, что часто от ИИ ожидают больше, чем он сейчас может дать. Тем более не стоит считать информацию формируемую генеративным AI полностью достоверной и не подлежащей проверке. Проводите кроссвалидацию с первоисточниками того, что вы получаете от генеративных нейросетей в форме утверждений.
Ранее я разбирал риски присущие ИИ в статье "Риски, присущие работе искусственного интеллекта".
Удачи в построении эффективных и устойчивых процессов.
С уважением,
Максим Торнов
P.S. Если вы заметили опечатку или неточность, буду искренне благодарен за сообщение об этом в личные сообщения.