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

В очередной раз пытаемся понять: «есть ли место в нашей команде системному аналитику и нужен ли он нам вообще?»

Часть первая.

Я не помню ни дня, когда Azure не работал бы в стрессовых условиях.

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

Весной и летом 2024 года началась масштабная инициатива по увеличению количества VM, которое мог хостить каждый узел. С точки зрения бизнеса всё было понятно: повышение плотности уже имеющихся серверов гораздо дешевле, чем построение новых дата-центров. Развёртывания Azure на мощностях компании всегда были ограничены шестнадцатью VM на узел. До того года собственные коммерческие облака Microsoft работали максимум с 32 VM, и это всё равно крошечная доля от теоретически поддерживаемых гипервизором 1024 VM.

Цель заключалась в увеличении на 50%, до 48 VM на узел, с перспективой увеличения до 64 в будущем. То, что должно было стать задачей по повышению произвольных ограничений ПО, привело к росту вылетов и инцидентов на 50%. Проблемы масштабировались ровно пропорционально плотности.

Ранее, когда я ещё продолжал работать над планом переработки интерфейса гипервизора для нижней части стека узлов Azure, мы провели исследование с командой Core OS, отвечавшей за другую сторону Hypervisor API. Данные трассировки вызовов показывали, что агенты узлов вместе атаковали гипервизор через интерфейс пользовательского режима WMI, в пике достигая 10 тысяч вызовов в секунду. У команды Hyper-V не было информации о том, какие агенты отвечали за это и почему было необходимо столько вызовов. С нашей стороны тоже никто не мог дать определённого ответа. На этом этапе стало понятно, что проект портирования выгрузки Overlake не будет никогда завершён. Не только из-за описанных выше зависимостей, но и из-за самого динамического поведения стека.

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

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

Это материал по мотивам выпуска подкаста Podcast++ от Онтико и Ви.Tech. В центре разговора - Ольга Ортега, директор по данным и аналитике в Ви.Tech - IT-дочке ВсеИнструменты.ру, и Иван Лукьянов, коуч и ментор директоров и фаундеров крупных компаний. Говорили о жизнестойкости лидера: не как о красивом слове из популярной психологии, а как о практическом навыке, который проверяется не на конференциях, а в моменты, когда все идет не так.

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

Проектный шестиугольник, документация проектов, внутрянка проектных команд, фреймворки обратной связи, система обучения в проектной команде и всё самое интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Из этой серии статей вы узнаете о, вероятно, самой глупом, легко предотвратимом и дорогом провале 21-го века, из-за которого Microsoft чуть не потеряла своего самого крупного клиента (OpenAI) и доверие правительства США.

Скучным утром понедельника 1 мая 2023 я впервые вышёл на работу в Azure Core в качестве сениор-сотрудника команды Overlake R&D, разработавшей карту выгрузки и сетевой ускоритель Azure Boost.

Azure не был для меня чем-то новым: наверно, это самая длительная моя подписка на облачный сервис, который был запущен в феврале 2010 года под названием Windows Azure.

Не был я и новичком в Microsoft: с 1 января 2013 года я был частью команды разработчиков Windows, а позже помогал выполнять миграцию SharePoint Online в Azure; в дальнейшем я присоединился к команде Core OS в качестве разработчика ядра. В ней я помогал совершенствовать ядро, участвовал в разработке и реализации платформы Container, поддерживающей Docker, Azure Kubernetes, Azure Container Instances, Azure App Services и Windows Sandbox. Выпуск всех этих технологий привёл к получению множества патентов.

Кроме того, я участвовал в мозговом штурме при создании прототипов карт Overlake в 2020-2021 годах, в составлении драфта предложения коммуникационного протокола и сетевого стека Host OS <-> Accelerator Card ещё на том этапе, когда у нас было лишь последовательное соединение отладчика. Также меня привлекали в качестве специалиста по Core OS, и я помогал разработчикам Azure Core диагностировать глубокие проблемы операционной системы.

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

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

Один клик — и ваша документация может исчезнуть. Именно так и произошло с нами. Поэтому мы нашли open-source альтернативу, где данными владеем только мы — и никакой регион это не изменит.

На этой неделе, 2 апреля, исполнилось 234 года Монетному двору США. Сегодня это высокотехнологичный конвейер, выдающий до 28 млрд юнитов в год. Но если мы заглянем под капот этой индустрии, то обнаружим, что монетный двор — это старейший в мире пример стандартизации, борьбы с «взломом» (подделками) и промышленной автоматизации.

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

Если вы помните первую статью, я рассказывал про небольшое macOS‑приложение для фоновой записи таун‑холлов и других «скучных» встреч. Оно работает локально, без облака, транскрибирует прямо на Mac и не требует подписки — это просто инструмент для одной задачи, а не продукт‑мессия.

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

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

Что значит этот треугольник? Тут есть два ответа:

1) Его можно представить, как цель для руководителя проекта, а именно сделать нужное качество с установленным бюджетом и сроком. Так сказать выполнить проекцию треугольника во‑времени, и чтобы был он не подобным, а точным.

2) Также указывается взаимосвязь, что если у нас объем «поплыл» и начал увеличивается, то за этим самым начнет увеличиваться и например, сроки при сохранении бюджета, или бюджет при сохранении срока. И при этом что‑то будет происходить с качеством — и если ассоциация с качеством, как вписанным кругом прямая, то получается, при увеличении площади треугольника, оно будет увеличиваться? И если при увеличении сроков или бюджета, такое можно представить, то можно ли представить такое при увеличение объема? Если линейную связь между сроком и бюджетом с качеством представить легко, то с объемом сложнее.

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

Получается, не треугольник, а квадрат?

И тут стоит вспомнить, что слово, которое рука об руку вспоминается с словом проект, а именно риски. Сделать быстро — рискованно, делать долго — менее рискованно. Сделать с большИм бюджетом один и тот‑же объем работ, также менее рискованно. Риски можно увеличивать, можно уменьшать. Более того, из житейского опыта, ясно, что чаще всего именно риски являются следствием соотношения выше рассмотренных параметров. Получается, еще один параметр? И проектный треугольник уже даже не квадрат.

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

Помните, как вы внедряли Jira, Asana или Trello? Казалось, что это и есть цифровая зрелость: задачи поставлены, коммуникация прозрачна, все удобно.

Но есть один момент, который компании осознают по мере роста: эта связка хорошо работает ровно до тех пор, пока ваша компания не перешагивает порог в 100-150 сотрудников.

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

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

Удалёнка сдвигает рабочий день вправо. Утром — встречи и реакции на входящие, днём — операционка, и только к вечеру наконец доходят руки до задач, которые требуют головы. Итог: работаю до 22:00 (если повезет), утром с трудом включаюсь, и на следующий день всё по новой.

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

Дальше — про то, как я это починила: фиксированный конец дня, задачи в блоках, один короткий ритуал на 15 минут. Без радикальных перестроек и советов «вставай в пять утра».

почему ты не ленивый - и ты даже не устал

Есть состояние, про которое почти никто нормально не пишет. Когда ты открываешь ноутбук и внутри вообще ничего не происходит. Ни сопротивления. Ни интереса. Ни желания отвлечься. Просто пустота.

Ты смотришь на задачу и понимаешь: я могу её сделать… но не буду.
И вот это пугает сильнее всего.

Интервью с Николаем Прянишниковым в шоу «ИГРОКИ»: про выживание бизнеса, войну мобильных операторов, тантрический секс и способ воспитания 7 детей.

Легендарный бизнесмен Николай Прянишников! В его послужном списке — выжженная земля для конкурентов. Он превратил «Билайн» из локального игрока в гиганта с капитализацией в 8 миллиардов долларов. Он заставил неповоротливый Microsoft в России расти в два раза быстрее глобального офиса. Теперь он в «Астре» — кует софт для «Росатома» и строит цифровую крепость в условиях тотальной изоляции.

Николай Прянишников — один из самых результативных топ-менеджеров России. В качестве гендиректора сети фитнес-клубов World Class, Николай расширил сеть с 50 до 110 клубов. Сегодня он не стесняется говорить обо всем откровенно, даже о сексе для пользы дела!

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

Весь разговор доступен для просмотра на Рутуб-канале шоу «ИГРОКИ».

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

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

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

Результаты: установлено, что юридическая и проектная документация должна рассматриваться как единый набор документов, так как трудоустройство работников и разработка ИТ‑продукта не представляются возможными без заключения контрактов. Также была усовершенствована структура проектной документации, закрепленной в ГОСТ Р 59853. Среди основных преимуществ данной модернизации необходимо отметить возможность определения степени освоения ИТ‑субъектами требований, декларирующих документальное сопровождение процесса создания ИТ‑продуктов. Например, если ИТ‑субъект не оценивает последствия принятых управленческих решений, затраченные ресурсы, коммерческий эффект, то это может свидетельствовать об отсутствии у него внутренних стандартов по управлению ИТ‑проектами. Важно отметить, что отсутствие стандартизации негативно сказывается на создании ИТ‑продуктов, так как ИТ‑субъектам вновь и вновь необходимо будет искать оптимальное управленческое решение для проблемы, которая возможно была решена ранее в других ИТ‑проектах.

За 6 лет работы продакт-менеджером в разных решениях для автоматизации проектов я видел одно и то же много раз: выбирают систему по чек-листу — «есть Гант? есть ресурсы? есть бюджеты? берем!». Через n месяцев оказывается, что не так уж и важен сам факт наличия функций. Невозможность адаптировать продукт под реальные процессы — вот что заслоняет собой все остальное.

Типичные ситуации: купили систему X — удобно для простых проектов. Выросли, нужны сложные зависимости — уперлись в потолок, пришлось мигрировать. Взяли мощную корпоративную платформу — любое изменение требует заявки в IT и недель ожидания. Команды потихоньку работают в таблицах и простых таск-трекерах.

В статье вы найдете:

— еще одну неприятную историю о ведении проектов — с подсчетом денег в чужих карманах; 

— 4 проблемы жестких систем и их решения из моей собственной практики;

— разбор трансформации low-code Waterfall инструмента в Agile всего за неделю неспешной работы.

За последний год нейросети научились не только отвечать на запросы, но и выполнять цепочки действий, работать с инструментами, проверять результаты и корректировать поведение. Это вывело ИИ из режима «диалогового помощника» в сторону автономных исполнителей.

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

В этой статье постараемся дать исчерпывающую информацию по этой теме.

Привет, Хабр! На связи Владимир Сыропятов, Senior Analyst в Garage Eight. Я несколько лет занимаюсь антифродом, и за это время научился строить модели, писать SQL в три часа ночи при инцидентах и читать паттерны там, где другие видят шум. Но об одном навыке мне никто не сказал. Ни на одном курсе, ни в одной книге. Именно поэтому пришлось наступать на грабли — дорогие грабли — и прокачивать его самому.

Речь о коммуникации с требовательными стейкхолдерами в условиях неопределенности.

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

Назовем это явление «бюрократический атлетизм» и попробуем разобраться, чем он отличается от soft skills, корпоративной этики и обычной профессиональной сдержанности.

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

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

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