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

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

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

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

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

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

Что может быть общего у забронзовевшего Waterfall и «выскочки» Agile? Как оказалось — очень многое.

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

Так-то API-контракт может быть не просто набором методов, которые «по-бырику» выставили, пока дальше код пишется, а что-то более зрелое и, соответственно, требующее более зрелого и продуманного подхода.

На что стоит обратить внимание при работе с API-контрактами внутри дружественной корпоративной среды множества разрабатываемых ИТ-систем?

На самом деле, мы, как ИТ специалисты, так и конечные пользователи довольно сильно привыкли к западным программным решениям за последние несколько десятков лет. Известные вендоры заполонили рынок информационных систем и технологий, начиная от Microsoft, Oracle, SAP, завершая SAS. В голове мелькала мысль: зарубежное, значит качественное и общепризнанное, довольно часто игнорируя тот факт, что есть и наше, отечественное программное обеспечение, в которое нужно инвестировать и которое требуется развивать. Казалось, что западные программные продукты безальтернативны, ведь их внедряют во многие предприятия, в том числе и государственный сектор. Особенно это касалось программных решений SAP, несомненно, линейка продуктов вендора обладает качеством, устойчивостью и масштабируемостью, однако инициативы вокруг SAP в какой-то момент превратились из средства реализации в самоцель. Выпуская программные решения на каждый чих, постоянно обновляя продукты до более совершенных версии, SAP-проекты превратились в успешный бизнес, дающий выгоду не столько конечным пользователям, сколько руководству и компаниям интеграторам. Сейчас же нам предстоит вернуться с небес на землю, вспомнить, что такое кастомная разработка и отечественные программные решения, чтобы занять ту нишу, что оставили за собой, уходя, зарубежные вендоры. В связи с этим, разберемся, что нужно делать для вывода нового программного решения на российский рынок.

Основными документами, описывающими план действий реализации корпоративных целей предприятия служат:

Привет! Я лид системных аналитиков в департаменте корпоративных систем ЛАНИТ. В этой статье я расскажу, как писать качественные постановки на разработку информационной системы. 

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

В 2015 году дизайнер Golden Krishna выпустил книгу с провокационным названием "The Best Interface is No Interface", где на пальцах объяснял, почему мы слишком увлеклись экранами, кнопками и менюшками — и совершенно забыли про саму задачу, которую пытаемся решить. Идея была в том, что лучший интерфейс — это тот, которого ты вообще не замечаешь, который просто работает где-то на фоне и не требует от тебя бесконечных кликов.

Прошло десять лет, и мы действительно пришли к тому самому "отсутствию интерфейса" — только совсем не так, как представлял себе Krishna, и уж точно не через какие-то ambient-девайсы и IoT-хитрости. Мы просто вернулись в командную строку, потому что теперь там появился кто-то, кто наконец-то нас понимает.

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

Заметили, как тихо стало в личке? Вспомните далекий 2021-й. Открываешь LinkedIn — а там DDoS-атака. Звали в Берлин, в Лимассол, в Долину. Предлагали релокацию, опционы, «только выйди завтра». Айтишка была легальным чит-кодом к жизни, IDDQD современной экономики.

А сейчас, в январе 2026-го? Вечеринка давно закончилась. Западные рекрутеры для нас не просто исчезли — они стали мифом, о котором рассказывают новичкам у костра. А местные... Вакансии есть, денег много, но требования жестче, а задачи всё больше напоминают «ремонт завода на ходу под обстрелом дедлайнов».

Те, кто пришел в профессию после 2023-го (сегодня они уже крепкие мидлы), вообще не понимают, о чем мы грустим. Для них закрытый контур — единственная реальность. А в чатах «старичков» висит тяжелый, невысказанный вопрос: «Пацаны, а что, магия всё? Мы теперь... просто заводчане с клавиатурами?»

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

В глобальной JVM запустился Garbage Collector. А российский сегмент уже четыре года как работает в режиме Network Partition. И если отложить эмоции, то мы наблюдаем финальную стадию действия Второго закона термодинамики в замкнутой системе.

В разных командах разработки наблюдается похожая картина. После внедрения ИИ в процессы он ускоряет не только работу, но и масштабирует уже существующие проблемы.

Мне приходилось внедрять ИИ в продакшн-среду в разных доменах — от классических моделей классификации до разворачивания собственных серверов под локальные LLM и интеграции генеративных моделей для усиления командной работы. В каждом случае вывод оказывался одинаковым.

Большинство инженерных проблем при работе с ИИ по-прежнему лежит в области дисциплины и мышления, а не в технологиях. Поэтому привычные инженерные практики требуют переосмысления.

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

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

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

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

Привет, Хабр! Меня зовут Антон, я руковожу направлением автоматизации тестирования BIOS/BMC в YADRO. Как-то раз я моргнул — и наша команда из 10 инженеров выросла до 35. Вместе с этим у нас появились направления и лиды, а значит, я больше не могу прийти в любую задачу и сам ее быстро закрыть.

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

Разбираем архитектуру, не пугаем. LLM — полезный инструмент при адекватном использовании. Но если марафоните сутками — это сигнал.

Кризисная линия: 8-800-2000-122 (анонимно, 24/7).

Привет! Меня зовут Дима, я продуктовый дизайнер. Мой путь в IT оказался связан с постоянной гонкой за релизами фичей. Я успел поработать в разных проектах—от небольших агентств и стартапов до бигтеха (и, как итог, сильно выгорел). В какой-то момент я решил попробовать себя в создании настольной игры. 

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

В «Release любой ценой» ты становишься релиз-менеджером и собираешь релиз из Backend, Frontend и Database. Твоя цель — зарелизить первым “любой ценой”: саботировать соперников багами и защищать свой релиз. Конечно, в игре есть AI — куда же без него в наше время—в виде дополнительной колоды случайных событий.  Если тебе кажется, что у тебя все под контролем, всегда можно вытащить из колоды Error 503, который выбьет тебя из игры. Победи, собрав все карты релиза, или останься последним выжившим.

PnP выложил на GitHub.

Недавно я активно занимался отправкой и проверкой пул-реквестов проекта PyTorch, созданных с существенной помощью LLM. Этот процесс сильно отличается ситуации в начале года, когда было понятно, что LLM вполне подходит для проектов, создаваемых с нуля, но для кодовой базы в продакшене их код оставался безнадёжно низкокачественным. Можете посмотреть мои смердженные PR, в описании которых упоминается Claude Code; у Джейсона Энсела тоже был подобный опыт (ссылка на Meta*; также есть список issue, на которые он ссылался в совей статье). Сейчас всё активнее обсуждается (Саймон Уиллисон, LLVM) то, как процесс код-ревью должен адаптироваться к этой новой эпохе LLM. Мой вклад в эти обсуждения таков: внутри команд код-ревью должен поменяться, превратившись в первую очередь в механизм согласования с человеком.

Когда я рос из инженера в управленца, мне казалось, что различия между CTO, CIO и COO во многом формальные. Все же "про технологии", "про управление", "про процессы".

На практике оказалось, что это три разных способа смотреть на компанию. И путаница между ними начинает дорого стоить именно тогда, когда бизнес перестаёт быть маленьким.

Я прошёл путь от инженерных ролей до CTO и в том числе выполнял функции COO в компании до 500 человек (около 60 в IT департаменте), входящей в состав корпорации.
И именно на этом масштабе разница между этими ролями становится особенно заметной.

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

Велосити команды растет, таски в Жира отлетают в "Дан" как горячие пирожки, а GitHub окрасился в здоровый зеленый цвет ежедневных коммитов. Менеджер смотрит на это, смахивает слезу умиления, открывает праздничное шампанское и думает: «Ну наконец-то процессы заработали!».

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

И мы все это делаем не со зла, просто это очень дорогой билет на историческую реконструкцию феномена, который называется «Эффект Хоторна».

Вы не просили, но я вам сейчас покажу откуда все пошло.

Эта история - не про плохой Agile, не про «тупых маркетологов» и не про «оторванных от реальности айтишников».

В этом обзоре мы собрали системы управления проектами, которые задают стандарты и полностью заменяют западные решения, а также нишевые продукты, которые закрывают узкие сценарии. 

Все системы включены в Реестр отечественных программ и соответствуют стандартам безопасности.

Это Docker-шаблон для Python + Poetry, рассчитанный на реальную работу, а не учебные примеры: воспроизводимое окружение, удобный dev-workflow, отдельные сборки под прод, dev, Jupyter и AI-инструменты.

Автор использует его в основном для DS/ML-задач, где важнее скорость и предсказуемость, чем экономия пары мегабайт образа. Шаблон обкатан в бою, экономит время и легко кастомизируется под свои нужды.

👉 Репозиторий на GitHub:
https://github.com/jamm1985/vim-python-docker-template

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

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

В этой статье мы шаг за шагом соберём базовый Docker-шаблон для Python с Poetry, который удобно использовать и для разработки, и для прода. В основе будет минимальное и воспроизводимое окружение, а всё остальное - Vim как IDE, Jupyter, AI-инструменты вроде Codex или Gemini - вынесено в отдельные образы и слои, которые можно подключать по мере необходимости. Начнём с самого главного - разберём Dockerfile и поймём, как собрать прочную и расширяемую базу для Python-проекта.

Почему руководитель разработки ПО заходит в видеоконференцию и полтора часа наблюдает, как разработчик пишет код? Короткий ответ:  он использует подход гемба — один из лучших способов найти слабые места в процессах.

Меня зовут Максим Ковтун, я директор департамента проектирования и разработки в IBS. В какой-то момент я понял, что постепенно отрываюсь от «земли»: технологии обновляются, команды растут, а я все реже вижу реальную работу людей — только отчеты, статусы и презентации. Тогда я вспомнил о японском подходе гемба и решил применить его для процессов разработки.