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

Из этой серии статей вы узнаете о, вероятно, самой глупом, легко предотвратимом и дорогом провале 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, корпоративной этики и обычной профессиональной сдержанности.

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

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

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

Расскажем, как открытый API Kaiten позволил металлообрабатывающему заводу ПФ-ФОРУМ интегрировать ChatGPT и сократить время на постановку задач

Статья показывает четырёхшаговый метод исследования целевой аудитории за 2 часа вместо недель.
Шаг 1: метапромптинг — попросить ИИ самому написать промпт для Deep Research.
Шаг 2: прогнать промпт через Claude, ChatGPT и Gemini, синтезировать лучшее из каждой (метод Франкенштейна).
Шаг 3: Telegram-хак — экспортировать профессиональные чаты в JSON, конвертировать через forstartup.ru/telegram-notebooklm, загрузить в NotebookLM для извлечения непубличных инсайтов из реальных диалогов.
Шаг 4: загрузить все материалы в одну нейросеть для финального синтеза портретов ЦА и болей.
Разобрано на реальном кейсе: исследование для курса по маркетингу медклиник, с промптами для копирования и чек-листом.

Работая над большими проектами рано или поздно сталкиваешься с типовой проблемой: меняются команды, приходят новые люди, требования плывут, правки копятся в разных файлах и комментариях в Confluence. В одном разделе — одна версия ролей, в другом — другая. Описания функций разорваны, шаблоны не соблюдаются, а критичные решения записаны «на полях». Так и рождается хаос. Не потому, что кто-то плохо работал, а потому что в большом проекте с долгой жизнью и множеством участников документация неизбежно расползается.

Поэтому мы сделали своего ИИ-ассистента «ДокАрхитектор» — и в этой статье расскажем, как обучить нейросеть корпоративным стандартам, сократить время проверки ТЗ с 10 часов до 3–4 и перестать бояться унаследованных проектов.

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

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

Discord аналогично: в нём была и рабочая коммуникация в студиях и агентствах, и голосовые комнаты во время игры в доту. Оба сервиса закрывали сразу два сценария: личное общение и работу.

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

Мы изучили больше 30 мессенджеров и отобрали 13 штук, которые решают, хотя бы с натяжкой, оба эти сценария. 

Оценивали по критериям:

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

Такие истории заканчиваются не быстро. Судебные разбирательства по правам на ПО, это от года до трёх лет, экспертизы исходных кодов, пяти- и шестизначные суммы судебных расходов. Итог зависит от того, что компания успела сделать до конфликта, а не после.