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

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

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

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

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

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

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

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

Делегирование в IT — штука тонкая. Руководитель не должен превращаться в «узкое горлышко», через которое проходят все решения и проверка каждой задачи. Можно нанять нового сотрудника, передать ему часть дел, а потом понять, что вы снова в ручном режиме ведете каждую мелочь. Знакомо? Меня зовут Владимир Лукашенко, и я автор —медиа «вАЙТИ».

Привет, Хабр! Я Роман Путилов, руковожу техническими менеджерами в Cloud.ru. Встреч у меня много, а времени на постмиты мало. Поэтому я отдал рутину искусственному интеллекту: он собирает черновик, а я за 3–5 минут довожу его до финала.

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

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

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

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

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

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

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

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

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

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

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

Меня зовут Юлия Ворожбицкая, я руковожу группой сопровождения и реализации проектов в команде «Цитрос». Мы работаем в высококонкурентном сегменте ECM, и каждый день сталкиваемся с задачами, где недостаточно «делать хорошо» — нужно создавать продукт, который востребован рынком. В этой статье я поделюсь нашим подходом к оценке емкости рынка и проведению CustDev — с методиками подсчета и личными выводами. Материал будет полезен Product Owner в B2B IT.

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

Вместо того чтобы просто уйти в игнор или ввязываться в словесную дуэль, я попробовал другой путь. Я взял проверенные временем идеи (Аристотеля, Канта и Хабермаса) и превратил их в промпт «детектор качества диалога».

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

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

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

Рассказываем о возможностях nanoCAD BIM Строительство для проектирования мостов и линейных сооружений, включая создание параметрических объектов, работу с библиотеками и интеграцию с другими BIM-решениями. На примере обучения сотрудников «Института Стройпроект» показано, как инструменты программы позволяют эффективно моделировать сложные конструкции, автоматизировать процессы и адаптировать решения под конкретные проектные задачи. 

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

При этом инструмент предлагает «единый вид всех элементов бэклога — будь то баг или задача по новому функционалу», что помогает приоритизировать общие цели команды. Это значит, что QA могут иметь в Jira общее пространство тест‑кейсов, задач на тестирование и найденных дефектов.

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

Статья будет полезна для всех участников QA‑команд (тестировщиков, тимлидов), кто базово уже разбирается с инструментом и хочет в него углубиться.

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

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

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

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

Я выстрадал предлагаемую на ваш суд модель за более чем 20 лет практической работы с разными командами, проектами и кризисами.

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

Логика триединства «И-цзин» не даёт инструкций, но помогает прочувствовать состояние времени сложной системы: где внешняя среда уже изменилась, а мы тянем прошлое, где человек выгорает, а система требует прыжка.

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

История, которая случилась полгода назад.

Ко мне на консультацию пришел Алексей. Senior Frontend разработчик, 8 лет опыта, блестящее портфолио, идеальный английский. Последние 5 лет живет в Европе, много лет работает на Upwork, неплохо оттуда зарабатывал. Но у него была одна проблема: его доходы начали падать.

Зачем Илон Маск дарит сотрудникам Tesla-кары, а в офисе Amazon делают тайский массаж и иглоукалывание?

Doxcer — плагин, позволяющий просматривать файлы в формате Docx в Obsidian, а также конвертировать их в md‑файл.

Ускоряет копирование информации из Word‑файлов в заметки, что полезно для офисов.

Всем привет! Меня зовут Антон Баранов, я тимлид разработки в компании "Синимекс", недавно я завершил работу над двумя микросервисными проектами в сфере финтех, а до этого был техлидом и разработчиком на проектах, связанных с БЭК-офисами и витринами данных. Сейчас я актуализирую свой чек-лист и хочу поделиться с вами размышлениями о том, почему старт проекта — это одновременно и самое захватывающее, и самое рискованное время для тимлида.

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