Недавно я завершила обучение на курсе от Google по программе Управление проектами Поэтому я решила подготовить цикл из шести статей, в которых постараюсь передать ключевые идеи курса для русскоязычной аудитории.
Курс состоит из шести разделов, и каждая статья будет охватывать один раздел. Вот их список:
Всем привет!
В этой статье — пошаговый разбор создания сценария использования (Use Case) на основе двух совершенно разных примеров: бронирование отеля в современном IT‑сервисе и покупка брюк на рынке 90-х.
Рассмотрим, как формируются эффективные сценарии использования от этапа создания Use Case диаграммы с помощью промта до детализации сценария.
Вы ставите таймер на 25 минут, делаете перерыв и уверены, что стали продуктивнее. А что если это не так? Изучаем, что говорят реальные исследования.
«То, как команда играет в целом, определяет её успех. У вас может быть самая лучшая в мире команда звёзд, но если они не будут играть вместе, клуб не будет стоить и гроша».
— Бейб Рут
«Если вы хотите идти быстро — идите в одиночку. Если хотите идти далеко — идите вместе».
— Африканская пословица
«Талант выигрывает игры, но команда выигрывает чемпионаты».
— Майкл Джордан
Командная работа — это тема, про которую вроде бы уже всё сказано. Но если бы это было так, мы бы не сталкивались снова и снова с одними и теми же граблями: перегретые сеньоры, выгоревшие тимлиды, нескончаемые фидбеки «не хватает взаимодействия» и «каждый сам по себе». Так почему же на практике всё ещё сложно осознать, что качество результата — это не про индивидуальный уровень, а про то, как люди вместе работают, слушают, дополняют и усиливают друг друга?
Меня зовут Яна, и у меня за плечами 13+ лет в ИТ, десятки проектов, международные операторы, интеграции, продуктовые команды, устройства, и сейчас — низкоорбитальная спутниковая система для высокоскоростной широкополосной передачи данных (более детально рассказывала о себе в Скрам‑мастер vs мастер реальности). С таким багажом у меня есть чёткое ощущение: где бы ты ни был, без команды ты не создашь ничего действительно крутого. И вот почему.
Привет, читатели Хабра!
Кому из нас не знакома ситуация, когда «горит» вообще всё и сразу? Кажется, что каждая задача кричит: «Сделай меня первой!» И вот тут‑то и возникает ступор: за что хвататься, с чего начать? Методик приоритизации существует великое множество — от простой и понятной матрицы Эйзенхауэра до запутанных фреймворков вроде WSJF. Но как во всем этом разобраться и не утонуть в бесконечных таблицах и формулах?
Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT‑отделом 8. Я работаю в компании Софтонит. В этой статье я постараюсь простым языком рассказать о самых популярных подходах к приоритизации задач. Мы разберем их плюсы и минусы, посмотрим на реальные примеры и, надеюсь, вы найдете тот инструмент, который будет вам полезным и поможет навести порядок в бэклоге, а также сделать процесс приоритизации четким и понятным.
Большой проект. Сложная система. Куча требований. Первое, что приходит в голову любому инженеру: «Надо декомпозировать!» Разложим по модулям, разделим на команды, каждый займется своим куском. Большую сложную задачу превратим в набор простых понятных подзадач. Так учат делать везде. Так делают все. Это основа основ. Но никто не говорит о том, что происходит дальше. Никто не предупреждает о скрытых ловушках, которые ждут на этом пути. А их там... много.
Работа системного аналитика — это постоянный баланс между техникой и бизнесом, между хаосом требований и порядком спецификаций. Аналитик соединяет интересы заказчиков, пользователей, разработчиков и тестировщиков, разбирается в сложных системах и помогает команде двигаться к конечной цели.
Но есть такие незаметные вещи, которые могут сильно всё усложнить. Когнитивные искажения. Они незаметно и постоянно влияют на наши суждения и решения.
В этой статье мы разберем, какие когнитивные искажения могут повлиять на работу системного аналитика, как их распознать и что сделать, чтобы минимизировать их влияние. Реальные примеры и практические советы помогут взглянуть на свою работу по‑новому и укрепить аналитические навыки.
Итак, когнитивные искажения — это не приговор, а вызов, с которым можно справиться. Давайте начнем разбираться!
Многим в детстве было знакомо увлечение компьютерными играми, многие перенесли свои увлечения и во взрослую жизнь, сделав его более осознанным. Фанатом игр (и это я не про казино) я стал лет в 10 и на определенный момент я стал думать, какую пользу я могу вынести в свои текущие проекты, будь то элементы геймификации, удобство пользовательского интерфейса или вопросы командной работы.
Недавно я завершила обучение на курсе от Google по программе Управление проектами Поэтому я решила подготовить цикл из шести статей, в которых постараюсь передать ключевые идеи курса для русскоязычной аудитории.
Курс состоит из шести разделов, и каждая статья будет охватывать один раздел. Вот их список:
Ещё горячо мной любимый Alistair Cockbern в начале 2000х подметил, что наибольшую эффективность даёт команда, физически запертая в одной комнате. Этот факт был неоднократно подтверждён и использован мной во время проблемных проектов, когда за короткий срок нужно было мобилизоваться и сделать большой объём работы или решить серьёзную проблему.
Когда команду технически можно собрать в одном месте, это непременно делали: выбирали город, где в моменте есть наибольшее количество нужных людей, остальным выписывали командировки, собирались в одном офисе, бронировали на неделю нужное помещение, запирались и включали волшебство самой эффективной командной работы. Надо было только не забывать вовремя заказывать пиццу и напитки :).
А если собрать команду в одном месте нельзя или это очень дорого? А если речь идёт не о неделе/двух, а о проекте длиной в полгода-год? А если твоя команда мало того, что распределена географически, так ещё и работает в двух таймзонах, а заказчик — в третьей? Сегодняшняя заметка про управление географически-распределённой командой в разных таймзонах.
Как сделать так, чтобы система KPI действительно работала на бизнес? Этим вопросом задаются все менеджеры, эффективные и действительно эффективные. Меня зовут Алсу Гибадуллина, и уже несколько лет я работаю в Innostage над сложными проектами управления эффективностью в госсекторе. Теперь расскажу, как наши наработки адаптировать под бизнес и работать с KPI не для галочки, а для реальных результатов.
При работе с BIM-моделями в формате IFC важно не только управлять геометрией и структурой здания, но и визуальными аспектами — например, цветами элементов. Цвет в IFC используется для улучшения читаемости моделей, визуализации этапов строительства, указания состояний (демонтаж, новое строительство и т.д.) или просто для улучшения презентации.
В этой статье мы разберём, как с помощью библиотеки IfcOpenShell изменить цвет у конкретной стены в IFC-модели. Вы узнаете:
- как устроено цветовое оформление в структуре IFC,
- как найти нужную геометрию элемента и назначить ей новый цвет.
Каждый день мы тонем в потоке информации: статьи, заметки, идеи, детали проектов, важные задачи — всё перемешано между вкладками браузера, записями в телефоне и разными приложениями. Но когда что-то действительно нужно, найти это бывает непросто. Мы снова тратим время на поиски или начинаем с нуля.
Как навести порядок в этом хаосе? Представьте инструмент, который не просто хранит информацию, а помогает ее систематизировать и быстро извлекать в нужный момент. Причем такой инструмент можно легко адаптировать под себя и он всегда будет под рукой.
Метод «Второй мозг» разработанный Тьяго Форте, представляет собой подход к управлению персональными знаниями, который помогает не только собирать информацию, но и эффективно ее использовать. Особенно интересно, что этот метод можно реализовать с помощью Telegram.
Telegram — это не только мессенджер. Его функциональности достаточно, чтобы превратить этот инструмент в полноценную систему управления знаниями. В статье я расскажу, как настроить «Второй мозг» внутри Telegram, приведу простые примеры и поделюсь практическими советами.
Каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На этом пути будут поджидать множество сложных вопросов, от решения которых зависит успех. Неверные ответы могут значительно усложнить проект, а правильные сделать эту дорогу легкой.
Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).
В качестве сквозного примера, для всего цикла статей, будет идея создать библиотеку электронных книг для обучения и научной работы. Проектируемая программа не только позволит читать книги, но и делать их конспекты, цитируя и добавляя собственные комментарии.
Привет! Меня зовут Дмитрий. Я являюсь руководителем группы в IT‑компании. Если перевести на более доступный язык, то получится так: Team Lead Integration. Компания не самая крупная, но очень международная.
Знаете, я никогда не любил и не понимал такое сочетание англицизмов и русского языка. Особенно, когда в него закладывается некоторая двусмысленность. Особенно, когда используется pro. Потому что в него можно заложить столько details, если вы понимаете, о чём я. Тем не менее, для своих размышлений такой оборот показался мне более, чем уместным, включая его двусмысленность. Возможно, истинной причиной стал тот факт, что этот заголовок придумался одной ночью, прям перед сном, и я очень боялся его забыть и не вспомнить на утро, и поэтому он полюбился. В любом случае, попробую разобраться и раскрыть то, что имею на этот счёт. Pro процессы. Хотя изначальная идея была в противопоставлении: «Процессы или бизнес». Когда одна сторона ставит своё участие и значимость немного выше другой. По принципу «бизнес или процессы — выбирайте». Хотя, на самом деле, а какой ещё должен быть заголовок?
Статья полезна тем, кто работает на стыке тесного взаимодействия того, что часто называют бизнесом, и технических или около‑технических команд, для сотрудников разных уровней (от условных джунов до руководителей отделов (Head of sales и прочее)). Также может быть полезна и интересна тем, кто ощущает лёгкий ветерок хаоса в рабочих процессах. Тут нет глубокой аналитики, цифр на основе графиков, графиков на основе исследований учёных британского университета. Только здравый смысл, мои размышления на основе собственного опыта и некоторые рекомендации, что же с этим делать.
Недавно я завершила обучение на курсе от Google по программе «Продакт-менеджмент». Поэтому я решила подготовить цикл из шести статей, в которых постараюсь передать ключевые идеи курса для русскоязычной аудитории.
Курс состоит из шести разделов, и каждая статья будет охватывать один раздел. Вот их список:
Сегодня слово «аналитик» всё чаще встречается в IT, маркетинге, логистике и даже в образовании. Но кто такой аналитик на самом деле? Давайте разбираться. В этой статье расскажу, кто такой аналитик, какие они бывают и чем именно занимаются.
Рынок найма поменялся. Стало плотнее, агрессивнее и одновременно... гибче. Люди научились продавать себя лучше. А кто-то - слишком хорошо. Так появляются волки.
Кто такие волки? Это кандидаты, которые накручивают себе опыт, приукрашивают скиллы и порой вообще выдают чужие заслуги за свои. Они не обязательно плохие - часто это способ адаптации к суровому рынку. Но если ты ищешь человека под конкретную задачу и вам нужно добрать компетенций со стороны - важно понимать, кого ты на самом деле берёшь.
В этой статье разберём, как отличить реальный опыт от накрученного, какие ловушки могут быть в процессе собеседования и как не запороть найм из-за одной легенды.
