Вы открываете приложение «на минутку», через полчаса понимаете — залипли. Это не магия и не слабая сила воли, это хорошая работа интерфейсов. Они устроены так, чтобы держать внимание и не отпускать.
В прошлой статье я показывал, как главная страница решает судьбу продукта. Теперь — о приёмах, которые работают после неё. Они незаметны, но именно они удерживают нас внутри экрана.
Период 2020–2021 годов характеризовался двумя на первый взгляд разнонаправленными, но синхронными процессами. С одной стороны, Федеральная резервная система США инициировала беспрецедентную по масштабам программу количественного смягчения (QE), что привело к экспоненциальному росту денежной массы и притоку ликвидности на финансовые рынки. С другой стороны, Народный банк Китая и другие регуляторы КНР последовательно ужесточали политику в отношении криптовалют, кульминацией чего стал полный запрет на майнинг и транзакции в 2021 году.
В момент, когда нужно было готовить релиз, мой мозг отказался работать. Я мог час крутить задачи в трекере, сорок минут решать, на какие письма ответить. Даже перед автоматом с едой я стоял по пять минут и уходил голодным.
Мне нужно было срочно придумать, как перезагрузить голову.
Добрый день, уважаемое сообщество Хабра! Я тимлид, и сегодня хочу поделиться с вами опытом поиска работы в 2025 году. Это первый раз в жизни, когда я искал новую должность, уже будучи лидом. В последнее время тема поиска работы всесторонне рассматривается с точки зрения разработчиков. Но как новые предложения ищут лиды?
Предлагаю вам вместе со мной посмотреть на ключевые особенности рынка вакансий лидов в России. Моё мини‑исследование не претендует на объективность: только одно (ладно, два) резюме и только один всем известный сайт поиска работы. Однако можно понять некоторые общие закономерности и обсудить то, как видят нас, лидов, наши потенциальные работодатели. Ну и поделиться друг с другом своими историями в комментариях.
Если вы лид, либо смотрите в эту сторону, а также если вы HR, приглашаю вас дальше.
Привет, Хабр!
Многие команды однажды замечают, что оценочные сессии превращаются в рутину, а прогресс всё не торопится улучшаться. Парадоксально, но именно так родилось движение #NoEstimates — отказ от традиционных оценок времени и переключение на метрики, основанные на реальных данных. Вместо гаданий «сколько времени займёт фича» мы смотрим на поток работы и используем его показатели для планирования.
Концепция #NoEstimates во многом объяснена в публикациях старожилов Agile. Оценки всегда неточны, обычно очень сильно. Единственный случай, когда оценка может сработать — это когда вы строите то же самое снова. Во всём остальном мире — где постоянно что‑то меняется — тратить время на приблизительные расчёты бессмысленно. Гораздо важнее смотреть на реальные показатели команды: скорость выполнения задач, время их прохождения и т. п. Холуб дальше замечает, что планировать «строгие» сроки — это пережиток водопадной модели, а Scrum‑фреймворк даже не требует от команды жёсткого commit«а на объем работ: в Scrum говорят о прогнозах (forecast), а не о фиксированных обязательствах.
Я знал одну компанию, которая занималась продажами В2В и В2С. У них было интересное правило: раз в неделю менеджер имел право послать одного клиента на три буквы, высказать ему матом всё, что захочется, нагрубить в своём стиле и бросить трубку. Директор компании считал это невероятной инновацией и проявлением демократичного стиля управления. Мне эта традиция не нравилась: во-первых, всегда можно расстаться по-человечески, а во-вторых, 7 менеджеров, 50 рабочих недель в год, это 350 посланных клиентов с очень высоким уровнем негатива. Даже если «право» реализуют в 10% случаев, это 35 потенциальных носителей отрицательных отзывов (и это минимальный из рисков).
Но что интересно: во многих компаниях нет таких эпатажных руководителей, но это не отменяет того, что продажники и клиентские менеджеры ненавидят клиентов, игнорируют их, а иногда и просто сливают. Да, клиенты бывают непростыми и некоторые реально заставляют поседеть и охрипнуть, но…стоит ли переживать? Возможно, важно выстроить диалог.
Привет, Хабр!
Использование OSS‑компонентов — стандарт современной разработки. Под OSS‑компонентами мы понимаем ПО с открытым исходным кодом. Это могут быть приложения, библиотеки, набор файлов, или даже просто фрагмент кода.
Но при использовании OSS есть нюанс — лицензии. Одни библиотеки можно брать без оглядки, другие требуют платежей, а третьи — строгого соблюдения условий. И если в бэкенде зачастую все относительно статично (версии меняются редко, компонентов немного), то веб — отдельная история. Тут компоненты множатся с космической скоростью, версии обновляются каждую неделю, и следить за всем этим вручную просто нереально.
В этой статье расскажем о том, как мы формируем реестр OSS‑компонентов и какие инструменты помогают нам быстрее проверять лицензии и формировать единый список компонентов.
Потерянные версии документов, поиски актуальных планов и отчетов, несоответствие статус проекта и реального состояния... Такое знакомо многим и менеджерам проектов, и спонсорам, и командам (которые считают, что проще написать заново). Дело не в плохих людях, а в отсутствии системы, которая учитывает статусы и этапы проектов.
Так как придумывать контент оказалось задачей не простой, а придумывать СТОЯЩИЙ контент почти невыполнимой, а писать тем не менее что-то хочется, то я немного снижу планку своего перфекциониста.
И пока вокруг все разговаривают про гендерное неравенство в разных областях и сферах работ, я бы хотела поисследовать, что делать со сложными проектами, которые идут сразу не туда, куда хочется и не так, как нужно.
В целом, редкие проекты строго двигаются к своим запланированным и четко сформулированным целям, а какой-то хаос в предстоящих итерациях стоит закладывать сразу, смело отводя на него внушительную долю запланированного времени. А еще здорово, когда выстроены процессы ОТ и ДО, но как мы все знаем, суровая реальность далека от идеала. Поэтому аки фокусник тебе так или иначе придется выполнять разные роли и задачи из разных областей рабочих обязанностей. Потому что, если ты архитектор или инженер, то какие-то мелкие договоренности о встречах, адресах или настройках легче проводить самостоятельно и глупо дергать РП (если вообще таковой на проекте имеется) для каждой фиксации мелочи, а с другой стороны где-то надо искать грань, когда количество времени на организаторскую работу превышает мыслимые и немыслимые пределы и вместо архитектурной или инженерной работы (на какую ты собственно и договаривался словами через рот) ты занимаешься какой-то сплошной тратой времени, когда вот эти мелкие задачи занимают настолько много времени, что становятся скорее рутиной, нежели неприятным, но быстрым обязательством, которое ускорит достижение цели, сократит человекочасы, потраченные на проект и в целом поможет сделать все хорошее, против всего плохого.
Я расскажу вам о своем опыте тимлида командой разработки в крупном банке, где старые управленческие привычки иногда брали верх над здравым смыслом. Это субъективная точка зрения на реальную ситуацию, где я — Д«Артаньян, а все остальные — редиски.
OpenAI впервые раскрыла реальную статистику использования ChatGPT: 73% запросов не связаны с работой
Компания OpenAI опубликовала первое масштабное исследование поведения пользователей ChatGPT, проанализировав 1,5 миллиона реальных диалогов за период с мая 2024 по июнь 2025 года. Результаты оказались неожиданными и развенчали многие мифы об использовании ИИ.
Ключевые выводы:
700 млн пользователей в неделю - каждый десятый взрослый житель планеты
73% запросов личные, только 27% связаны с работой (год назад было 50/50)
Женщины обогнали мужчин - 52% vs 48% пользователей
Программирование - всего 4,2% от всех запросов (а не основное применение, как многие думали)
Три главные категории: практические советы (29%), поиск информации (24%), создание текстов (24%)
Неожиданные факты:
→ В развивающихся странах ChatGPT растет в 4 раза быстрее, чем в богатых
→ 10% всех обращений - это обучение и репетиторство
→ Больше половины "письменных" задач - редактирование существующих текстов, а не создание нового контента
Исследование показало, что ChatGPT превратился из нишевого инструмента для программистов в массовый помощник для повседневных задач - от рецептов до домашних заданий.
Однажды я записался на ProductCamp, придумал игру, которая была бы моим вкладом в команду «развлечений», не нашел свободных слотов, не поехал, но идею той игры полюбил и начал развивать.
Эта статья посвящена описанию вариации Spaghetti Challenge (далее Спагетти Челленджа) — игры для вечеринок, корпоративов, тимбилдингов, мастер‑классов по управлению, инженерному мышлению и кооперации.
Описанная версия игры добавляет в классический Спагетти Челлендж новую роль: Продуктологов. Участники в этой роли тренируются преподносить свои идеи и продавать их Строителям, и сразу смотреть: решают ли их продукты проблемы, и какую пользу они приносят.
Говорите по‑русски: не «OPEN» а «ОТКРЫТО». Ваш код — следующий? Всем коммитить по‑русски!
порассуждаем о будущем
Мы решили встроить ИИ в систему управления проектами и посмотреть, что из этого выйдет. Спойлер: получилось лучше, чем мы ожидали.
Сегодня речь пойдёт о том, как превратить приблизительные оценки сроков выполнения задач в надёжные прогнозы, и о том, как рассказывать об этих прогнозах другим.
Оценка сроков выполнения задач — это важное дело. Но, в то же время, подобные оценки доставляют массу неприятных эмоций множеству инженеров и программистов. Оценки сроков являются источником напряжения, которое возникает между командами разработчиков и всеми теми, кто так или иначе с ними взаимодействует. Это — менеджеры, другие отделы компаний, клиенты.
Всё дело в том, что почти все до сих пор неправильно рассказывают другим об этих оценках.
Привет, Хабр!
Сегодня рассмотрим метод, который может стать для вас интересным инсайтом в стратегическом планировании разработки — Wardley Mapping.
Если кратко, Wardley Map — это схема, где мы располагаем все компоненты нашего продукта или системы в двух измерениях: по оси «ценность для пользователя» (вертикаль) и по оси «эволюция/зрелость» (горизонталь).
Зачем вообще нужна дизайн-система? В первую очередь, для стабилизации и ускорения проектирования с разработкой. Затем — для унификации пользовательского опыта. Идея хорошая, однако иногда вместо этого мы просто получаем барьер на каждом шаге. Перекрасить кнопку? Согласование. Новый элемент или паттерн? Дизайн-комитет. А/В-тест? Сначала в ДС.
Команда учится делать не «лучше», а «правильнее». Развитие продукта замирает, потому что «в системе так не принято». Это и есть ДС-тюрьма: удобно сторожам, плохо заключённым.
Эта заметка развернулась из комментария к статье: Таски есть, системы нет.
С моей точки зрения, заглавие разсматриваемой стати верно. Однако в содержании перечислены проблемы-следствия, без разкрытия ключевой затронутой проблемы.
В заметке я постараюсь выйти на эту ключевую проблему и затронуть вопросы вида:
Из чего такая система должна произрастать? Какие к ней требования? Есть ли примеры?
Один и тот же тренинг. Кому-то все понятно и доступно. Кто-то раздражен — материал кажется очевидным и бесполезным. А кто-то полностью потерян — слишком абстрактно, оторвано от практики. Материал один, результаты — разные.
Представьте идеальную IT-команду: блестящие специалисты, амбициозный проект, всё для успеха. Но проходит несколько месяцев, и что-то ломается. В чатах исчезают мемы и жаркие споры об архитектуре, остаются лишь сухие «залил пул-реквест». Разработчик, горевший своим делом, теперь молча соглашается с любым решением. Даже успешный релиз не хочется отмечать — будто это не победа, а просто конец очередного марафона.
Это не просто усталость. Это — тихое выгорание. Не громкий скандал, а методичный отказ системы. Не «я устал», а «мне всё равно». И самое тревожное, что менеджмент часто замечает проблему лишь с заявлением об уходе, когда человек мысленно уже месяц как не с нами.
Правда в том, что люди уходят не только из-за денег. Гораздо чаще — из-за ежедневного обесценивания, абсурдного контроля и ощущения бессмысленности. 58% IT-специалистов готовы на меньшую зарплату, но не готовы мириться с токсичной культурой управления (Harvard Business Review).
Эта статья — для тех, кто чувствует, как команда теряет энергию, но не хочет с этим мириться. Для разработчиков, которые видят, как гаснут их коллеги. Для менеджеров, которые хотят вести команду к целям, не сжигая людей. Мы разберем, какие управленческие ошибки убивают мотивацию, и какие практики помогут вернуть команде огонь, устойчивость и желание делать классные продукты.