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

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

Руководство организации понимает, что нужно что-то делать. Менять ситуацию в корне. Научить людей нормально работать. Как именно? В принудительном порядке отправить всех на корпоративное обучение управлению проектами. 

Однако это не работает. И ниже расскажу о трех главных причинах, почему корпоративное обучение управление проектами чаще всего будет бесполезным.

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

В прошлых статьях я прошелся по фразам:

Часть один: «Этого нет в ТЗ!» и «Этого нет в моей должностной!»
Часть два: «Мы проговаривали!» и «У меня нет ресурсов!»

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

Для поиска самыхтоксичных коллег (они же паразитирующие сотрудники), предлагаю руководителям, кроме всех стандартных методов, посмотреть на ситуацию через гид по девяти кругам «организационного Ада по Данте».

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

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

Добрый день, уважаемое сообщество Хабра! Я тимлид, и сегодня хочу поделиться с вами опытом поиска работы в 2025 году. Это первый раз в жизни, когда я искал новую должность, уже будучи лидом. В последнее время тема поиска работы всесторонне рассматривается с точки зрения разработчиков. Но как новые предложения ищут лиды?

Предлагаю вам вместе со мной посмотреть на ключевые особенности рынка вакансий лидов в России. Моё мини‑исследование не претендует на объективность: только одно (ладно, два) резюме и только один всем известный сайт поиска работы. Однако можно понять некоторые общие закономерности и обсудить то, как видят нас, лидов, наши потенциальные работодатели. Ну и поделиться друг с другом своими историями в комментариях.

Если вы лид, либо смотрите в эту сторону, а также если вы HR, приглашаю вас дальше.

Потерянные версии документов, поиски актуальных планов и отчетов, несоответствие статус проекта и реального состояния... Такое знакомо многим и менеджерам проектов, и спонсорам, и командам (которые считают, что проще написать заново). Дело не в плохих людях, а в отсутствии системы, которая учитывает статусы и этапы проектов.

Так как придумывать контент оказалось задачей не простой, а придумывать СТОЯЩИЙ контент почти невыполнимой, а писать тем не менее что-то хочется, то я немного снижу планку своего перфекциониста.

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

В целом, редкие проекты строго двигаются к своим запланированным и четко сформулированным целям, а какой-то хаос в предстоящих итерациях стоит закладывать сразу, смело отводя на него внушительную долю запланированного времени. А еще здорово, когда выстроены процессы ОТ и ДО, но как мы все знаем, суровая реальность далека от идеала. Поэтому аки фокусник тебе так или иначе придется выполнять разные роли и задачи из разных областей рабочих обязанностей. Потому что, если ты архитектор или инженер, то какие-то мелкие договоренности о встречах, адресах или настройках легче проводить самостоятельно и глупо дергать РП (если вообще таковой на проекте имеется) для каждой фиксации мелочи, а с другой стороны где-то надо искать грань, когда количество времени на организаторскую работу превышает мыслимые и немыслимые пределы и вместо архитектурной или инженерной работы (на какую ты собственно и договаривался словами через рот) ты занимаешься какой-то сплошной тратой времени, когда вот эти мелкие задачи занимают настолько много времени, что становятся скорее рутиной, нежели неприятным, но быстрым обязательством, которое ускорит достижение цели, сократит человекочасы, потраченные на проект и в целом поможет сделать все хорошее, против всего плохого.

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

Сначала планировал зайти в 1С — устроился в 2014 году помощником программиста. Четыре года обновлял базы, ничего сложнее не давали. Зато на работе было много свободного времени.

Начал изучать PHP и Java — хотел попробовать бэкенд. Ходил на собеседования, но в 2016-2017 порог входа оказался высоким. Нужны были алгоритмы, профильное хорошее образование, глубокие знания. Таким самоучкам, как я, путь был заказан.

Кто-то подсказал — во фронтенде порог входа ниже. Сел изучать JavaScript по YouTube. Сделал тестовый проект — игру в домино, где костяшки раскидываются по столу и играют несколько игроков. 

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

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

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

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

Привет, Хабр! Меня зовут Анастасия Типакова, я руковожу группой развития технологий информационного моделирования инженерного направления в ПИК.

Сегодня расскажу подробнее про наш продукт ИОС (инженерное оборудование и сети) из экосистемы ПИК. Полное описание экосистемы можно найти в статье «Экосистема ПИК. История формирования».

Всё началось в далёком 2018 году, когда ПИК начал формировать продуктовую модель в Дирекции автоматизации проектного блока. Постепенно стало ясно, что готовые инструменты и сервисы прекрасно адаптируются под продуктовую модель. Так у нас появилась целая линейка продуктов: Family Manager, BIM Inspector, PikTools, Робот R2, BIM Data Service и PIK СheckUP.

Семь специалистов, семь Excel‑таблиц, и десятки требований регуляторов, которые обновляются со скоростью света.Каждая проверка — это гонка с дедлайном, хаос в переписках и отчаяние в глазах команды. Дошло до того, что отпуск одного сотрудника мог парализовать работу всей службы ИБ. Перемены не приходят в одночасье, обычно осознание того, что нужно что‑то менять приходит слишком поздно — а именно, после первого серьезного инцидента, когда урон уже нанесен.

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

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

Наш кейс — про один такой небольшой банк в России. Всего семь сотрудников в службе ИБ. И при этом — ГОСТ 57580, методические рекомендации 3/8/12, 72 форма отчетности и десятки других обязательных требований, которым нужно соответствовать.

Задали вопрос — получили ответ прямо в ChatGPT, а сайт-первоисточник так и не открыли. Это феномен «нулевого клика». Интернет превращается в высокоуровневый API, а мы — в его пользователей.

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

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

Команда учится делать не «лучше», а «правильнее». Развитие продукта замирает, потому что «в системе так не принято». Это и есть ДС-тюрьма: удобно сторожам, плохо заключённым.

Эта заметка развернулась из комментария к статье: Таски есть, системы нет.

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

В заметке я постараюсь выйти на эту ключевую проблему и затронуть вопросы вида:

Из чего такая система должна произрастать? Какие к ней требования? Есть ли примеры?

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

В этой статье я расскажу, о чём важно знать, прежде чем начать этот бизнес, какие сложности вас ждут и почему вы не сможете управлять командой из 20-30 человек без продвинутой аналитики.

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

В IT‑разработке тоже есть такая стадия — это поддержка того, чем осчастливили заказчиков. Если ее упустить, то даже идеально проведенная «операция» может закончиться осложнениями. Поэтому для аналитика понимание этой стадии не менее важно, чем участие в создании нового продукта.

Всем привет! Меня зовут Роман, я руковожу разработкой. Когда‑то начинал разработчиком, потом тимлид, сейчас управляю лидами.

В моём багаже опыта — работа работа в интеграторе, потом в небольшой компании из сферы SMS‑маркетинга, череда позиций в in‑house разработке в разных отраслях. А сейчас я снова в айтишечке, в заказной разработке.

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

Казалось бы, инструментов хватает: Jira, YouTrack, Trello, GitLab, Confluence и ещё десятки. Но если копнуть глубже, становится понятно: каждый из них решает только кусочек головоломки. Целостной картины всё равно нет. Она появляется только в голове после погружения, но и тут засада — голов в проекте много, и у каждой своя картинка.

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

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

Меня зовут Павел Крамин. Я много лет занимаюсь коммерческой разработкой для маркетинга и продаж на российском рынке.

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