Управление проектами *

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

Меня зовут Константин Евсеев, я тружусь в компании VisionLabs, которая специализируется на технологиях биометрии и компьютерного зрения. В этом посте расскажу о проекте, к воплощению которого я хотел приложить руку еще за четыре года до его появления. Конкретно — о разработке системы для заселения в отель по биометрии. Почему? Все просто: если ты инженер и видишь, что что-то можно улучшить, то руки чешутся, пока не сделаешь. 

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

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

А я сажаю рядом Оппонента и даю ему возможность пару раз оспорить каждое правило.

Говорят, перед Новым годом нужно закрыть хвосты, договориться с командой и адекватно спланировать январь. Но кому нужно это геройство? 

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

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

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

В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который может «завалить» тестировщиков — сначала фрустрацией от рутины, а потом недовольством заказчика.

Во всех обсуждениях ценности ИИ-помощников в разработке ПО мне встречается одна печальная история: разработчик-джун, вооружившийся каким-нибудь LLM-инструментом, создаёт для своих коллег или мейнтейнеров опенсорс-проекта огромный нетестированный PR, ожидая, что всё остальное решится благодаря процессу код-ревью.

Такое поведение грубо, оно заставляет других людей впустую тратить время и идёт вразрез с долгом разработчика ПО.

Ваша задача — выпускать код, который доказанно работает.

Мы, разработчики ПО, не просто производим код; сегодня даже можно сказать, что для этого предназначены LLM. Мы должны выпускать код, который работает, и приложить к нему доказательство его работы. Если вы этого не делаете, то просто сбрасываете бремя настоящей работы на того, кто должен будет проверять ваш код.

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

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

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

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

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

Эта статья — не техническая документация для системных администраторов. Это гайд для владельцев бизнеса и ИТ-директоров, которые хотят понять природу «тормозов» в 1С, чтобы эффективно ставить задачи своим техническим специалистам или подрядчикам. Мы намеренно не углубляемся в синтаксис SQL-запросов, а фокусируемся на точках контроля, организационных причинах сбоев и экономике владения системой.

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

Проекты в АСУ ТП обычно заканчиваются успешно.

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

Новые инженеры месяцами «входят в тему», модернизации откладываются, знания живут в головах отдельных людей, а слово «стандарт» сводится к упоминанию ГОСТ и ЕСКД, которые никак не помогают в реальной эксплуатации.

Почему так происходит?

Потому что во многих компаниях стандарт находится ниже проекта, а не выше него.

Эта статья — не про ГОСТы, не про шаблоны и не про конкретные контроллеры.

Она про то, почему стандарт АСУ ТП должен быть частью бизнес-системы предприятия, как он влияет на простои, деньги, людей и зависимость от подрядчиков — и почему отсутствие стандарта обходится дороже, чем его внедрение.

Если вам знакома ситуация, когда система «работает, но лучше её не трогать» — эта статья для вас.

В середине года появилась адекватная метрика от Яндекса: она позволяла анализировать трафик и принимать решения о дальнейшем развитии направлений портала.

Пришло осознание, нашими пользователя являются люди практически со всего мира, метрика показывала пользователей из 133 стран, 50% трафика приходилось на Россию, остальные 50% на остальной мир.

Некоторые из них известны, некоторые - довольно узкоспециальные, но ВСЕ они очень полезны инженерам-разработчикам и проектным менеджерам.

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

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

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

Привет, Хабр, и с наступающим Новым годом! Меня зовут Станислав Пуртов, я – заместитель директора по автоматизации проектного блока в ПИК. 

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

Для начала давайте разберемся, что это такое, ведь под «удалёнщиком» до сих пор понимают разное. 

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

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

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

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

Пострадало четыре сервера из всего ЦОДа — и все наши публичные коммуникации. Потому что владельцы виртуальных машин пришли под все посты и везде оставили комментарии.
Параллельно была ещё одна история — под статьёй про то, что случалось за год, написал человек, мол, чего у вас всё постоянно ломается. Я вот размещаюсь у регионального провайдера, и у него за 7 лет ни одной проблемы.

Так вот.

Разница в том, что мы про всё это рассказываем. Тот провайдер наверняка уже раз 10 падал, останавливался и оставался без сети, но грамотно заталкивал косяки под ковёр.
Это значит — никаких блогов на Хабре, никаких публичных коммуникаций с комментариями (типа канала в Телеграме), никаких объяснений кроме лицемерных ответов от службы поддержки и т.п. И тогда, внезапно, вас будут воспринимать более стабильным и надёжным.

Наверное.

Ну а я продолжаю рассказывать, что у нас происходило. Добро пожаловать в очередной RCA, где главное в поиске root cause было не выйти на самих себя. Но мы вышли!

Приветствую, Новенький! Рад, что вы завершили онбординг в нашей корпорации ACME. У меня для вас есть первый тикет. Это простая задача, всего два сторипоинта, но она позволит вам немного научиться тому, как взаимодействуют наши сервисы. Просто реализуйте SLO доступности нашего сервиса Foo. Вы ведь знаете, как реализуются SLO?

Думаю, нам стоит стремиться к четырём девяткам. Я уверен, что вы в курсе всех best practices нашей отрасли, поэтому не буду надоедать вам советами. Если нужно, внизу есть бумажная Google SRE Book. Мне кажется, это быстрая задача; сможете представить свой SLO к пятничному демо?

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

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

Представим: важная задача висит в списке, дедлайн маячит, ты понимаешь, что делать её надо прямо сейчас…
Именно в этот момент ты:

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

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