Сфера дизайна выглядит привлекательно: курсы обещают лёгкий старт в IT, «золотые горы» и работу мечты, а сами задачи кажутся лайтовыми. Я осваиваю эту профессию уже второй год. В статье — мои неочевидные и, возможно, неудобные мысли о текущем состоянии рынка как в найме, так и на фрилансе. Спойлер: на мой взгляд, дело не только в работодателях.
«Наташа, мы всё уронили», — таких историй за мой восьмилетний рабочий стаж в продакт-менеджменте хватит с лихвой. Особенно когда ты имеешь дело не просто с понятным продуктом для конечного потребителя, а со сложным софтом, где даже секундное падение серверов или спорное цветовое решение админской стойки может привести к факапу.
Поэтому, когда я перешла в ISPsystem из ИТ-аудита в банке, мне казалось, что я сменила не только работу, но и Вселенную. Вместо проверок — мегаответственность за развитие продукта, вместо готовых регламентов — постоянные эксперименты. Часто — весьма рискованные.
Сейчас, как директор по продуктам, я понимаю: этот путь был не про везение, а про осознанные шаги, ошибки и умение учиться на них.
В этой статье — мой путь до СРО: практический опыт для тех, кто хочет вырасти, но не знает, с чего начать.
Всем привет! С вами Леша Жиряков, и сегодня я затрону тему планирования и Agile. Недавно кластер/трайб/холдинг, в котором я работаю, проходил трансформацию методов работы, все началось с идеи: а давайте сделаем продукт более открытым. С одной стороны, бизнес требует предсказуемости и возможности строить долгосрочные стратегии, с другой — рыночная турбулентность и подводные камни в IT диктуют необходимость быстрой адаптации к меняющимся условиям.
Это противоречие особенно остро проявляется при столкновении традиционного многолетнего планирования с гибкими Agile-методологиями, призывающими «реагировать на изменения важнее, чем следовать плану». Открытость, гибкость, скорость, эффективность, надежность — вот критерии успешного продукта. Но, развивая надежность, сложно оставаться гибким, повышая эффективность, рискуешь потерять в скорости, а стремление к открытости может снижать безопасность.
Классическое долгосрочное планирование на год и более даёт стратегическую перспективу, но часто оторвано от реальности быстро меняющегося рынка и технологий. Двухнедельные спринты позволяют гибко адаптироваться к изменениям, но затрудняют видение большой картины и координацию масштабных инициатив. Где же золотая середина?
Квартальное планирование становится компромиссным решением, позволяющим синхронизировать циклы бизнеса с работой IT-команд. Квартал как временной интервал достаточно короток для маневренности, но при этом дает необходимую устойчивость для реализации значимых инициатив. В умелых руках оно способствует Agile-трансформации, усиливает прозрачность и повышает эффективность команд. При неправильном внедрении может превратиться в бюрократический ритуал, возвращающий организацию к каскадным методологиям под видом прогрессивного подхода.
Как устроена наша система на практике: от первого звонка и сметы до актов, допников и еженедельных отчётов. Подойдёт студиям, разработчикам и продактам
Проведя множество собеседований на позицию продакт-менеджера и ежедневно общаясь с большим количеством продактов, я понял, что у большинства моих коллег сейчас в голове полная каша и неразбериха. Со всех сторон сыплются новомодные словечки, пестрятся фреймворки, все используют agile и делат growth hacking, даже не понимая, что это такое, как это варить и есть ли это у них на самом деле.
В этой статье я попробовал проанализировать инструменты, которые используют продакт-менеджеры, разобрать, что они из себя представляют, а также ответить на ключевые вопросы: Что это? Для чего это нужно? Когда это применять?
Диаграмма потоков данных (DFD) — схема, которая показывает, где информация застревает, дублируется или исчезает в никуда. Со стороны такая схема может казаться архаикой — зачем рисовать стрелочки, если можно сразу писать код? Ответ прост: исправлять проблемы в уже написанном коде дороже, чем на этапе проектирования.
В статье собрали основу про DFD для тех, кто с ней не сталкивался: зачем ее используют и как изображают.
Привет! Меня зовут Александр Бондаренко, работаю CPO в Garage Eight. Это третья часть статьи про улучшения и инновации (часть 1 и часть 2). В ней расскажу, что выбрать для своего продукта — обновления, прорывы или ничего. И еще подарю чек-лист для продакт-менеджеров.
Когда ошибка не баг, а фича, 4 международных кейса. Часто именно ошибка даёт возможность развития бизнеса и технологий. Отказ от анализа и изумления опыта из ошибок, приводит к станции.
Всем привет! Меня зовут Ира Лисицына, мы с командой делаем сайт ВкусВилла удобным понятным и не останавливаемся в попытках достичь совершенного пользовательского пути через постоянные тесты и работу с обратной связью.
Любое изменение начинается с идеи. Можно ждать озарения, а можно подстроить его под себя, сделать так, чтобы гениальные мысли сами приходили в нужное время. Когда наша команда пришла к тому, что нам необходимо самим управлять своими озарениями и находить новые идеи как по расписанию — появилась встреча по генерациям гипотез. В чем польза таких брейншторм и как довести идеи до прода – расскажу тут на реальных кейсах.
— Привет! Подскажи, пожалуйста, какой срок по этой задаче?
— 2 дня и 1000 долларов
— А почему тысяча долларов? Мы же договаривались на 500?
— Когда мы договаривались, ты не спрашивал сроки
Почему бюджет на разработку вырос в два раза, или как создать идеальную продуктовую команду.
В процессе создания программного обеспечения участвует множество ролей, каждая из которых имеет свою систему ценностей, приоритетов и целей. Эти различия часто приводят к противоречиям в требованиях. Для структурированного анализа таких конфликтов используется модель «Гексапараллакс», которая рассматривает шесть ключевых точек зрения:
AI может помочь снизить затраты, ускорить процессы или увеличить выручку. Однако, чтобы экономика проекта сходилась, нужно не только уметь качественно оценивать потенциальный эффект, но и уметь контролировать затраты.
Цель статьи — показать, как минимизировать расходы на AI-проект.
Дисклеймер: Рынок GenAI очень динамичен, и цены могут быстро меняться. Цены актуальны на момент написания (середина 2025 года) и могут измениться.
Давайте честно: менеджер по большей части работает ртом. Договаривается, придумывает решения, продаёт эти решения окружающим, обосновывает, пинает, пинает, эскалирует, просит… Короче, говорить и объяснять ему приходится примерно все время. И умение четко и ясно доносить свои мысли в правильном ключе для менеджера – критично.
Как говорить так, чтобы от вас не отворачивались через 2 минуты с зевком? Как быстро объяснять занятым людям, в чем смысл вашего вопроса и чего вы хотите? Как сделать так, чтобы ваши вопросы решались руководителями за 2 минуты, вместо недель ожидания аудиенции? Ну и вообще: как перестать быть душным и негативным и стать быстрым и позитивным всего за пару приемов (не таких уж и простых, но все же)?
Вот об этом коротенько давайте поговорим в этой статье.
Эта статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, особенно в том, чему никто толком не учит – сфотскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи на Хабре про управление.
Статья для тех, кто хочет выжать максимум из 1С с ограниченным бюджетом.
Вводная часть
«Как можно автоматизировать продажи, не вкладывая сотни тысяч рублей? У нас маленький штат и нет своей ИТ-команды».
Привет, Хабр. С вами Катя, я аккаунт-менеджер в KISLOROD. Это почти как сапер, только вместо мин — дедлайны, баги и молчаливые клиенты.
Сегодня расскажу, как один вопрос и три уровня менеджмента спасают отношения с клиентами. За год мы увеличили NPS с 47% до 57%. Это означает, что клиенты чаще готовы рекомендовать нас — не из вежливости, а благодаря реальным улучшениям в управлении проектами, коммуникации и сервисе. Рассказываю, как это сделать.
Еще пару лет назад я считал себя «классическим» продуктом. Знал пользователей, гонял дизайнеров, выкапывал инсайты, пинал разработку — все как учили. Но в последнее время начал замечать странную штуку: лента вакансий как будто перекроили. Вместо привычного Product Manager всё чаще вижу TPM. Technical Product Manager. Technical Program Manager. Technical ещё что‑то. Причём зарплаты те же или выше. А требования — местами совсем другие.
Сначала я это игнорировал. Ну подумаешь, слово «technical» прицепили. Потом — напрягся. Потому что под капотом оказалось: от тебя ждут не просто roadmap на квартал и пару фичей в прод, а полного погружения в архитектуру, понимания API, базы данных, CI/CD, пайплайнов, очередей, да ещё и умения всё это дело засинкать между 3 командами параллельно.
В какой‑то момент я начал задаваться вопросом: а я вообще кто?
Пользователь Reddit опубликовал в r/rustjerk сгенерированный ИИ пост под названием «Почему наш CTO запретил использовать Rust после одного переписывания кода». Очевидно, что этот рассказ выдуман, но у меня есть история похожая на него в том смысле, что успех проекта на Rust привёл к прекращению использования этого языка в компании.
Несколько лет назад я работал в стартапе-«единороге», во время пандемии развивавшемся невероятно быстро. Его основное приложение было написано на Ruby on Rails, а часть инструментария для работы с видео — на Node.js, но мы никак не применяли быстрые компилируемые языки наподобие Rust и Go. Через пару месяцев после моего прихода в компанию нам нужно было реализовать работающий в реальном времени сервис, который бы позволял нам получать информацию о том, кто из пользователей находится онлайн (то есть в профиле есть зелёная точка) и чем они занимаются (например: N пользователей смотрят презентацию X, M пользователей находятся в разделе маркетинга и так далее). Ничего особо сложного, но мы рассчитывали на изначальный рост до ста тысяч пользователей. Эта цель тоже не особо сложна, но большинство разработчиков согласилось, что Ruby — не лучший выбор для этого.
Когда компания только начинает свой рост, информационная безопасность почти неизбежно воспринимается как палки в колеса. Формальные согласования, запреты, новые правила — все это кажется лишним грузом. Но рано или поздно наступает момент, когда становится все сложнее стабильно и предсказуемо развиваться без системного подхода к ИБ.
Матвей Григорьев, руководитель направления ИБ в Dodo Engineering, заглянул к нам в подкаст «Все по ИБ» и поделился опытом построения ИБ-службы с нуля в компании, которая растет как на дрожжах. Он объяснил, как превратить безопасность из назойливого «контроллера с линейкой» в настоящего партнера бизнеса — и рассказал, как в Dodo внедряли подход Zero Trust. Мы собрали главные тезисы в этом конспекте — дальше слово Матвею.
Некоторое время назад у нас появилась новая должность — маркетолог‑скаутер. Это специалист, который профессионально занимается поиском и отбором новых идей и проектов на ранних стадиях.
Скаутинг — это эффективный инструмент для нахождения на рынке новых идей, которые будут потенциально прибыльными. Для стартап‑студии идеи и партнёрства‑ это главное «топливо».
Скаут отсматривает тематические сайты в Интернете, паблики акселераторов, чаты, где общаются авторы новых проектов. Его задача не просто «увидеть» идею, а сразу пропустить ее через фильтр:
📌во‑первых, собственную насмотренность,
📌во‑вторых — соответствие трендам, актуальность задумки, технологию реализации, прикинуть объем рынка.
Иногда уже на этом этапе понятно, есть ли у идеи потенциал стать продуктом или она останется на уровне «сырой» задумки. С авторами наиболее перспективных идей нужно установить контакт и поддерживать его.
Рынок автоматизации процессов сейчас переживает качественное обновление — компании самых разных масштабов стремятся минимизировать ручную работу, ускорить процессы, снизить число ошибок в цепочках передачи данных между системами и повысить управляемость бизнес-процессов в целом…
И именно на стыке этих задач возник интерес к универсальным low-code решениям, которые позволяли бы настаивать автоматизированные потоки данных быстро, а главное — без обязательного привлечения разработчика к каждой задаче. Одним из наиболее ярких представителей этого класса инструментов стал n8n — гибкая платформа для интеграции и автоматизации, получившая признание как среди энтузиастов и стартапов, так и в крупных предприятиях.
Впрочем, обо всем по порядку.
