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

Привет Хабр! Понимаю, что постов на эту тему появляется всё больше, вижу как их количество растёт. Все они подходят к проблеме с разных сторон — я хочу показать свою.

Я фриланс-разработчик, 2 года опыта. В основном делаю телеграм-ботов и TG mini apps, иногда бывают заказы на лендинги, смарт-контракты и пентесты. Работаю на одной площадке — Кворк. Есть аккаунт на Fiverr, но там никто ни разу не писал, кроме мошенников...

Последние полгода я делаю проекты только при помощи LLM. Я почти не читаю код и не пишу его совсем — только логи иногда добавляю. Готов к летящим помидорам. Хочу рассказать о том, что я только вырос: в доходе, эффективности, доверии заказчиков. За эти полгода мой доход вырос почти в три раза, я нашёл двух стажёров, и дело идёт в гору — появились крупные заказы.
Но меня немного обескураживает, когда люди называют процесс разработки при помощи LLM "вайбкодингом". Я не могу назвать это ни вайбом, ни кодингом. Сейчас объясню почему.

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

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

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

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

Это — вторая часть цикла “Начало работы с Jira Automation”, в которой мы разбираем Smart Values и учимся применять их на практике внутри автоматизаций Jira.

Когда слышишь слово «API», первое, что приходит в голову — это технический набор функций для программистов. Но в нашей работе с Ozon Seller API я убедился, что API — это целый продукт, в котором нужно думать не только о коде, но и о двух разных аудиториях, метриках, бизнес-логике и даже внутренней политике большой компании.

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

Меня зовут Лев Савельев, я старший менеджер по продукту Ozon Seller API. В этой статье расскажу, как мы развиваем Seller API как продукт, с какими вызовами столкнулись, какие ошибки сделали и чему научились, и как вся работа связана с экосистемой Ozon — порталом dev.ozon.ru и существующим Магазином приложений для селлеров.

Компании по всему миру сегодня спешат объявить себя «AI-first», но всё чаще это звучит как красивый лозунг без реального содержания. В своей колонке генеральный директор Runway Сицы Чен предлагает честно взглянуть на этот разрыв — между тем, что организации декларируют, и тем, что на самом деле происходит внутри команд. Это размышление о том, как не превратить инновации в показное действие, почему настоящие преобразования начинаются с любопытства, а не с мандатов сверху, и что отличает компании, действительно осваивающие ИИ, от тех, кто лишь делает вид.

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

Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Я считаю, что если Agile не работает в вашей компании — то методология тут ни при чем.

Разберемся, в чем настоящая проблема и как ее решить.

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

Меня зовут Лея, я менеджер проектов в Lamoda. Я решила сделать ретро полезным и интересным для команды, вдохновившись примером одного из хабровчан и популярными играми. Опишу процесс на примерах с Pac-Man и Тетрисом, полученный результат и оставлю для вас рекомендации для применения в своей команде. 

Привет, Хабр! Меня зовут Юля Анпилогова, я менеджер команды индивидуальных интеграций CDEK. Мы стали первыми, кто не только запустил интеграцию с Wildberries по схеме DBS (delivery by seller — доставка силами продавца), но и создал единую точку подключения к маркетплейсам WB и Ozon. Этот опыт оказался похож на квест. Курьеры, не привыкшие спрашивать код, лимиты запросов API Wildberries и покупательница Елена, заказавшая тестовый ежедневник — всё это оказалось его частью. Сегодня в статье расскажу, как мы прошли этот путь.

Хабр, привет!

В INTEKEY мы прошли путь от стартапа до компании с солидным портфелем проектов, и за это время успели изучить все возможные вариации IT-договоров. Мы систематизировали этот опыт вместе с нашими партнерами — юридической компанией «Зарцын и Партнеры» при личном участии основателя Людмилы Харитоновой — и готовы поделиться решениями, которые превратят ваш договор из формального документа в реальный инструмент управления проектом.

Особое внимание в этой статье мы уделим новым законодательным требованиям 2025 года — от ужесточения 152-ФЗ о персональных данных до новых критериев для реестра отечественного ПО. Эти изменения существенно повлияли на риски IT-проектов, и мы покажем, как адаптировать ваши договоры к текущим реалиям.

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

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

Почему одни проекты мы бросаем, а другие — тащим годами?

В этой статье я разобрал, как мои прошлые проекты — от пиксельной игры до логического симулятора — помогли мне НИКОГДА не выгорать. Делюсь принципами, спасающие мои идеи от забвения.

В мире стартапов есть две религии. Первая молится на «быстро и дешево» (No-Code). Вторая — на «надежно и масштабируемо» (Hard-Code). Адепты первой показывают работающие приложения, собранные за выходные. Адепты второй снисходительно улыбаются, зная, что будет, когда в это приложение зайдет тысячный пользователь.

Истина в том, что технология — это не религия, а финансовый инструмент. В разных фазах жизни стартапа «правильный» выбор меняется на диаметрально противоположный.

Я не буду занимать ничью сторону, а просто покажу цифры.

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

Перевод свежей (ноябрь 2025) и вызывающей споры статьи об оценке роста производительности для разных работ при использовании LLM. Использованы реальные диалоги и оценено время, сэкономленное людьми в связке с LLM.

За полгода активного использования Cursor IDE я была поражена тем, насколько этот инструмент изменил мой подход к работе. Разработка превратилась в удовольствие: поэтапное планирование, реализация, умные подсказки – агент выполняет задачи активно, быстро и, что самое главное, практически именно так, как я хочу.

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

Казалось бы, недостатков почти нет. Однако, всякий раз, приступая к новой задаче, я начинала новый чат. Мне не хотелось перечитывать свои диалоги недельной давности, искать там контекст. Но настоящая проблема возникает, когда задача переходит ко мне от другого разработчика. У меня нет доступа к его диалогу с чатом. Я не знаю, почему он принял те или иные решения, какие варианты он и AI отбросили. Мне приходится заново вводить Cursor в суть задачи, тратя время на объяснение того, что AI-агент моего коллеги уже знал.

Еще одной проблемой всегда остается отсутствие наглядного понимания хода проекта. Глядя на код, я вижу результат, но не процесс. Я не вижу, как менялась логика принятия решений и куда движется архитектура. Git Log дает мне сухие факты ("изменен файл X"), но не дает ментальной модели.

Получается парадокс: наши локальные AI-агенты умнеют с каждым днем, но как команда мы страдаем от "коллективной амнезии" и отсутствия единой картины мира. Именно это натолкнуло меня на идею Когнитивного слоя проекта (Project Cognition Layer). Если у нас уже есть инструмент, который идеально хранит историю всех изменений (Git), почему бы не "накинуть" на него когнитивный слой, понятный и человеку, и AI?

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

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

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

Привет, Хабр! Сегодня проверим, какая нейросеть лучше помогает в программировании. На дворе 2025 год у нас подоспел GPT-5.1, подтянулись конкуренты вроде Grok от xAI и DeepSeek из Поднебесной, а на отечественной сцене выступают обновлённая Алиса от Яндекса и сберовский GigaChat.

Каждый менеджер хотя бы раз ловил себя на мысли: «Если не я, то кто?» Это вроде бы простая фраза, но за ней скрывается куда больше, чем желание увидеть проект успешным. Она задаёт тон всей культуре управления: той, где руководитель становится «героем», который раз за разом вытаскивает команду из дедлайнов, конфликтов и хаоса. 

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

Привет, меня зовут Арина, я Fullstack-разработчик.

Долгое время я была уверена, что «много работать» = «работать хорошо».

С помощью электронного документооборота физические лица могут получать госуслуги, устраиваться на работу, поступать в ВУЗ, оформлять кредиты, не выходя из дома. Организациям данный механизм позволяет сокращать издержки, связанные с созданием, обработкой и пересылкой документов. Электронный документооборот ускоряет и упрощает процесс обмена документами между компаниями и государственными органами. Более того, подключение к системам ЭДО сейчас нужно не только для удобства, но и в отдельных случаях является необходимостью: некоторыми документами можно обмениваться только в электронном виде. Системы ЭДО требуется для работы с маркированными товарами, прослеживаемостью, маркетплейсами и электронными торговыми площадками, для сдачи отчетности в ФНС и в другие государственные структуры.