Что такое JTBD
Jobs To Be Done, «Работы‑Которые‑Надо‑Сделать» — это маркетинговая теория о том, почему люди принимают те или иные решения о покупке. Эта теория помогает предпринимателям, компаниям, менеджерам и теоретикам лучше понимать потребности людей и создавать действительно нужные этим самым людям продукты...
Привет! Меня зовут Елена Тупикова, я академический руководитель программы онлайн-магистратуры от Яндекса и МФТИ «Управление IT-продуктами». В этой статье я расскажу о сфере управления IT-продуктами: о трендах, актуальных профессиях и навыках.
Работа маленького колл-центра — это всегда баланс между многозадачностью и эффективностью. У нас всего три человека: два оператора и руководитель. Каждый сотрудник тут является неотъемлемой частью команды, а изменения внедрять проще и быстрее, чем в крупных подразделениях.
В статье делимся нашим реальным опытом: как именно мы выстраивали мотивационную систему, какие решения оказались удачными, а что пришлось доработать с учетом специфики маленького коллектива.
В какой-то момент я смог отчётливо различить одну важную особенность человеческой личности, оказывающую существенное влияние на результативность работы. К сожалению, в медицине этим же словом обозначается диагноз, название которого — тревожность. Сложно определить, что случается раньше: работа или тревожное состояние, особенно в сфере IT, но находящиеся в тревожном состоянии сотрудники часто имеют склонность работать усерднее, нежели полностью спокойные или безразличные.
Захотелось найти научное подтверждение гипотезе, понять её ограничения и способы работы с ней.
В прошлой своей статье “Сказ о том, как три разработчика сделали работу за шестерых и в два раза быстрее” я упомянул о положительных результатах, достигнутых с помощью системы приоритезации. Здесь же разберу подробнее этот вопрос.
FFF — методология, которая держит сроки и бюджет, даже когда всё идёт не по плану. Гибкий подход без сказок о всегда стабильной разработке. В статье – о том, почему, как и когда этот подход может сработать.
или разбор карты от Авито с точки зрения бизнеса, DORA и инженерной практики
Если ты релизнул фичу на 500K₽/мес выручки, но получил «3» за ретро и фассилитацию — это не шутка, это реальность многих крупных команд.
Сегодня хочу поговорить про систему оценки разработчиков. Не формально, а по существу. Разберём публичную карту Авито — без токсичности, но критически. И покажу, как строить модель, которая работает.
Приветствую уважаемых хабралюдей!
Меня зовут Игорь Холопов, я – директор по маркетингу компании Systeme Electric. Некоторые из вас давно и хорошо знают – чем мы занимаемся с 2022 года и какую продукцию предлагаем. Однако, уверен, многие до сих пор не знают. И даже не догадываются. И, например, скорбят об отсутствии на российском рынке легендарных бесперебойников APC. Дам спойлер: на самом деле с этими ИБП в РФ все в полном порядке.
Я решил завести блог на Хабре по нескольким причинам. С одной стороны, чтобы информировать о деятельности Systeme Electric тех, кто уже в теме, и знают о нас. Право дело: на каком еще ресурсе информировать знающих людей, если не здесь? С другой стороны, блог заведен с целью разъяснить ситуацию тем, кто не в курсе существования Systeme Electric, перевести их в первую категорию и… опять же, информировать о нашей деятельности, продуктах, проектах и так далее 😊
Первый пост в блоге – т. е. тот, который вы сейчас читаете – будет посвящен именно тому, что такое сегодня Systeme Electric, откуда мы взялись и какую продукцию предлагаем.
Все годы существования YouGile на вопрос «нужно ли делать CRM?» мы отвечали однозначно: конечно, нет! Это погубило десятки таск-трекеров, превратив их в перегруженных монстров. И вот мы подумали и решили делать… собственную CRM. Рассказываем, почему мы считаем, что рынку нужна простая CRM, и показываем первые прототипы.
В статье о том, как я впала в ступор, когда моя команда из 10+ человек начала активно сопротивляться новому инструменту с фидбеком, и как я внедряла культуру обратной связи. Попробую разобрать, что пошло не так, и какие уроки я из этого вынесла.
Привет. Меня зовут Карина, я PM сервиса «Майснаб». Мне всегда казалось, что корректно сформулированный фидбек о работе — то, чего хотят все. Он как навигатор в Google Maps: не просто говорит, что ты не там, а показывает, где свернуть, чтобы прийти куда нужно.
Эффективное управление ИТ-командой на примере взаимодействия популярных дирижеров и их оркестров. От Герберта фон Караяна до Леонарда Бернстайна: как принципы дирижирования помогут вам руководить ИТ-командой.
За последние годы машинный перевод сделал серьёзный шаг вперёд. Если раньше он использовался в основном туристами, пытающимися объясниться с местными за границей, то сегодня его активно применяют в бизнесе. Особенно востребован он при переводе технической документации: благодаря объемам, прямому стилю и предсказуемой структуре, машинный перевод обеспечивает хорошее качество и позволяет существенно экономить ресурсы и поддерживать стабильное качество.
Но можно ли использовать машинный перевод в интерфейсе — самой чувствительной части продукта для пользователя?
Я управляю локализацией цифровых продуктов с акцентом на масштабирование процессов, их интеграцию в продуктовые циклы и соответствие бизнес-целям. Один из ключевых векторов моей работы — внедрение решений, ускоряющих выход продукта на международные рынки, включая стратегическое использование машинного перевода. В этой статье, опираясь на реальный кейс из своей практики, я расскажу, как выявить типичные ошибки нейронного машинного перевода в интерфейсах и понять, насколько такой подход подходит для вашего продукта. Это поможет принять взвешенное решение: можно ли использовать машинный перевод интерфейса вашего продукта без ущерба для качества локализации и пользовательского опыта.
Всем привет! Меня зовут Александр Бондаренко, работаю CPO в Garage Eight. Это следующая статья из цикла про то, как строить продукт. Как и другие современные компании, мы постоянно ищем способы улучшить свои продукты. Но бесконечные улучшения могут навредить. Почему? И где та точка, в которой нужно остановиться? Разбираю в статье.
— Победа любит подготовку, так говорят.
Одна компания решила пренебречь этим золотым стандартом. Внедрила в свою программу лояльности кэш-бэк. Люди покупают – копят баллы. Их можно будет потратить при следующей покупке.
Пару лет все шло неплохо. Пока аналитики не начали замечать – покупки с бонусными баллами натурально сжирают пол маржи. В реальных деньгах – 15-20 млн каждый месяц.
Из этих же баллов на заднем дворе “склада аналитики и данных” началась вырисовываться натурально горы “токсичных отходов”. Кэш-бэка у пользователей за пару лет накопилось примерно на 500 млн. рублей.
— Это что, все отдать надо? — Возник в головах молчаливый вопрос. А за ним последовали мысли о скорейшем увольнении. Слинять, пока никто ничего не заметил…
Начали чесать затылок. Цугцванг никак не решался:
Цель этой статьи — показать, в каких случаях Agile не принесет ожидаемого эффекта, рассмотреть наиболее распространенные случаи его некорректного применения и обозначить ключевые моменты, на которые важно обратить внимание перед началом Agile-трансформации.
Немного фантазии: вы садитесь к компьютеру, бросаете в окно IDE обычную фразу — «собери бэкенд-черновик на Postgres, REST и авторизацию по JWT» — и видите, как через минуту нейросеть выкладывает готовый репозиторий. Руки почти не касаются клавиатуры. Кажется магией, но работает уже сегодня. Карпаты назвал этот трюк «vibe-coding», а я — удобной эволюцией мышления: мы перестаём быть набором пальцев и становимся постановщиками задач.
Подобный сдвиг человечество переживало и раньше. Генри Форд однажды переставил людей вдоль движущейся ленты, и время сборки «Т-мобиля» рухнуло в восемь раз. Тогда станок взял на себя физическую рутину, теперь языковая модель забирает рутину интеллектуальную. Инженер больше не крутит гайки кода, а думает о траектории всего продукта.
ТРИЗ давно мечтала о таком эффекте и называла его «идеальным конечным результатом»: система сама выполняет функцию, человек лишь задаёт направление. Алгоритм-ассистент делает это буквально — перебирает решения быстрее, чем мы успеем сварить кофе, а нам остаётся выбирать лучшие.
Когда ручной труд тает, становится важным, на что тратится освобождённое время. Почти век назад Джон Мейнард Кейнс предсказывал: избыток богатства превратит работу в редкую практику, а люди «оценят лилии полевые, что не трудятся, не прядут». Кода действительно меньше, но вопросов «зачем»-и-«для кого» становится больше. Мы вытаскиваем из стека не очередной баг, а этику, мотивацию, дизайн опыта.
Здесь вмешивается стоическая дихотомия: контролируй своё суждение, оставь в покое то, что от тебя не зависит. Нейросеть может промахнуться, выдать мимо, упрямо не понимать промпт. Кричать на неё бесполезно. Проще переформулировать вопрос и спокойно протестировать ответ. Три-четыре итерации — и багов как не бывало. Спокойствие экономит часы и нервы.
ИИ обучается на существующих данных, как джуниор-разработчик на Stack Overflow, и становится похож на мидла. Но сможет ли он когда-нибудь дорасти до сеньора?
Заголовки вроде «Программисты будут не нужны через пять лет» появляются всё чаще, а модели, такие как ChatGPT и GitHub Copilot, демонстрируют впечатляющие способности в написании кода, однако мы считаем, что никаких серьезных изменений в IT-сфере в ближайшие годы не случится. В этой статье мы предлагаем к обсуждению свои аргументы для такого непопулярного мнения.
Сегодняшняя ситуация вокруг спецоперации в Украине и последовавшие рестрикции со стороны европейских стран и США обнажили и без того известные проблемы импортозамещения западной продукции. Не исключением в этом вопросе стало программное обеспечение (далее – ПО), о старте импортозамещения которого заговорили еще в 2016 года. По изначальному плану замещение программного обеспечения должно было завершиться в 2024 году. Однако, не смотря на столь амбициозный план, ощутимых результатов это не дало как несколько лет назад, так и сейчас. Да, конечно, на протяжение всего этого времени публиковалось множество материалов на тему успешного замещения части западного ПО отечественным, однако это была лишь каплей в море ИТ-решений и технологий.
Последовавший в начале 2022 года уход из России практически всех известных вендоров от Microsoft, до SAP и Oracle, показал нашу сильную зависимость от прививаемого годами зарубежного ИТ-сервиса. По существу, начало полноценного замещения зарубежного ПО началось именно с этого момента, когда российские компании поставили перед фактом остановки поддержки, продления лицензий и работы самого ИТ-решения. Большинство ИТ-менеджером и директоров судорожно стало думать о переходе на российские аналоги, в частности на продукты 1С, как базового корпоративного решения. Однако, использование нового ПО на предприятии возможно лишь после его имплементирования, процесс которого оказался также сильно завязан на страны запада.
В это статье мы рассмотрим вопрос импортозамещения приложений класса ERP и ERP2, принимая во внимание тот факт, что это далеко не единственный компонент корпоративной информационной системы (далее – КИС). Для целей удобства повествования термины программное обеспечение, информационные и корпоративные системы, а также ERP-системы для нас будут тождественны. В работах [1-2] выделяют четыре основных уровня задач для внедрения КИС, к которым относят процессы, данные, приложения и технику, а также два вспомогательных: управление проектном и изменениями. Собственно говоря, процесс внедрения и импортозамещения ERP-систем мы будем рассматривать сквозь указанные 6-ть параметров.
Давайте разберемся, как договариваться так, чтобы и отношения сохранить, и результат получить. Казалось бы, быть мягким и уступчивым — это круто и правда ценится, но иногда это приводит к тому, что реальные проблемы замалчиваются и только усугубляются. Важно найти баланс: не давить, но и не прогибаться.
Одна из ключевых задач проектного менеджера — быть готовым к появлению новой информации, новых вводных и изменяющихся условий реализации проекта, и спокойно отрабатывать каждое такое изменение по мере его поступления.
К сожалению, иногда возникают ситуации, когда новые вводные не позволяют реализовать проект. Это особенно тяжело на масштабных инициативах, потому что хороший проектный менеджер ощущает личную ответственность за результат. В таких случаях страдает не только проект, но и сам менеджер, что может привести к выгоранию.