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

Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру. В этот раз я решил помочь вам посмотреть на свою работу в отношении надежности. Особенно полезно будет тем, у кого официально нет SR-инженеров в штате.

"У нас нет SRE" – не значит "у нас нет надёжности". Даже без SRE-инженера ваша команда уже что-то делает для надёжности.

Покажу, как увидеть уже существующие у вас практики и понять, куда двигаться дальше.

Пошаговая инструкция и промпты для агента OpenAI Codex — создаем актуальную документацию проекта. А заодно упрощаем для продакт-менеджеров постановку задач программистам.

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

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

Объемный план на металлургическом производстве определяет, чего и сколько должно быть изготовлено на каждом этапе, чтобы вдруг не получилось, что доменная печь выдала на тонну меньше чугуна, чем нужно, чтобы раскатать стальные рулоны, которые ждет заказчик. Такие просчеты могут стоить миллионов.

Объёмный план затрагивает весь производственный цикл: от закупки сырья и управления запасами до отгрузки продукции клиентам и, конечно, включает производство. Все должно быть согласованно, четко подогнано одно к другому и работать как часы. Без крутой ИТ-системы здесь не обойтись.

С 2016 года мы пользовались зарубежным софтом, но система устарела, а обновления стали недоступны. Нам предстояли муки выбора российского решения, инженерные компромиссы и кастомизация. И тут мы первыми в России рискнули сделать ставку на систему объемного планирования In.Plan. Только вот нюанс: решение было облачным, а нам был нужен крепкий on-premise прямо в нашей промышленной инфраструктуре, ну и других требований к кастомизации было миллион.

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

Итак, представляю на ваш суд пьесу "Неэффективная эффективность" в 13 частях от продуктового лидера с 20-летним опытом, который так и не смог решить маленькую проблемку.

Отказоустойчивый и масштабируемый энтерпрайз невозможно спроектировать по книжкам. Одно и то же решение может фигурировать и в best, и в bad practice — и, что забавно, иногда переходит из одного списка в другой. Ещё недавно монолиты считались злом, а теперь снова в моде.

Хотите посмотреть, как знакомые паттерны ведут себя в реальном контексте?

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

Всем привет, я Саша, инженер по тестированию ПО в Directum. Неотъемлемая часть моей работы — поиск слабых мест, недочетов системы. Фокус на недостатках оставляет отпечаток на образе мысли, взгляде. Работа требует внимания к деталям, определенного перфекционизма.

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

Дизайн-система (далее - ДС) стала признаком взрослого продукта. Ее хотят сразу: токены, компоненты, документация, идеальная консистентность и вот это всё.

Даже начинается одинаково: “Надо срочно навести порядок, у нас все разъехалось, давайте дизайн-систему”. Через пару недель появляются названия компонентов, правила, обсуждения, новые договоренности.

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

Как отделить зрелую необходимость от красивой прокрастинации, и как построить минимальный UI-каркас так, чтобы он помогал выпускать версии, а не превращал каждую итерацию в бесконечные согласования?

Делюсь своим опытом и рассуждаю, почему сегодня важность ДС переоценена.

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

Но есть нюанс. Если смотреть не только на личные кейсы, а на сухую статистику, картинка становится чуть менее радужной. По данным hh.ru и аналитике Хабра, в 2025 году количество IT-вакансий сократилось примерно на 25-30% год к году по сравнению с 2024. Это ещё не апокалипсис, но уже вполне себе тревожный звоночек. Особенно для тех, кто привык хорошо жить, вкусно кушать и планировал встретить старость на побережье, а не в очереди за соцпомощью.

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

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

Привет! Меня зовут Егор Сизов, в компании «Цифра» (дивизион Непрерывные производства) я руковожу направлением «Системы управления производством».

За этот год, среди прочего, я занимался двумя крупными проектами: организации сбора библиотеки готовых конфигураций и конвертацией конфигураций PI System в Платформу ZIIoT. 

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

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

В третьей часть темы «что взять бизнесу из профессионального спорта» (см. ранее часть 0, часть 1 и часть 2) будет подробно разобрана незнакомая множеству российских компаний вещь, на которой базируются команды и даже целые лиги в игровых видах спорта – это скаутинг. То есть целенаправленный подбор готовых, растущих или будущих талантов с последующим внедрением в свою корпоративную систему. Для того, чтобы после грамотной огранки из алмаза получить дорогостоящий бриллиант, что принесет существенный профит вам на дистанции. 

Недавно мы с командой посчитали, сколько времени уходит только на то, чтобы найти информацию о задаче. Получилось около 8 часов в неделю на человека — это целый рабочий день, который тратится на переключение между Jira, Excel, почтой, Service Desk, GIT,  Confluence и ещё парой внутренних систем. При этом половина контекста всё равно теряется где-то между инструментами. Знакомо?

Плохая новость: проблема не в конкретном таск-трекере.

Хорошая: есть системный подход, который обкатан на реальных внедрениях — он опирается не на «ещё один инструмент», а на процессы.

Меня зовут Артём Герасимов, я владелец продукта SimpleOne SDLC. Ниже — разбор, как из зоопарка разрозненных систем прийти к единому потоку разработки, где инструмент подчиняется процессу, а не наоборот.

В Codex появилась экспериментальная фича — skills: декларативное описание локальных «навыков» агента с автоматическим discovery и строгими правилами применения. В статье разберём, как это работает под капотом, зачем нужно и как использовать это в своих проектах.

В новой части цикла статей «что взять бизнесу из профессионального спорта» (часть 0, часть 1) речь пойдет про скорость мышления и скорость принятия решений – вещь, которую я пытаюсь вдолбить рашнбизнису уже несколько лет, и очевидно, надо продолжать вдалбливание, потому что с той стороны нет ни осознания проблемы, ни попыток подхода к снаряду. А те, кто это осилили, по странному стечению обстоятельств являются либо крупным бизнесом, либо одним из лидеров в своей рыночной нише. Попутно будет разобрана далеко не всем очевидная тема «элита тянется к элите», которую можно и нужно использовать на рынке, если, конечно, вы не вице-президент «Норникеля» (там в голове только про деньги). В общем, план понятен, давайте приступать.

Наличие всевозможных методологий по управлению проектами внедрения ERP-систем может запутать новичка [1-3]. Ведь проекты внедрения могут вестись согласно каскадной однопроходной модели или многопроходным, к которым относят итерационную и спиралевидные модели [4]. В первом случае говорят о применении PMBoK [1], во втором Agile направленных подходов [2], к примеру: Scrum, Kanban и др. Несмотря на информационный хайп и сложность внедрения корпоративных систем в подавляющем большинстве применяются каскадные способы имплементации. Поэтому понимание сути и особенностей применения PMBoK становится критичным.

Свод знаний по управлению проектами (PMBoK) дает базис понимания того, как управлять любым проектом, в том числе в области ИТ. Поэтому содержательная часть заполняется активностями и задачами, специфичными для корпоративных информационных систем [5]. Достаточно часто руководителями проектов внедрения информационных систем являются выходцы из функциональных консультантов. Последнее не исключает и обратную ситуацию, когда проектный менеджер есть лицо далекое от ERP-систем. Проходя через множество проектов имплементации, консультант обретает те необходимые знания, которые позволяют понять структуру и организацию проекта, однако дефициты в понимании проектного управления все равно могут остаться.

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

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

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

Недавно собрались с коллегами в эфире ТГ канала для разработчиков обсудить то, что сейчас волнует, кажется, каждого в индустрии — ИИ-инструменты в разработке. Не абстрактно «что думаете про ChatGPT», а конкретно: что реально работает, что нет, и почему при всём хайпе проекты не стали выходить быстрее. Вообщем, собрал ключевые мысли — дальше от третьего лица, включая свои реплики как участника.

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

В этой статье я хочу поделиться нашим опытом работы с голосовым управлением (VoicePicking/Pick-by-Voice*) на складах. Нашим партнером в этом направлении выступает компания Айвойс с платформой GOLAS. Мы начали работать с этой технологией несколько лет назад, и за это время внедрили ее на разных объектах.

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

*Voice Picking (голосовой отбор, Pick-by-Voice) — это технология автоматизации складских процессов, при которой сотрудники получают задания и подтверждают их выполнение с помощью голосовых команд через гарнитуру. Это полностью безбумажный и hands-free метод работы, который интегрируется со складской системой управления (WMS) для обмена данными в реальном времени.

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

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

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