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

Всем привет! Меня зовут Юлия, и уже 6 лет я занимаюсь тестированием. За свою карьеру я успела принять участие в разных проектах компаний от стартапов до гигантов индустрии, тестировала бэк, фронт, мобилки, веб и даже устройства интернета вещей, успела дорасти до тимлида и начать осваивать автоматизацию.
В этой статье я поделюсь своим опытом QA-инженера и расскажу о самых распространенных ошибках, которые могут убить ИТ-продукт на корню. Я собрала примеры из реальной жизни, чтобы показать, как даже самые мелкие недочеты могут обернуться огромными проблемами.

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

Гибкость (agility) — это, без сомнения, полезная вещь, и Манифест Agile не выглядит необоснованным. В сравнении с устаревшей практикой, известной как «Waterfall», Agile безусловно имеет свои преимущества. Тем не менее, многие аспекты Agile на практике оказываются весьма вредными, и я не считаю, что дихотомия «Agile/Waterfall» вообще является полезной концепцией.

Существует одна из разновидностей Agile, называемая Scrum, которую я наблюдал на практике, и она реально может привести к гибели компании. Под словом «гибель» я не имею в виду «ухудшение культуры». Я говорю о том, что акции этой компании упали почти на 90 процентов за меньше чем два года.

Страница тарифов может быть самой важной страницей вашего сайта. Здесь клиенты принимают ключевое решение: стоит ли ваш продукт запрашиваемых денег?

Правильно структурированная страница повышает конверсию до 50%, а публикация цен даже для enterprise-решений становится конкурентным преимуществом.

Анализ десятков SaaS-компаний выявил ключевые элементы, превращающие страницу цен в мощный инструмент конверсии.

В статье разбираем современный подход к автоматизации тестирования — от требований до продакшена. Как писать автотесты ещё до выката фичи, запускать их в изоляции, работать в одной ветке с разработчиком и ловить баги раньше, чем они попадут на стенд. Реальные практики, понятные схемы и причины, почему "автоматизация после релиза" — путь в никуда.

Всем привет! Меня зовут Бодров Иннокентий. Я — продакт, аналитик и архитектор с более чем 17-летним опытом в разработке информационных систем, построении успешных продуктов в телеком-индустрии, финтехе, электронном документообороте и корпоративных порталах.

Последние несколько лет я активно продвигаю идеи работы на основе здравого смысла, бережливости и современного, гибкого (в хорошем смысле слова) продуктового подхода. И один из инструментов, который мне помогает в этом — это Domain-Driven Design (DDD).

Многие считают DDD чем-то исключительно для разработчиков. Я же уверен: это прежде всего коллаборативная техника. Она полезна аналитикам, продактам, архитекторам, менеджерам. Но особенно важно, чтобы в DDD погружались те, кто ближе к бизнесу. Потому что именно у них есть шанс выстроить мост между миром предметной области и кодом.

О том, как это сделать — и будет эта статья.

Приходите на бесплатный двухдневный митап 21 и 22 мая в Алматы от спикеров QIC digital hub, Kolesa Group, Yandex и DataArt! Эксперты рынка поделятся своими знаниями и кейсами в работе с продуктами и данными.

Все вокруг повторяют мантры про «не сдаваться», хакатоны и борьбу с техническим долгом. Эти слова звучат правильно — но почему тогда команды, которые им следуют, часто буксуют на месте? Может, дело не в мотивации, а в том, что мы слепо копируем сценарии, которые давно не работают? Пора выйти за рамки привычного.

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами. Публикую перевод интересной статьи для техлидов от технического консультанта Авива Бен-Йосефа, автора книги The Tech Executive Operating System.

«У нас никто никогда не сдаётся!» «Посмотрите, какой хакатон мы провели!» «Мы жёстко закладываем время на борьбу с техдолгом».

На первый взгляд — правильные и вдохновляющие лозунги. Но на деле это просто рекомендации, которым имеет смысл следовать… если вы хотите управлять посредственной командой.

Как технический лидер, вы часто попадаете в ловушку «общепринятых» практик. Но что, если именно эти практики тормозят развитие вашей команды и организации? В этой статье — шесть нестандартных установок. Они могут показаться непопулярными, зато помогут выстроить устойчивую, инновационную и по-настоящему эффективную команду.

No-code платформы – мощный тренд 2025 года, позволяющий создавать приложения и автоматизировать процессы компании с минимальным привлечением программистов. 

Вы когда-нибудь задумывались, какие именно задачи учитываются при расчёте velocity - и как на самом деле работают Velocity и Sprint Reports? Если нет, скорее всего ваши репорты не отражают реальную картину.

Вот 4 распространённых нюанса, которые могут серьёзно исказить ваши Velocity и Sprint Reports - и как моё приложение Multi-team Metrics & Retrospective может во многом автоматически устранить их:

1. Вы удаляете задачи из спринта только если они были действительно деприоритизированы?

Если вы вручную убираете незавершённые задачи из спринта (например, чтобы перенести в бэклог или следующий спринт) до его завершения вместо того, чтобы проследовать по workflow, который запускается после нажатия на кнопку 'Complete sprint', то Jira не посчитает их как "незавершённые" в Sprint Report. В результате ваш velocity окажется искусственно завышен. Удалять следует только те задачи, которые действительно деприоритизированны. Все остальные должны остаться и быть перенесены соответствующим образом.

2. Все ли выполненные задачи действительно входят в спринт?

Метрика Issues completed outside of this sprint в Sprint Report учитывает только те задачи, которые были завершены вне спринта И затем вручную добавлены в него. На практике многие команды закрывают задачи, но забывают их класть в спринт. Если вы проанализируете хотя бы квартал, то скорее всего найдёте несколько задач, которые были решены, но так и не вошли ни в один спринт. В результате Velocity и Sprint Reports не учитывают часть задач.

3. А как насчёт дубликатов?

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

4. Оцениваете ли вы повторно одну и ту же работу?

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

Бонус: Путаница с Added Scope на ретроспективах

Если вы проводите анализ добавленного скоупа работ в активный спринт, то знаете, насколько сложно отличить действительно новую работу от ожидаемых дополнений - например, багов, выявленных при тестировании задач текущего спринта, или тех же дубликатов. В отчёте Sprint Report такие задачи отмечены звёздочкой (*), но отдельной метрики для них нет - приходится вручную анализировать каждую задачу.

Отдавать свои деньги — неприятно. Для этого ощущения есть специальный термин Pain of Payment или стресс расставания с деньгами. 

Исследований на эту тему проводят много: все, кому интересно получать деньги от клиентов, хотят знать, как это сделать наиболее бесшовно. Например, правительства, чтобы сделать для людей оплату налогов менее неприятной.

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

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

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

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

Дисклеймер: Все примеры выдуманы, все совпадения случайны ;-)

За последние 10+ лет я строил продуктовые инженерные практики и культуру как в стартапах, выросших с нуля до 100+ человек, так и в корпорациях с 1000+ штатом. 

Это конспект моего опыта и ответы на четыре вопроса: что делает технический директор, как он выстраивает работу, какие задачи входят в его обязанности и почему техдиры (Chief Technology Officer) различаются.

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

Продакт сегодня – настоящий человек-оркестр из мира IT: он и гипотезы проверит, и бизнес-модель выстроит, и с клиентом общий язык найдет. Понятно, что одной конкретной теоретической базой тут не обойтись: нужны компетенции и знания из разных сфер. И здесь вам помогут книги. Я Катя Ольхова, продакт-менеджер МойОфис Почта и… книжный червь :)

Расскажу про литературу, которая повлияла на развитие моих профессиональных компетенций: впереди и разговоры с мамой, и база по найму «тех самых» спецов, и бизнес-модели, без которых в нашем деле никуда. Одной идеальной книги для продакта нет, поэтому я собрала разноплановую подборку (есть даже одна художественная книга): от основ для новичков до продвинутых техник для тех, кто хочет прокачать конкретные навыки. Итак…

Что бы мне почитать, если:

Я продакт на старте карьеры и боюсь, что сил, времени или терпения хватит всего на одну книгу из списка

Нужно детально разобраться, какая бизнес-модель у твоей компании, разрушить ее и построить заново

Хочу понять, как создать продукт, который формирует привычку

Учусь проводить с клиентом качественные интервью: не просто продавать идею, а слышать и понимать потребности собеседника

Необходимо научиться управлять проектами в сжатых сроках

Учусь всегда нанимать нужного человека на горящую позицию

Часто попадаю в конфликтные ситуации на работе и хочу лучше их прорабатывать

Ты что-то ждёшь от коллег из другого подразделение / продукта. Попросил раз. Попросил два. Написал в чат — тишина. Напомнил ещё раз — снова молчание. Знакомо? Что делать дальше? Самый очевидный путь - эскалация. Но точно ли он лучший?

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

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

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

Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.

Под катом: Youtube, Glovo, Intsagram, Tiny Glade.

Нашел для изучения новые мега-листинги опенсорсных проектов, комиксы и книги по теме открытых разработок. Сегодня хотел бы поговорить о управленческом фреймворке, который разработали и передали в open source специалисты Red Hat.

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

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

На встречах они не обсуждали функциональность продукта, а говорили о «пользовательских историях» – маленьких повествованиях, описывающих фичи. Каждой такой истории присваивались «story points» — условные единицы, оценивающие объём усилий, необходимых для выполнения задачи. Каждое утро они проводили «стендапы» – короткие собрания, на которых все стоят. В центре их офиса стояла доска, на которую они клеили стикеры и передвигали их по колонкам в зависимости от статуса задачи. Они работали «спринтами» – двухнедельными циклами, посвящёнными определённым задачам.

На общих совещаниях менеджер команды показывал прогресс с помощью специального ПО с дашбордом, отображающим статус всех проектов. Он также мог показать график «velocity» — скорости выполнения задач, с историей изменений и прогнозами.

Так я и узнала, что такое Agile — метод управления разработкой, который получил колоссальную популярность в технической среде и, всё чаще, за её пределами (один TED-спикер даже рассказывал, как внедрил Agile дома, в семье).

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

Привет, Хабр! Меня зовут Иван, и я проджект-менеджер (или PM) в продуктовой разработке. Кто не знает, проджект занимается…чем только не занимается: мы одновременно держим под контролем работу команд и общаемся с десятками людей, успеваем делать ещё и свои задачи. Выглядит как хаос, но я знаю как им управлять.

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