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

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

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

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

Я, Гузель Хамидуллина, системный аналитик департамента управления данными Positive Technologies. Рассказываю, что помогло нашей команде объединиться.

Привет, Хабр! На связи руководитель отдела внедрения по технологиям информационного моделирования в ПИК Полина Павлова. 

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

Начало работы и создание первых инструментов

ПИК начал формировать продуктовую модель в Дирекции автоматизации проектного блока в 2018 году. В тот период времени компания основательно занялась переходом в BIM-проектирование (о том, что такое BIM можно узнать в ранее выпущенной статье «House Flipper в реальной архитектуре: как специалисты проектируют что угодно в цифровом симуляторе»). 

В то время лидером рынка ПО для проектирования был производитель Autodesk. В начале 2000-х Autodesk приобрел программное обеспечение Revit, которым до сих пор пользуются проектировщики из самых разных компаний для быстрого и удобного моделирования своих разделов с последующим оформлением и формированием комплектов согласно ГОСТам, применяемым в проектировании. 

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

У ПИК был и остаётся свой большой штат проектировщиков, дополненный огромной командой подрядчиков и аутстафферов. Для дальнейшего упрощения работы с большим количеством потребителей команда дирекции провела реструктуризацию, выделив при этом отдельных специалистов, которые занимались бы задачами развития новых технологий в проектном блоке (о том, какие могут быть сценарии формирования структур в BIM-командах, можно почитать в нашей статье «Правила построения BIM-команды»).

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

Уважаете ISO/IEC 27001, CIS и NIST CSF? Мы тоже. Фреймворков по кибербезу на свете лучше нет, но их недостаточно. Кибербезу, который застрял в догматической недопустимости событий и оторванном от ИТ-службы пузыре, нужен новый герой.

Рассказываем, как наша методология CyberYool делает акцент на киберустойчивости, а не кибербезопасности; помогает не только соответствовать требованиям регуляторов, но и делать так, чтобы эти меры реально защищали; и напоминает, что вообще-то ИБ и ИТ должны развиваться в компании вместе, а не играть в догонялки.

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

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

Что в статье:

✔ Опыт организации работы параллельной работы 10+ бэкенд-разработчиков

✔ Ролевая модель и бизнес процесс создания продукта

✔ Почему junior-разработчики могут быть продуктивнее middle’ов

✔ Метрики помогающие контролировать эффективность команды

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

Эффективность, продуктивность, самодостаточные команды, гибкость (или даже agility) – про это говорят спикеры, организуются круглые столы, записываются подкасты. Причины такой популярности, особенно сейчас абсолютно очевидны и оправданы. В нашей суровой реальности у компаний и предпринимателей крайне мало времени на совершение маневра.Ну и понятно, что любая нестабильность в командах (читай текучка или слабина ресурсов) – это дополнительная головная боль, временные и денежные затраты, которые сейчас есть куда использовать с большим выхлопом.

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

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

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

На этом моя карьера могла закончиться — но я нашёл выход. 

Привет, Хабровчане! Я Рома — продуктовый дизайнер Tomoru.Team.

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

Мы очень много говорим о проектах, с которыми работают бизнес-аналитики, о заинтересованных лицах, которые принимают решение, что проекту “быть” или, наоборот, обрубают проект на стадии поиска финансирования. Но откуда же берутся эти проекты и как сделать так, чтобы проект получил одобрение от лиц, принимающих решения в компании?

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

История начинается еще с тех времен, когда БА школа запускалась в рамках крупной компании, покинувшей пределы РФ после всем известных событий. Школа создавалась изначально как сервис, позволяющий внешним слушателям обучаться бизнес-анализу с нуля, а компании - пополнять ряды аналитиков “свежей кровью”. Дело в том, что на рынке бизнес-аналитиков спрос на специалистов в какой-то момент сильно обогнал предложение. А для того, чтобы переманить уже обученные кадры из других компаний, необходимо было покрыть достаточно большие зарплатные ожидания этих самых кадров. Поэтому было придумано эти самые кадры “создавать”!

Итак…начало…

Всем привет! Зовут меня Николай, я Project manager в компании 05.ru. В этой статье я расскажу о своём опыте решения проблем в управлении задачами, о сложностях, с которыми столкнулся, и о том, какие вопросы возникали при внедрении нового подхода к учёту и измерению длительности выполнения задач.

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

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

Magnit Tech не стал исключением, ведь я пришла в команду, которую только-только сформировали. То есть – ни одной странички в Confluence в нашем разделе.

Звучит пугающе? А меня это заинтересовало. Так что, в этой статье я расскажу:

Зачем –> определение конечной цели
Кому –> распределение ответственности
О чем –> выбор темы для документации
Когда –> выбор времени для написания
Как –> эффективное донесение информации.

А также поделюсь двумя вариантами подхода к написанию документации + как работать над стилистическим оформлением.

Собрались однажды В.И.Ленин, И.В.Сталин и В.В.Путин, и стали думать: “Как нам обустроить Россию?”
Нет, это не анекдот. Это я экспериментировал с мозговыми штурмами в ChatGPT. 
Получилось не очень. А Очень получилось с мозговым штурмом для мебельной компании.
Вот здесь есть что рассказать. Был по-хорошему впечатлен результатами.

Рекомендую этот способ для креатива, в том числе для всяких-разных житейских надобностей. “Креатива” не в смысле забрызгать окружающих яркими красками, а в хорошем смысле этого слова.

Рассказываю.

Исходная задача: Есть малый мебельный бизнес в Москве. С собственным производством корпусной мебели. По сути ничем не отличающийся от сотен других таких же. Как жить? Точнее даже - Как Выжить?

А, еще пара дополнений: 

Заказчики сказали о себе “Семейный мебельный бизнес”, но эту тему практически не используют.
Пробовали контекстной рекламой вести трафик на сайт, результат провальный.
Сейчас основной канал продаж - Авито.
С исходными данными на этом всё.

Для самых нетерпеливых: протокол мозгового штурма по ссылке, его итоги начинаются с 19 страницы: https://docs.google.com/document/d/1pGPf2zLAw3Ia7B9Tb0PbuujtJNlSkFseZnOHnzn68rM/edit?usp=sharing
Часть блоков, в которых одна вода, из протокола я удалил для компактности.

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

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

Всем привет! Меня зовут Гай, и я консультант, помогающий компаниям в разработке стратегии. В этой статье я расскажу о нашей модификации Х-матрицы — мощного инструмента для картирования стратегии организации, который пришел к нам из японской системы Хошин-Канри (Hoshin Kanri).

Технологи — особенные пользователи. У них огромная ответственность, руки в перчатках, на лице — защитные очки. В цехе полутемно или светится раскалённый металл, а им нужно отследить сотни параметров техпроцесса. И им очень хочется, чтобы всё работало как часы. Правда, представления об идеальной работе у них сильно отличаются от привычного UI/UX. 

Некоторые мастера внезапно просили нас усложнить интерфейсы. 

Прямо реально усложнить: добавить меню, подменю, передвинуть кнопку, сделать крупнее. Ответ очень простой: они привыкли к старой оракловой системе с интерфейсами из кучи выпадающих меню. Некоторые по 20 лет тыкали в эти менюшки и сформировали мышечную память. Где-то людей просто бесил порядок кнопок, например: «Кнопка «Отменить» всегда была справа. Переставьте, пожалуйста!» 

Аналогично — с горячими клавишами. Если восемь лет назад мастер запомнил, что Ctrl+R означает «Контроль реза», то так и будет нажимать в новой системе, рассчитывая на знакомое поведение. Поэтому мы подняли все старые комбинации и добавили их в новый софт. Теперь работают и новые горячие клавиши, и привычные опытным мастерам аккорды. 

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

В цехах мы узнали ещё много нового про UI/UX, а заодно про себя и свою работу.

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

Меня зовут Александра, и я — менеджер инкубатора Коллаб 2К24 от ВкусВилла. В 2024 году мы запустили программу, в рамках которой студенты — бакалавры и магистры ведущих ВУЗов России и СНГ разрабатывали свой инновационный продукт. Чтобы команды налаживали горизонтальные связи, делились опытом, получали качественную обратную связь от конкурентов и радовались успехам друг друга —  мы создали модель биржи ценных бумаг внутри нашего R&D Инкубатора. Это совершенно новый подход к акселерационным программам, который можно адаптировать и запустить под любой формат: корпоративная программа, учебный курс или стартап-акселератор. 

Самурай без меча подобен самураю с мечом, но без меча.
Японская пословица.

• Открыть юрлицо (как и любому бизнесу) и прикрутить оплату.
• Запустить ЦОД (у нас несколько площадок, и одна в собственности, потому что там серверы с иммерсионным охлаждением). Там из интересного, например, строительство оптических линий связи.
• И, собственно, соблюсти требования РКН по включению в реестр хостингов.

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

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