Управление разработкой *

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

В зависимости от сложности схемы, печатная плата может быть выполнена в 1-2 слоя: тогда дорожки можно визуально "проследить", просветив их фонариком. К слову сказать, лет 20-30 назад инженеры вообще не испытывали таких проблем, так как печатные платы были формата сквозного монтажа и все дорожки были снаружи и, как правило, контрастные.

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

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

В данном случае, у меня на исследовании ключ автомобильной сигнализации. Как можно видеть по схеме, вся электроника крутится вокруг чипа A3XA5 QFN, работающего на частоте 27.6 МГц. С учетом того, что данное устройство является элементом безопасности, в интернете ноль информации по плате, чипу, алгоритму и т.д. Но это ненадолго: я провел собственное исследование и в скором времени опубликую свои находки! Поэтому, не переключайтесь ;)

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

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал

Когда задача считается выполненной

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

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

Мы поговорили с коллегами и попросили их рассказать, в какой момент для них задача считается завершенной. Их ответы читайте ниже.

Настя, тестировщик:

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

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

Ваня, системный аналитик:

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

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

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

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

Олег, android-разработчик:

Задача выполнена, когда:

1. Функциональность реализована и проверена вручную — примерно так, как это сделал бы тестировщик, но без учета конкретных тест-кейсов.

2. Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.

3. Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.

4. Новое поведение покрыто тестами, есть уверенность, что его не сломают случайно. Также важно, чтобы оно не сломало существующие автотесты.

5. Новое поведение поддерживаемо и расширяемо: его сможет понять и продолжить другой разработчик.

Выбор вакансии: как я кинулась во всё — и это не дало результата.

Есть разработчики, у которых развитие идёт линейно и предсказуемо: верстальшик → джун фронтендер → мидл → мидл в сильной компании → сеньор/лид/уход в бэкенд

Красиво. Понятно. Логично.

Но у меня кривая черта развития сначала бэк на Java в закрытом предприятии. Потом фулстек в фудтехе: в основном Vue, но ещё и Go (и все сопутствующее), и CUBA Platform (lowcode на java, он же «Тезис»), и n8n.

Широко. Разнообразно. Интересно.

Как я начала откликаться - на всё, что блестит

И сейчас Когда я вышла на рынок, то сначала я откликалась на все что близко:

1. Frontend - Vue / React / Angular
   Ну фронт же. Есть мнение, что «не нужно учить конкретный фреймворк — важны принципы».

2. Go
   а почему бы нет? Знаю , умею , курсы закончены, писала на нем

3. Fullstack (Go или JDK + фронт)

4. N8N, автоматизаторы особенно с ИИ
   Интересно. Растущее направление.

5. Lowcode платформы CUBA, тезис, WebTutor - замаскированный под фронтенд Опыт есть. Почему не использовать?

И это фатал еrror

1. Ошибка №1. Переключение контекста
   Очень сложно переключать контекст и даже синтаксис языка - на первом собесе по TS я не смогла вспомнить синтаксис (на ум приходил только java, так как он изучался более долго и в закрытой среде, ирония: хоть я на нем и не пишу, но разбуди среди ночи - код напишу)

2. Ошибка №2. Рынок
   Рассматривать вакансии на Angular, React без опыта в продакшене - на данный момент наивно.
   
   Рынок перегрет:
   - Vue ~ 1000 откликов за неделю,
   - React - 4000 ,
   
   Неужели Арина (или тот кто читает эту статью) ты думаешь, что кто-то будет рассматривать ваше резюме со Vue? Каким бы в целом хорошим инженером вы не были. Рынок не покупает «в целом».

3. Ошибка №3. Fullstack со связкой Go + Vue или JDK + Vue
   Фуллстеки со связкой go или jdk - это бред вакансии, это карьерный тупик.
   - PHP + Vue - норм
   - Node + Vue - норм,
   но Go + Vue - это нонсенс, это только подработка для поддержания штанов. Чаще это небольшие команды, поддержка, нестабильные проекты.

4. Ошибка №4. n8n — нравится, но это уже не совсем разработка
   Автоматизация, интеграции, AI — это интересно. Но это больше аналитика и orchestration, чем классическая инженерия. Если хочешь быть разработчиком — нужно понимать, куда ты смещаешь фокус.

5. Ошибка №5. Low-code — карьерный тупик
   Проблем с окружением больше. Кода меньше. Рынок уже. Ты становишься зависимой от конкретной платформы. И выйти обратно в «чистую разработку» становится сложнее.

Мой Hotfix: Фокус

Я поняла, что на падающем рынке выживают либо "универсалы" c ИИ подбоком, либо эксперты

Моя новая стратегия:

• Vue 3 + TypeScript + Nuxt (как зона роста)

• n8n — как подработку и интересный дополнительный навык.

Иногда рост — это не добавить ещё стек. А убрать лишнее.

Стоит ли давать разработчику второй шанс? Кейс об «эффекте бумеранга»

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

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

В такой ситуации тимлиду важно отделить эмоции от управления.

Второй шанс — это не про «пожалеть» и не про «наказать». Это холодный расчет изменившихся условий. Прежде чем принять решение, я задаю себе вопросы:

• Что изменилось в его ресурсе и фокусе?

• Появилась ли внутренняя мотивация вместо внешней?

• Готов ли он брать ответственность за результат, а не просто закрывать тикеты?

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

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

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

А как вы относитесь к «бумерангам»? Стоит ли входить в одну и ту же реку дважды, или в ИТ это не работает?

Плагин 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. По стилю общения вы будто общаетесь с Сеньёром, который вас презирает, зато резалт пушка

———

Прикольные фишки, которые я постоянно применяю

1. Через Antigravity прошу генерировать изображения со вставкой сразу в код, получается бесшовный воркфлоу Prompt => Generation => Insertion

2. Используй Claude CLI Opus 4.5 для Day to Day задач

3. Используй Codex CLI xhigh для задач на рефакторинг или поиск corner cases, он сильно тщательнее это делает

4. Планируя новую фичу, проси Claude создать локальный MD с планом, а затем Codex xhigh + Gemini 3 pro пусть покритикует этот план и напишет ниже свои комменты

5. Не забывай про кнопку ESC + ESC в Claude Code CLI

6. Claude Code CLI в начале сессии загружает себе CLAUDE.MD, Codex загружает в себя AGENTS.MD, а Gemini — GEMINI.MD.

7. Команда /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, но без подписок, ограничений и облака;

• можно ставить локально и делать музыку прямо на своём ПК.