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

Дисклеймер:

Эта статья написана полностью ИИ, на основе моего запроса к 10 разным нейросетям, с одним коротким запросом на тему "С чего начать, чтобы улучшить наше управление в IT-бизнесе".

Бизнес: 12 человек, сегмент "IT-бизнес" (обслуживаниие информационной инфраструктуры), вроде всё нормально, но хочется развития.

Некоторое сравнение сырых ответов 10 нейросетей приводятся в отдельной статье.

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

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

Обратите внимание - это чисто исследовательская работа, тут нет никакой рекламы. Прошу карму не снижать)

Итак:

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

Прощаемся с «Телегой» и думаем, как быть дальше

Замедление и возможная блокировка мессенджера в России огорчает многих. Понятно, что у аудитории Хабра больше навыков и компетенций, чтобы придумать умные прокси, бесперебойные виртуальные частные сети — VPN и другие хитрые штуки. Но если говорить не об ИT-специалистах, а об обычных людях, для которых «Телега» важна и на работе, и в быту, то всё выглядит печальнее. Да и по многим профессиональным сообществам ограничения мессенджера сильно ударили.

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

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

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

Меня зовут Дмитрий Синявский, я SRE в Ви.Tech, IT дочке «ВсеИнструменты.ру». В какой то момент я поймал себя на мысли, что вокруг DevOps снова спорят как в начале десятых: одни уверяют, что он умер, другие переименовывают все в platform engineering, третьи ждут, что ИИ наконец сделает всю грязную работу за инженеров. Мы с Владимиром Утратенко, который прошел путь от техподдержки до техдиректора и сейчас развивает платформу «Штурвал», спокойно разложили это по полочкам.

В этой статье я собрал самое полезное из нашего разговора: что стало с DevOps после хайпа, как автоматизация одновременно помогает и ослабляет, и какое место ИИ реально занимает в инженерке.

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

Самая интересная часть интервью касалась принципов управления столь крупной и стремительно растущей организацией. Вся система менеджмента там выстроена вокруг одного фундаментального принципа:

Представьте: команда взялась за инициативу, расписала задачи по спринтам, завела тикеты в Jira — и ушла пилить. Через квартал выясняется, что не успели. Или успели, но никому не нужно. Или руководство неожиданно "не поддержало".

Большинство провалов проектов и инициатив — предсказуемы. Их можно увидеть заранее, если знать, куда смотреть.

Для этого существует DICE-фреймворк от Boston Consulting Group. Это методика оценки вероятности успеха (или провала) проекта до старта.

Если вы хоть раз гуглили «как настроить Obsidian для задач» - вы знаете, чем это заканчивается. Три часа в YouTube, пять вкладок с гайдами, десяток установленных плагинов и... система не работает. Потому что это чужая система.

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

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

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

Привет, Хабровчане! Меня зовут Виктор Чижеков, я техлид команды разработки внутренних продуктов CDEK. В этой статье хочу поделиться своим опытом, как я стал техлидом, но продолжал быть разработчиком. Как переосмыслил свою роль и обязанности, как изменилось видение команды и как я начал на неё влиять. 

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

"Кино для Руководителей" меня часто спрашивают руководители на EMBA и в личных консультациях, что им почитать по теме управления. Обычно я предлагаю классику бизнес-литературы Джима Коллинза "От хорошего к великому", в которой есть всё самое важное.
А недавно подумал, что можно предложить и фильмы, где есть интересные варианты управления и ведения бизнеса, да и просто посмотреть хороший фильм полезно для перезагрузки.
Поэтому решил регулярно выкладывать свои предложения по таким фильмам и здесь.
Первый фильм "Да здравствует, Цезарь!"
Обратите внимание на поведение Эдди Мэнникса в исполнении Джоша Бролина, это почти идеальный вариант руководителя, который никого не унижает, он находит подход к каждому, умеет Сам решать любые задачи, знает всех сотрудников, от вахтёра до режиссёра.
Он почти идеальный, но к сожалению, всё зацикливает на себе и это проблема для него - семья его не видит, дети растут без отца, да и для бизнеса - если он уйдет, всё развалится.
И ещё один важный момент, Эдди Мэнникса практически каждый день ходит исповедоваться, так как чувствует внутри какое-то напряжение, что он делает, что-то плохое, как ему кажется.
Это напряжение уход только тогда, когда он получает предложение перейти в другую компанию с очень хорошей оплатой, но понимает, что ему реально интересно работать в кино, где он может реализовать себя лучше всего. Он отказывается от этого предложения, принимает себя в роли руководителя и главное, он начинает Делегировать задачи другим.
Финальный эпизод - это счастье руководителя, которые уходит от микроменеджмента, принимая себя в роли руководителя.
Отличный фильм с отличными актерами и полезной информацией для руководителей.
#КиноДляРуководителя #управление #hailcaesar #МихаилБоднарук

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

Личный опыт и разбор первой тактики перехода для уровня дохода 9+ млн/год

Многие мои коллеги и знакомые, достигая определенного карьерного потолка, совершают одну и ту же ошибку. Когда встает вопрос о смене работы, они действуют по накатанной схеме: «упаковать резюме, обзвонить агентства, разместиться на hh.ru». Это работает, пока ваш годовой доход не превышает 3–4 миллионов рублей.

Но когда мы говорим об уровне 9–10 миллионов рублей в год и выше, законы рынка меняются кардинально. Это «неструктурированный рынок», где публичных инструментов просто не существует. 

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

Почему ко мне пришел топ-менеджер из «Газпрома»

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

При его текущем уровне дохода (9–10 млн/год) просто откликнуться на вакансию — значит потерять время. Мы провели серию консультаций, наметили стратегию, и, как результат, он получил офферы сразу по нескольким каналам. Но обо всем по порядку.

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

Один из таких случаев — обновление парка из десятков тысяч рабочих станций с ALSE 1.7 на 1.8 без остановки бизнес-процессов.

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

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

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

Доступен ряд научно-популярных работ, описывающих различные подходы к построению ИТ-архитектуры, которые обобщены в терминах корпоративная архитектура и архитектура предприятия. Методологии построения корпоративной архитектуры представлены такими подходами как: FEAF, DoDAF [1], а также широко известная и наиболее популярная TOGAF [2]. Несмотря на кажущееся обилие стратегий к формированию ИТ-архитектуры, по большому счету, они апеллируют едиными сущностями, изначально предложенными в модели Захмана.

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

Цель текущей работы состоит в анализе модели Захмана и ее применимости в проектах реализации корпоративных информационных систем. Достижение сформулированной цели потребует решения следующих задач:

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

Я Алексей Соболеков, лид архитектуры F&R в Magnit Tech. Это мой личный взгляд на события, и в команде существуют разные их интерпретации.

В 2024 году команда F&R (подробности тут: Архитектура высоконагруженной платформы Magnit F&R) в MAGNIT TECH  столкнулась с нетривиальным вызовом: всего за один год необходимо было вырасти с 20 до 220 человек для формирования состава команд. Формально все выглядело благополучно - проект запущен, бюджет подтвержден, приоритет высокий. Но именно с этого момента в ИТ-команде разработки F&R начали накапливаться системные проблемы.

Две недели назад я опубликовал первый отчёт о запуске Telegram-бота MENO: 120 пользователей, retention 56%, один баг в парсинге дат и несколько человек, которые сами пришли помогать с фидбеком. Обещал продолжить - продолжаю.

В своей практике я часто вижу одну и ту же проблему. Корпоративные архитекторы проектируют схемы целевой архитектуры (в лучшем случае - в репозитории в ArchiMate, но чаще просто в PowerPoint) , Solution и Software-архитекторы принимают тактические решения, а итоговая архитектура реализованного решения всё равно "плывёт" и не соответствует задуманному.

Стратегия остаётся слайдами в PowerPoint. Принципы — просто слова на виртуальной доске. Команды разрабатывают "как удобно" (или "как быстрее), а не "как задумано".

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

В этой статье я разберу несколько ключевых концепций, которые помогают этот разрыв закрыть: Discovery и Delivery, TOGAF ADM и Change Management. А в финале покажу, как они агрегируются в IT-Governance — и почему архитектор-методолог (такую роль можно встретить очень редко в виде чётко сформулированного запроса) находится в центре этого агрегатора.

Сталь с клеймом «Старый соболь» прославила заводы Нижнего Тагила на всю Россию и Европу. Ещё пару веков назад качество этой стали ценилось так высоко, что английские конкуренты даже подделывали знаменитого соболька. Но как так получилось, что на Урале возникло производство, покорившее мировой рынок? С чего началась история промышленников Демидовых и в чём был секрет их премиального металла? Разберёмся в этой статье.

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

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

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