Компания Kolesa Group временно не ведёт блог на Хабре
“Разработка API сложна, Postman делает её лёгкой” © Postdot Technologies, Inc
Когда видишь описание инструментов Postman — захватывает дух, просыпается чувство всевластия над своим будущим детищем. Кажется, что и взрощенные в прошлом "монстры" наконец-то падут перед тобой!
В этой статье мы расскажем о Postman и попробуем написать свой первый скрипт.
Вольный перевод статьи Итамара Гилада, консультанта по росту и стратегии, бывшего продакт-менеджера Google, о подходе к стратегическому планированию развития продуктов.
На протяжении лет я разработал немалое количество продуктовых стратегий, роадмапов и диаграмм Ганта по проектам. Но больше я их не делаю. Я нашёл альтернативу получше, о которой сейчас расскажу.
Как и все интересные истории, эта началась достаточно давно и неожиданно. Однажды наш банк-партнер пришел к нам и сказал: “Ребята, мы научились делать скоринг в нашей системе за одну минуту. Как насчет того, чтобы объединить наши усилия и интегрировать проекты? С нас – решение и кредит, с вас – машины”. Сказать, что мы воодушевились, – ничего не сказать! Мы имели все шансы стать первыми чуть ли не в мире, кто может дать кредит онлайн на подержанное авто за одну минуту (ОДНУ МИНУТУ, КАРЛ)! Ниже я расскажу, что из этого получилось, но для начала расскажу вам, кто такие, собственно, МЫ.
В современных продуктовых компаниях самое главное — это продукт и его пользователи. Чтобы повысить фокус разработки на продукте, стандартом де-факто в отрасли являются кросс-функциональные команды.
Мы в Kolesa Group прошли путь от иерархической структуры управления в матричную. Хапнули багов и пропатчили ее до оптимального, в нашем профиле, состояния.
В статье разберем:
1. Как достичь автономности команд разработки.
2. Как эта автономность помогает нам расти в 2 раза по всем показателям.
При разработке Android приложений наступают моменты, когда те или иные части кода можно вынести в виде библиотек, чтобы можно было переиспользовать их в разных проектах:
Чаще всего все проблемы были решены задолго до нас, но в нашем случае нужно было вынести часть слоя бизнес-логики и фактически весь слой, отвечающий за данные в 3 наших основных продукта объединенной компании Колёса Крыша Маркет. Все наши продукты – классифайды про автомобили, недвижимость и прочие товары. Поэтому нами, разработчиками, было решили написать одно решение для всех продуктов компании. К тому же, это облегчило нашу работу.
Давайте представим, что вы управляете продуктом, который помогает малому бизнесу осуществлять техническую поддержку своих клиентов. Вы ищете способы увеличить степень вовлечённости (engagement) и возвращаемости (retention) своих клиентов. У вас есть две идеи:
Дашборд – это фича, которая уже несколько раз обсуждалась с пользователями и вы чувствуете, что у неё есть большой потенциал, но также осознаёте риск того, что только один крупный пользователь будет пользоваться дашбордами. Чат-бот – это то, что нравится всем сотрудникам вашей компании и продавливается руководством – это похоже на очень нужную вещь для клиентов, это классный проект. И да, чат-боты сейчас в моде.
Что вы выберете?
Статья рассказывает, почему наиболее популярный способ приоритизации бэклога не так хорош, как принято думать, и что можно сделать, чтобы улучшить его.
Оценка трудозатрат на разработку и ценности (отдачи от трудозатрат) — главный элемент приоритизации в продуктового бэклога: это простой понятный подход, а потому очень популярный. У вас наверняка есть 2 такие колонки в продуктовом бэклоге (и даже если нет, то стоит их добавить):
В недавней статье наш боевой товарищ actopolus рассказал о том, как мы научились применять Postman для реализации функционального тестирования нашего API проекта. Научившись писать функциональные тесты, и написав их порядка полутора сотен, мы решили, что настало то самое время — время прикрутить эти тесты к нашим CI-сборочкам.
Вообще, изначально процесс интеграции Postman-тестов в сборки можно было разбить на 3 простых этапа:
Однако, нами не был учтён один очень важный нюанс — у нас не было инструмента для измерения покрытия нашего кода Postman-тестами. Без информации о том, насколько хорошо мы покрываем тестами код, нам было сложно понять где мы находимся сейчас и к чему нам нужно стремиться. Следовательно, план был дополнен ещё одним пунктом:
