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

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

Привет, Хабр! Меня зовут Елена Маламут, я руководитель проектов в IBS с 2015 года, и за это время мне не раз приходилось принимать проекты на разных стадиях реализации — в том числе и те, что уже столкнулись с трудностями.

Привет, я Александр Шакмаев продуктовый менеджер в Cloud.ru. Этот год принес массу AI-активностей и, уверен, многие столкнулись с почетной миссией внедрения AI в команду, свои процессы и компанию в целом.

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

Недавно я активно занимался отправкой и проверкой пул-реквестов проекта PyTorch, созданных с существенной помощью LLM. Этот процесс сильно отличается ситуации в начале года, когда было понятно, что LLM вполне подходит для проектов, создаваемых с нуля, но для кодовой базы в продакшене их код оставался безнадёжно низкокачественным. Можете посмотреть мои смердженные PR, в описании которых упоминается Claude Code; у Джейсона Энсела тоже был подобный опыт (ссылка на Meta*; также есть список issue, на которые он ссылался в совей статье). Сейчас всё активнее обсуждается (Саймон Уиллисон, LLVM) то, как процесс код-ревью должен адаптироваться к этой новой эпохе LLM. Мой вклад в эти обсуждения таков: внутри команд код-ревью должен поменяться, превратившись в первую очередь в механизм согласования с человеком.

Когда я рос из инженера в управленца, мне казалось, что различия между CTO, CIO и COO во многом формальные. Все же "про технологии", "про управление", "про процессы".

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

Я прошёл путь от инженерных ролей до CTO и в том числе выполнял функции COO в компании до 500 человек (около 60 в IT департаменте), входящей в состав корпорации.
И именно на этом масштабе разница между этими ролями становится особенно заметной.

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

Велосити команды растет, таски в Жира отлетают в "Дан" как горячие пирожки, а GitHub окрасился в здоровый зеленый цвет ежедневных коммитов. Менеджер смотрит на это, смахивает слезу умиления, открывает праздничное шампанское и думает: «Ну наконец-то процессы заработали!».

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

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

Вы не просили, но я вам сейчас покажу откуда все пошло.

В четвертой части темы «что взять бизнесу из профессионального спорта» (см. ранее часть 0, часть 1, часть 2, часть 3) внезапно будет довольно неожиданное отступление про психологию, мотивацию и жизненный выбор, несмотря на обстоятельства. Можно сказать, что автор аккуратно и осмысленно зайдёт на территорию "мотивационной мотивации" - в том числе потому, что нынешний российский IT во многом превратился в готового клиента Тони Роббинса и иных инфоцыганских шабашей под общим лозунгом "где взять энергию".

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

1. Главный критерий высших стадий Спиральной динамики.

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

После этапов, которые были наиболее успешны (не путать с понятием эффективность) в прошлом – Красный и Синий, которым соответствовали руководители с этими же ведущими компетенциями: Красные – ориентация на результат любой ценой, Синие – главное, соблюдение стандартов и политик компаний. Приходят этапы, по которым живут компании нового века и поколения – Оранжевые, Зеленые, Желтые и Бирюзовые, все эти этапы развития компании роднит одно ключевое свойство: все они ставят во главу угла Человека, его как абсолютную ценность и конкурентное преимущество.

Кадры теперь реально являются самым ценным и важным активом компании. Так вот поэтому одно из самых важных качеств руководителя по-настоящему современной компании является его внимание к людям, то есть это Зелёный руководитель.

2. Почему именно Зелёные – это именно руководители высших этапов Спиральной динамики.

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

Эта история - не про плохой Agile, не про «тупых маркетологов» и не про «оторванных от реальности айтишников».

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

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

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

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

Пойми, что может Excel!

Вот прям как в знаменитом меме «А что, разве так можно было?!!!»

Профессионалы Экселя не знают программу. Они её ПОНИМАЮТ!

Привет, Хабр. Всех с наступившим Новым Годом.

На днях наткнулся на статью Махмуда Хашеми, в которой обсуждаются некоторые недостатки методологии семантического версионирования (SemVer), и в качестве решения этих недостатков предлагается использовать календарное версионирование (CalVer). В организации, где я работаю, по стандарту разработки требуется обязательно версионировать приложения по SemVer. Из собственного опыта использования SemVer скажу, что нашёл в ней ещё ряд недостатков, для исправления которых пришлось искать новый способ версионирования.

Я провёл неглубокое исследование научных публикаций 2023-2025 годов о влиянии ИИ-чатботов на психическое здоровье. Спойлер: влияние есть, но доказательная база пока слабая. Зато практические рекомендации по защите -> вполне конкретные.

ИИ отменяет продактов или наоборот делает их профессией №1? Рассматриваю позиции Булдаковой и Эндрю Ына + вывод для джунов и лидов.

12 лет ничего не писал на Хабре... За это время опубликовал две книги, завел себе Telegram-канал, где регулярно выкладываю фрагменты своих будущих книг (одна из них - про прикладную рациональность).

А тут, вдруг, задумался... А чего это я про Хабр-то забыл?.. В общем, вот вам статья о том, что такое прокрастинация. С намеками о том, куда думать, если хочется этого избежать.

3 часа ночи. Звонок от незнакомого номера. «Пользователи не могут залогиниться, п****ц».

Вы лихорадочно листаете Slack. Непонятно, где проблема и кого будить. Подняли тестеров — они тоже гадают. Бэкенд? Инфра?

Идёте во флудилку в телеге, ищете похожий ник тимлида. Не отвечает. Кто замещает — никто не знает. Начинается массовый обзвон. Через 40 минут находится человек. Смотрит код. «Не моё. Это к Сане — он, кажется, редирект криво поменял в гугл клауд консоли». Ещё 20 минут — поиск Сани, доступы только у него.

Утром все разбитые. CTO вопрошает. И становится ясно: баг простой. Проблема не в коде. Проблема в бардаке.

Знакомо? Я тоже через это прошел. И после такой ночи решил: хватит. Нужна система.

День начинался как обычно. Я, как всегда, не выспался. Сколько можно спать по 4 часа? Ладно, соврал — по 5.

Пошёл к другу на штаб-квартиру работать. Пешком — машину оставил жене. Дорога минут 20 всего, прогулка на свежем воздухе.
А голова — тяжёлая.

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

Многие думают, что большие компании не совершают ошибки. Но даже если у вас налажен процесс код‑ревью и всё тщательно проверяется, риск накосячить никогда не равен нулю. Хотя, конечно, всегда лучше учиться на чужих ошибках, чем на своих.

Меня зовут Юрий Беглецов, я технический продакт в Точка Банк. Мы с командой делаем универсальные API, чтобы клиенты могли интегрировать банк и дочерние сервисы прямо в свои системы. Иногда у нас тоже бывают провалы — обидные, серьёзные и даже забавные. Две истории из серии «никогда больше» — под катом.

В этом году я завершил историю со своим стартапом – проектом AI writing assistant (рассказывал свою историю тут). Она заняла семь лет, мы привлекли $1.5 млн инвестиций, 300 тысяч пользователей, а по итогу я сумел договориться об aqui-hire сделке с компанией-единорогом.

И поскольку конец года – отличное время для подведения итогов – я решил осмыслить этот опыт и дать несколько советов тем, кто только собирается или недавно начал работу над своим стартапом. А чтобы сделать материал еще более универсальным, в начале текста я собрал советы и уроки от Бена Хоровица – знаменитого американского продакт менеджера, CEO проданного за миллиард долларов стартапа и основателя крупнейшего венчурного фонда Andreessen Horowitz.

Получилась статья про уроки фаундерам от миллиона до миллиарда.

Привет, Хабр! Меня зовут Андрей Боков, я главный архитектор отдела разработки хранилищ данных в «Газпром ЦПС». Если вы хоть раз сталкивались с тем, что информация о сотрудниках не соответствует в различных корпоративных системах, например, 1С, электронный документооборот, корпоративный портал, система управления проектами, – вы понимаете, о чем сейчас пойдет речь. Мы пробовали решить эту проблему точечными интеграциями, но с ростом числа систем увеличивался и хаос в данных. Нам был нужен единый контур, который позволит проследить путь данных от источников до отчета.

Так началась работа над корпоративным хранилищем данных (КХД). Мы выбрали многослойную архитектуру и методологию Data Vault 2.0 – подход, который сохраняет историю изменений и дает возможность подключать новые источники без перепроектирования структур хранилища. В статье я расскажу про наш опыт, который будет полезен специалистам по работе с данными: руководителям, архитекторам, аналитикам и инженерам. Подробно опишу, как мы строили ядро КХД и какие уроки и инсайты вынесли по результатам реализации.