Этот дайджест создан совместно с телеграм-каналом PM Live ? проджект и продакт менеджмент. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
? Почитать:
Если у вас большая система, состоящая из множества микросервисов, то вы наверняка задавались вопросом: «Что сделать, чтобы архитектурная схема этой махины была на 100% актуальной?»
Ранее для получения доступа требовалось наличие не менее 300 пользователей, платящих по $9000 в месяц. Теперь ограничений нет. Любые компании могут подключить опцию за $30 за одного пользователя.
Разработка ПО почти полностью состоит из быстрого цикла экспериментов. У нас есть мысль о том, как мы можем решить задачу, нам требуется несколько секунд, чтобы написать решение, а затем мы его выполняем. Если это срабатывает, мы переходим к следующей задаче, если не срабатывает, то пробуем другую мысль. Когда у нас заканчиваются идеи, то мы переходим на Stack Overflow и пытаемся найти что-нибудь там. Клинические испытания могут длиться месяцами, а большинство экспериментов в разработке ПО занимают меньше минуты — это может быть быстрое изменение строки кода, проверка прохождения юнит-тестов или результатов при повторном запуске программ или перезапуске браузера. Наши циклы гораздо короче, но мы всё равно не можем предвидеть дальше, чем результат следующего эксперимента.
Как мы «укрощаем» рентабельность и какие для этого используем инструменты.
Это возможность выпить вместе кофе, или 15 минут перерыва, чтобы проверить почту/телефон (спасибо удаленке), или это возможность узнать, кто из коллег в офисе (если вы вернулись в офис).
Я обучаю стажеров – системных аналитиков, и недавно столкнулась с такими вопросами, о которых раньше даже не задумывалась. Вопросы были связаны с разными видами ключей в базе данных и с тем, как они связаны между собой (тему с реляционными БД мы разбираем на примере PostgreSQL).
Что такое оркестровая разработка. Один профессиональный дирижер может управлять огромным оркестром, с которым раньше даже не работал. Всё это связано с его профессионализмом дирижера и грамотной организацией оркестра. В современной разработке дела обстоят очень схоже, так как современный заказчик создает у себя костяк самых сильных специалистов, которые дирижируют подрядчиками и линейными специалистами.
Ну теперь вы, вроде, полноценный винтик среднего звена, так называемый middle developer, теперь хочется расти еще выше, в лиды —> архитекторы —> CTO. А проблема на самом деле в том, что хоть сейчас у вас и есть уверенность в том, как писать какие-то функции, строить REST-приложения, но нет уверенности в том, правильно ли это делается с нуля, чист ли ваш код, как управлять другими разработчиками. Если вы задавались такими же вопросами или столкнулись с такой же проблемой, то в этой статье я постараюсь кратко описать некоторые вещи, которые помогли именно мне с этим разобраться.
Главная черта продакт-менеджера — это широта компетенций. Именно он в компании лучше всего представляет себе целевую аудиторию, вашу сферу в целом, ваше направление и сам продукт. Это дает ему право принимать важные решения по его развитию. Если же какая-либо из многочисленных компетенций продакта, по мнению коллег, развита у них лучше, то они считают, что обязательно должны вмешаться в его работу. Особенно ярко это проявляется со стороны топ-менеджеров, в глубине души считающих, что они сами справились бы со всем не хуже.
Есть мнение, что аналитик нужен зрелому продукту: когда уже есть стабильная аудитория и выручка, а команда хочет запустить исследования, чтобы развиваться дальше. Но я убеждена, что аналитика полезно подключить уже на этапе дискавери — это может улучшить результаты запуска и уменьшить объём разработки. В статье расскажу об этом на примере нашего продукта — рассылки спецпредложений.
Сейчас из любого утюга кричат про то, что бизнес делается людьми и важно этих людей уважать, любить и уделять внимание их состоянию. Я не исключение и также считаю. Но давайте честно, не все мы эмпатичны по своей природе. Для кого-то хвалить сотрудников и искренне ими интересоваться совсем не естественно. А, если переборщить, легко забыть про бизнес-цели и потерять бдительность в своих управленческих решениях.
Для меня Теория Ограничений (ТОС) — это не про поиск бутылочного горлышка, или использование буфера, или прохода, или даже туч. ТОС — это умение видеть простоту в сложном, отбрасывать лишнее и находить относительно быстрые прорывные решения.
? Посмотреть:
- Почему роботы не взлетают ⏱40 минут
Почему со временем падают инициативы на настройку программных роботов.
- Docs-as-Code на пальцах ⏱40 минут
Вебпрактик разрабатывает сервисы для Лукойла, Почта Банка, Сибера, ПСБ.
- UX-исследования для аналитиков ⏱15 минут
СП.АРМ — медицинские инфосистемы.
Конфликтные ситуации и методы разрешения споров.
Хорошей недели!
