Рубрика «Управление продуктом» - 20

Дисклеймер

Это список не конечен и не претендует на истину в последней инстанции — я структурировал свой опыт публичных выступлений и выбрал самые универсальные советы, выполнение которых позволит почти гарантированно сделать выступление как минимум неплохим.

1. Структура доклада

Парадоксально, но многие докладчики даже на крутых конференциях зачастую не делят своё выступление на три основные части – формулировка проблемы, предпринятые шаги, выводы. Структура может быть сложнее, но базовая она почти всегда такая, даже если вывод – «у нас ничего не получилось».

Ключевая проблема для слушателя – отсутствие вводной части. Выводы он может сделать и сам, а вот стартовать с опозданием сложно и неприятно. Он ещё не понял, что вы будете про пищеварение, а уже нужно вникать в строение эпителия тонкого кишечника. Результат – ваш доклад попадает в слушателя не на все 100%, а имеет шансы и вовсе пролететь мимо.
Читать полностью »

Привет!

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

22 ноября, Москва — AnalyzeIT MeetUp №3 - 1

Кратко:

  • Про нашу Школу системного анализа.
  • Ликбез по профессии аналитика.
  • Confluence — упорядочиваем документы.
  • Измеряем soft skills идеального кандидата на собеседовании.

А теперь подробнее.
Читать полностью »

Разработка электроники. Аудит проекта в примерах. Спасаем тёплые полы всем хабром - 1

Лирическое отступление

По моему мнению, в сегодняшней России наибольшие шансы на успех в области технологических стартапов имеют два типа проектов:

  • узконишевые в области промышленной автоматизации, основанные командой профессионалов в данной области и подкреплённые стартовым финансированием по крайней мере в 20 — 50 000 USD
  • создание прототипов устройств, ориентированных на глобальные рынки

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

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

Давно хотел провести детальный анализ какого-либо проекта по разработке электроники, показать явные ошибки и правильные подходы, которые помогут их исключить. Возможно, ещё долго бы собирался, но подвернулся случай — пост в блогосфере Habra “Становление термостата. Как это получилось”. Статья вызвала бурю в комментариях в том числе и с моей стороны, значит тема актуальна. Какой смысл рассказывать о провалившихся и канувших в Лету проектах, где уже ничего нельзя исправить, не лучше ли попытаться сделать доброе дело?

Попробуем провести аудит проекта с учётом самых ценных комментариев и будем надеяться, что команда извлечёт из него что-то полезное. Возьмём за минимально жизнеспособную версию (MVP) информацию, которую авторы раскрыли в своей статье и подумаем, каким образом можно его улучшить в ходе следующей итерации.
Читать полностью »

— Привет, Саша. Расскажи, пожалуйста, как долго ты работаешь в Wrike, и чем ты занимался до прихода в компанию?

— Привет. В Wrike работаю шесть лет. До этого работал в другой организации и занимался там сначала search engine optimization и потом перешел в проджект-менеджеры. Затем в какой-то момент захотел окунуться в UX. Поработал еще в двух местах UX-дизайнером, а уже после этого устроился в Wrike.

— А насколько твой опыт c UX пересекался с тем, чем ты занимаешься сейчас?

— Это была абсолютно другая история. В прошлом я работал в основном либо над какими-то очень небольшими проектами «под ключ», либо над вещами, связанными не с продуктом, как таковым. К примеру, я работал в «Деловых Линиях». Очевидно что, основа продукта там – это доставка грузов. Мы там просто делали интерфейс для того, чтобы это было удобно.
Wrike – это совсем другая история, это компания с digital-продуктом в центре. К тому же в Wrike я устроился мобильным UX-дизайнером, и для меня это была абсолютно новая область. До этого я всерьез не занимался мобильными приложениями.

Почему я перешел из UX в PM'а и потом в Lead PM'а и что изменилось? - 1Читать полностью »

Встреча Email Public Talk #3: «Идеальная сегментация и Customer Journey Map», 14 ноября - 1

Друзья, приглашаем всех желающих 14 ноября на встречу свободного формата клуба Email-маркетологов. В этот раз мы поговорим об идеальной сегментации и Customer Journey Map.

Разберем специфические случаи из практики наших участников в рамках тех проектов, с которыми они работали и работают. Узнаем, какими способами сегментации они пользуются, какие проводили эксперименты, какие модели оказались рабочими и чем руководствоваться при выборе лучшей методики построения матрицы сегментов.
Читать полностью »

Всем привет! Несколько месяцев назад мы запустили в продакшн наш новый open-source проект — Grafana-плагин для мониторинга kubernetes, который назвали DevOpsProdigy KubeGraf. Исходный код плагина доступен в публичном репозитории на GitHub. А в этой статье мы хотим поделиться с вами историей о том, как мы создавали плагин, какие инструменты использовали и с какими подводными камнями столкнулись в процессе разработки. Погнали!
Читать полностью »

Disclaimer. Костис Капелонис — Developer advocate (человек, защищающий и отстаивающий принципы программной разработки) Codefresh, первой платформы CI/CD для Kubernetes и контейнеров. Миссия Codefresh «Автоматизировать и упрости всё, от кода до облака». Как инженер-программист, Костис имеет многолетний опыт контейнеризации приложений, построения конвейеров CI/CD и разработки приложений Java. Он живет в Греции и любит кататься на роликах.

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

Существует много информации о непрерывной интеграции (CI) и непрерывной доставке (CD). Публикации в блогах с помощью технических терминов пытаются объяснить, что означают методологии CI/CD, что они делают и как они могут помочь вашей компании. К сожалению, часто обе эти методологии связывают с конкретными инструментами или даже поставщиками ПО. Типичный разговор на эту тему в компании звучит так:

— Вы используете непрерывную интеграцию в вашей команде?
— Да, конечно, мы используем инструмент X!

Позвольте мне раскрыть вам маленький секрет. Непрерывная интеграция и доставка – это два подхода к разработке кода, которые совершенно не связаны с конкретным инструментом или поставщиком. Несмотря на то, что существуют инструменты и решения, которые могут помочь вам в обеих случаях (например, Codefresh), в действительности компания может практиковать CI / CD, используя только сценарии bash и однострочники Perl. Ээто не очень практично, но, безусловно, вполне возможно.

Поэтому, вместо того, чтобы попадать в общую ловушку объяснения сути CI/CD с помощью инструментов и технических терминов, мы объясним, что представляют собой эти методологии, опираясь на самый важный фактор процесса разработки – людей!Читать полностью »

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

Руководителю важно, чтобы в отделе всё крутилось, вертелось, стабильно выдавало результат. А ещё KPI постоянно висят домокловым мечом. Потому поиск новых технологий и курсов уходит на 5-10 место.

Почему мы часто ждём, что путёвку на обучение нам предложат HR или руководитель? Стив Джобс говорил: «Ваше время ограничено. Поэтому не тратьте его на то, чтобы прожить чью-то чужую жизнь. Не попадайте в ловушку догмы, которая учит жить в соответствии с мыслями других людей».

Кубернетес меняет жизнь компании. Это факт.

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

Слёрмовая осень, слёрмовая зима… - 1

Нам стало интересно, как изменилась профессиональная и личная жизнь ребят, которые прошли базовые Слёрмы. Чтобы обосновать потраченное время, мы предложили скидку на Слёрм Мега — и попросили участников дать ответы на несколько коротких вопросов: что им понравилось в Слёрме, что не понравилось, что бы они хотели улучшить.

Читать полностью »

Иван Круглов, Principal Developer в Booking.com, выступал на Слёрм DevOps c темой SRE, а после выступления согласился за чашкой кофе поговорить о Kubernetes, Service Mesh, open source и «нестандартных» решениях в Booking.com

Так как тема SRE оказалась намного обширнее, то Иван и его коллега Бен Тайлер, Principal Developer в Booking.com, согласились стать спикерами Слёрм SRE, который пройдёт 3—5 февраля 2020. Там будут рассмотрена теория и практика применения SLI/SLO/error budget, проведение разбора полетов (post-mortem), эффективная ликвидации IT-инцидентов, построение надежных систем (мониторинг и алертинг, graceful degradation, failure-injection, capacity planning, предотвращение cascading failures).

А сейчас слово Ивану.

Интервью с Иваном Кругловым, Principal Developer: Service Mesh и «нестандартные» инструменты Booking.com - 1

Читать полностью »

Любое программное обеспечение — это объект интеллектуальной собственности. По сложившейся на рынке практике многие производители ПО оставляют за собой исключительные права на владение продуктом и лишь предоставляют клиентам возможность использовать одну или несколько его копий. Эти и другие юридические тонкости оговариваются в специальных документах — лицензионных соглашениях.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js