Архитектура продукта
Многие продвинутые компании всерьез заменяют проджекта продактом. Поэтому продакту все больше приходится погружаться в разработку продукта и понимать из чего она состоит.
Это помогает:
1. экологично подходить не только к деньгам, но и к команде. Чтобы ее не измотать и вовремя спрашивать совета. (А это правда важно, чтобы разработка была адекватная нужен взгляд не только сверху вниз, но и наоборот)
2. помогает понимать из чего состоит продукт и на глаз примерно определять его сложность
3. проводить приблизительный эстимейшн, когда нужно оценить фичу или задачу без команды на глаз (конечно это будет сильно грубо, но продакты знают что такие ситуации происходят постоянно). Непонимание сроков - это одна из топ проблем почему продакты чувствует себя идиотами
4. адекватно оценивать ресурсы на старте разработки
Что делаю я на старте разработки?
1. набрасываю крупноблочную архитектуру продукта по бизнес-функцим: отдельно из чего состоит фротент и из чего состоит бэкэнд
2. смотрим, что можем заменить nocode или third-party сервисами, чтобы упростить и удешевить
3. делаем декомпозицию по фичам
На практике все это сливается в одну задачу, а не в три последовательные.
Чтобы упростить построение, отталкивайтесь от верхнеуровнего CJM
После пары таких встреч с командой вам будет легче коммуницировать с командой и появится понимание о том, какие ресурсы вам нужны
Многие продвинутые компании всерьез заменяют проджекта продактом. Поэтому продакту все больше приходится погружаться в разработку продукта и понимать из чего она состоит.
Это помогает:
1. экологично подходить не только к деньгам, но и к команде. Чтобы ее не измотать и вовремя спрашивать совета. (А это правда важно, чтобы разработка была адекватная нужен взгляд не только сверху вниз, но и наоборот)
2. помогает понимать из чего состоит продукт и на глаз примерно определять его сложность
3. проводить приблизительный эстимейшн, когда нужно оценить фичу или задачу без команды на глаз (конечно это будет сильно грубо, но продакты знают что такие ситуации происходят постоянно). Непонимание сроков - это одна из топ проблем почему продакты чувствует себя идиотами
4. адекватно оценивать ресурсы на старте разработки
Что делаю я на старте разработки?
1. набрасываю крупноблочную архитектуру продукта по бизнес-функцим: отдельно из чего состоит фротент и из чего состоит бэкэнд
2. смотрим, что можем заменить nocode или third-party сервисами, чтобы упростить и удешевить
3. делаем декомпозицию по фичам
На практике все это сливается в одну задачу, а не в три последовательные.
Чтобы упростить построение, отталкивайтесь от верхнеуровнего CJM
После пары таких встреч с командой вам будет легче коммуницировать с командой и появится понимание о том, какие ресурсы вам нужны
На днях стала членом Скрам Альянса. Теперь я сертифицированный скрам продакт оунер (CSPO)
Зачем?
1. По итогу ресечинга европейского рынка, это нужно и важно.
2. Это интересный челендж-приключение.
3. Это одна из ступеней в рамках моего плана по повышению квалификации.
Как прошло?
Было интересно. Я выбрала на сайте скрам альянса сертифицированного тренера, чтобы в последующем сдать экзамен.
Из всех мне приглянулся британец с нетипичным тренингом, а симуляцией.
Стоит около 800 евро. Плюс мне понравился его график. Все тренера предлагали 2 дня по 8 часов, а мой тренер 3 дня по 4 часа. Это было значительно удобнее с мужем и ребенком без нянь и бабушек.
Итого:
Нового для меня было крайне мало. В основном систематизация знаний, несколько интересных инсайтов, прикольное международное обучение с кейсами коллег и я узнала себя чуточку лучше.
Я в основном практик, я даже не знала что "и это я делала" и "вот тут тоже". Поэтому на тренинге я скорее изучала свой опыт))))
В итоге сертификат дали без экзамена. Мне он нужен чтобы подтвердить знания и навыки того, что я умею в скрам.
Теперь думаю, что вероятно пойду на вторую ступень. :)
Следующим постом, как обещала, прям точно точно, напишу план своего обучения в рамках бюджета (5 тысяч долларов):)) Накидайте огонечков:)
Зачем?
1. По итогу ресечинга европейского рынка, это нужно и важно.
2. Это интересный челендж-приключение.
3. Это одна из ступеней в рамках моего плана по повышению квалификации.
Как прошло?
Было интересно. Я выбрала на сайте скрам альянса сертифицированного тренера, чтобы в последующем сдать экзамен.
Из всех мне приглянулся британец с нетипичным тренингом, а симуляцией.
Стоит около 800 евро. Плюс мне понравился его график. Все тренера предлагали 2 дня по 8 часов, а мой тренер 3 дня по 4 часа. Это было значительно удобнее с мужем и ребенком без нянь и бабушек.
Итого:
Нового для меня было крайне мало. В основном систематизация знаний, несколько интересных инсайтов, прикольное международное обучение с кейсами коллег и я узнала себя чуточку лучше.
Я в основном практик, я даже не знала что "и это я делала" и "вот тут тоже". Поэтому на тренинге я скорее изучала свой опыт))))
В итоге сертификат дали без экзамена. Мне он нужен чтобы подтвердить знания и навыки того, что я умею в скрам.
Теперь думаю, что вероятно пойду на вторую ступень. :)
Следующим постом, как обещала, прям точно точно, напишу план своего обучения в рамках бюджета (5 тысяч долларов):)) Накидайте огонечков:)
Еще очень сильно заебали боты в комментариях. Банишь одного, появляется еще три...
Повышение квалификации на 5000$
#международка
Рассказываю по пунктам, что я подобрала для себя, как и обещала
Давайте начну сначала с выводов
1. Сразу скажу для тех кто хватается за сердце, эта сумма не очень большая по меркам Европы и, тем более, США. Я бы сказала далеко не большая.
2. Промониторив множества продуктовых школ и курсов, а также курсов элитных международных школ, я хочу сказать, что дешевое и качественное обучение по теме именно в России. Да-да, именно дешевое и качественное. Ниже показываю на примере. Ниже цены ставят наверно только индусы.
3. Для меня оказалось 2 самых подходящих, самых офигенных и удобных формата: тренинги на несколько дней интенсивной работы и ....тренажеры-симуляторы.
4. Тренажеры-симуляторы сделали мое кормление веселее! Это как судоку или шахматы))) Или тестики, которые практически все люди любят проходить. Вам же маркетологи предлагали собирать лидов через квизы, чтобы "повышать" конверсию?)) Ну ладно, это немножко не по теме. Основная мысль, это то, что я всегда знала про формат симуляторов, но я не думала, что это удобно, весело и ооочень вовлекает. Я уверена, что доходимость таких курсов сильно выше.
5. Повышение квалификации для меня заключается не только в приобретении знаний и навыков, но и в исследовании того, что я уже знаю или углубить то, что я уже умею. Это такой маленький пунктик, который помогает систематизировать свой опыт и ...лучше продавать его работодателю.
То есть цель не узнать что-то кардинально новое, цель систематизировать и углубить то, что есть и восполнить пробелы в теории и практике.
Теперь к курсам
1. Тренинги для сертификации на скрам продакт оунера. Выбрала Альянс. Подробнее написала тут.
Нужно, чтобы лучше внедрять его в проекты. Работаю постоянно именно по скрам и хотелось больше деталей и глубины для работы с командой. Стоимость 800 евро.
2. AgileFluent. Практикум по бизнес английскому для продактов. 8 встреч около 30 тысяч рублей (roughly 300 евро). Идея отличная, словарный запас прокачивают нормально. Вы решаете продуктовые задачи на английском языке, что неплохо погружает. Но я так скажу, что по итогу двух встреч, я не считаю это наилучшим вариантом. Скорее начальным.
Если вы хотите прочитать про это подробнее, накидайте ❤️. Я распишу эффективную схему погружение в бизнес английский
3. ProductDO. Симулятор. Технические знания для продакта (250 евро). Прикол что я нашла их курс на английском языке и он дешевле, чем на русском))))
Это наверно лучшее, что я брала. Очень прокачивает именно в техническом плане. После курса полюбила свою команду еще сильнее, потому что ребята минимизировали высокую связанность. Мне кажется я начинаю понимать команду еще лучше! Такого продукта я даже на зарубежном рынке не находила. Владимир Калмыков, если ты меня читаешь, это охуенный обучающий продукт!
4. GoPractice. Тоже симулятор. У этих ребят тоже есть английская версия курсов, но стоит она уже дороже. Управление продуктом на основе данных. 55 тысяч рублей. Планирую погрузится больше в АБ тесты и рост продукта. Потом увидела что у ребят есть целый курс по росту продукта, пожалела, что не взяла его. Но думаю это уже следующий раз.
ИТОГО: 2300 евро.
Пока что все.
В закладках лежит и Reforge и Data-driven от Стэнфорда, но это скорее веселый опыт. Я не увидела в этих курсах чего-то супер значимого. Они скорее решают вопрос моего личного любопытства и экспириенса. Ну и условного "бренда", который будет красоваться у меня в линкиде (когда я до него доберусь конечно же))))
#международка
Рассказываю по пунктам, что я подобрала для себя, как и обещала
Давайте начну сначала с выводов
1. Сразу скажу для тех кто хватается за сердце, эта сумма не очень большая по меркам Европы и, тем более, США. Я бы сказала далеко не большая.
2. Промониторив множества продуктовых школ и курсов, а также курсов элитных международных школ, я хочу сказать, что дешевое и качественное обучение по теме именно в России. Да-да, именно дешевое и качественное. Ниже показываю на примере. Ниже цены ставят наверно только индусы.
3. Для меня оказалось 2 самых подходящих, самых офигенных и удобных формата: тренинги на несколько дней интенсивной работы и ....тренажеры-симуляторы.
4. Тренажеры-симуляторы сделали мое кормление веселее! Это как судоку или шахматы))) Или тестики, которые практически все люди любят проходить. Вам же маркетологи предлагали собирать лидов через квизы, чтобы "повышать" конверсию?)) Ну ладно, это немножко не по теме. Основная мысль, это то, что я всегда знала про формат симуляторов, но я не думала, что это удобно, весело и ооочень вовлекает. Я уверена, что доходимость таких курсов сильно выше.
5. Повышение квалификации для меня заключается не только в приобретении знаний и навыков, но и в исследовании того, что я уже знаю или углубить то, что я уже умею. Это такой маленький пунктик, который помогает систематизировать свой опыт и ...лучше продавать его работодателю.
То есть цель не узнать что-то кардинально новое, цель систематизировать и углубить то, что есть и восполнить пробелы в теории и практике.
Теперь к курсам
1. Тренинги для сертификации на скрам продакт оунера. Выбрала Альянс. Подробнее написала тут.
Нужно, чтобы лучше внедрять его в проекты. Работаю постоянно именно по скрам и хотелось больше деталей и глубины для работы с командой. Стоимость 800 евро.
2. AgileFluent. Практикум по бизнес английскому для продактов. 8 встреч около 30 тысяч рублей (roughly 300 евро). Идея отличная, словарный запас прокачивают нормально. Вы решаете продуктовые задачи на английском языке, что неплохо погружает. Но я так скажу, что по итогу двух встреч, я не считаю это наилучшим вариантом. Скорее начальным.
Если вы хотите прочитать про это подробнее, накидайте ❤️. Я распишу эффективную схему погружение в бизнес английский
3. ProductDO. Симулятор. Технические знания для продакта (250 евро). Прикол что я нашла их курс на английском языке и он дешевле, чем на русском))))
Это наверно лучшее, что я брала. Очень прокачивает именно в техническом плане. После курса полюбила свою команду еще сильнее, потому что ребята минимизировали высокую связанность. Мне кажется я начинаю понимать команду еще лучше! Такого продукта я даже на зарубежном рынке не находила. Владимир Калмыков, если ты меня читаешь, это охуенный обучающий продукт!
4. GoPractice. Тоже симулятор. У этих ребят тоже есть английская версия курсов, но стоит она уже дороже. Управление продуктом на основе данных. 55 тысяч рублей. Планирую погрузится больше в АБ тесты и рост продукта. Потом увидела что у ребят есть целый курс по росту продукта, пожалела, что не взяла его. Но думаю это уже следующий раз.
ИТОГО: 2300 евро.
Пока что все.
В закладках лежит и Reforge и Data-driven от Стэнфорда, но это скорее веселый опыт. Я не увидела в этих курсах чего-то супер значимого. Они скорее решают вопрос моего личного любопытства и экспириенса. Ну и условного "бренда", который будет красоваться у меня в линкиде (когда я до него доберусь конечно же))))
Telegram
ROSLOVETS
На днях стала членом Скрам Альянса. Теперь я сертифицированный скрам продакт оунер (CSPO)
Зачем?
1. По итогу ресечинга европейского рынка, это нужно и важно.
2. Это интересный челендж-приключение.
3. Это одна из ступеней в рамках моего плана по повышению…
Зачем?
1. По итогу ресечинга европейского рынка, это нужно и важно.
2. Это интересный челендж-приключение.
3. Это одна из ступеней в рамках моего плана по повышению…
Про архитектуру для продакта с нуля часть 2
Часть 1 тут.
Этот пост поможет тем, кто делает продукт from scratch
Нет, не надо пытаться прыгнуть выше архитектора и СТО и изучать SOLID принципы. Достаточно понимать крупноблочно на какие блоки разбивается фронтенд, какие сервисы работают в бэкенде и как они взаимодействуют с друг другом, какие есть сторонние сервисы (например апи карт или платежки).
Нужно это, чтобы исключать дубляжи в коде и не изобретать велосипед, общаться с разработчиками и понимать почему они недоверчиво смотрят на ваши охуенно важные ноу-хау и самое главное, чтобы код (внимание) строился с верху вниз, а не наоборот.
Как я делала это раньше?
1. в Миро крупноблочно делала карточки с функционалом со стороны клиента. Какие задачи он должен решать с помощью нашего продукта? В какой последовательности? Это был первый слой.
2. вторым слоем совместно с бэкенд-разработчиком мы прорабатывали блоки (сервисы), которые решают задачи из пункта 1.
3. параллельно продумывали, что из этого мы можем заменить на ноукод или готовые сервисы. Например, зачем городить бэкенд и писать код, если есть Strapi?
Как можно это улучшить?
Я столкнулась с недостатком. Связан он с тем, что когда вы сделали продукт, оказывается фронтенд как бы в вакууме. То есть вы обсудили крупноблочно блоки и фичи, но сам код во фронте построен так, как удобно разработчику. Бэкенд в таком подходе получается так как вы проработали блоки. И дальше при масштабировании, изменении продукта или вообще замены разработчика боли особо не чувствуется. А фронтенд сам по себе.
Есть 4-слойный тип архитектуры. Первый -оч бизнесовый, второй и третий - вы прорабатываете с командой и 4-ый куда вы не лезете. Вот статья, в которой можно изучить эту систему поподробнее.
Это немного другое разделение и более глубокий подход к построению архитектуры с нуля (чтобы бизнес и разработка встретились в одной точке и все были рады).
Вы сразу прорабатываете архитектуру как во фронте, так и на бэке исходя из бизнес функций и бизнес задач. Вы сразу приучаете разработку (фронт + бэк) работать так, чтобы сервисы делились на всех уровнях по бизнес задачам, а не так как увидел этохудожн разработчик
Часть 1 тут.
Этот пост поможет тем, кто делает продукт from scratch
Нет, не надо пытаться прыгнуть выше архитектора и СТО и изучать SOLID принципы. Достаточно понимать крупноблочно на какие блоки разбивается фронтенд, какие сервисы работают в бэкенде и как они взаимодействуют с друг другом, какие есть сторонние сервисы (например апи карт или платежки).
Нужно это, чтобы исключать дубляжи в коде и не изобретать велосипед, общаться с разработчиками и понимать почему они недоверчиво смотрят на ваши охуенно важные ноу-хау и самое главное, чтобы код (внимание) строился с верху вниз, а не наоборот.
Как я делала это раньше?
1. в Миро крупноблочно делала карточки с функционалом со стороны клиента. Какие задачи он должен решать с помощью нашего продукта? В какой последовательности? Это был первый слой.
2. вторым слоем совместно с бэкенд-разработчиком мы прорабатывали блоки (сервисы), которые решают задачи из пункта 1.
3. параллельно продумывали, что из этого мы можем заменить на ноукод или готовые сервисы. Например, зачем городить бэкенд и писать код, если есть Strapi?
Как можно это улучшить?
Я столкнулась с недостатком. Связан он с тем, что когда вы сделали продукт, оказывается фронтенд как бы в вакууме. То есть вы обсудили крупноблочно блоки и фичи, но сам код во фронте построен так, как удобно разработчику. Бэкенд в таком подходе получается так как вы проработали блоки. И дальше при масштабировании, изменении продукта или вообще замены разработчика боли особо не чувствуется. А фронтенд сам по себе.
Есть 4-слойный тип архитектуры. Первый -оч бизнесовый, второй и третий - вы прорабатываете с командой и 4-ый куда вы не лезете. Вот статья, в которой можно изучить эту систему поподробнее.
Это немного другое разделение и более глубокий подход к построению архитектуры с нуля (чтобы бизнес и разработка встретились в одной точке и все были рады).
Вы сразу прорабатываете архитектуру как во фронте, так и на бэке исходя из бизнес функций и бизнес задач. Вы сразу приучаете разработку (фронт + бэк) работать так, чтобы сервисы делились на всех уровнях по бизнес задачам, а не так как увидел это
Как написать ТЗ на разработку
😐 Я не люблю текстовые форматы ТЗ. Обычно они пишутся плохо. Я всегда за визуал.
😐 Я люблю, когда исполнители не требуют досконального ТЗ и задают вопросы, чтобы уточнить детали и сделать задачу лучше.
😐 Мне приходится часто писать ТЗ и формулировать его, но иногда приходится и "собирать" ТЗ от людей, которые шарят в доменной области. Да-да, прям как проджект. Так сложилось, такое бывает.
К чему я пришла?
Во-первых, ТЗ всегда стараюсь делать в Miro. Визулизация- наше все. В ней сразу все понятно. Из каких блоков задача и что для этого надо. ТЗ сразу отражает последовательность действия пользователей или системы.
Во-вторых, люди которые шарят в доменной области не умеют формулировать ТЗ. Всю их отсебятину "мы тут написали документик" можно выкидывать. Потому что эту по*боту никто не то чтобы не прочитает, ее никто не поймет. Часто с этим просто невозможно работать.
В третьих, если ТЗ непонятное, у разработчиков начинается аллергия, выражающаяся в прокрастинации.
😮 Чтобы написать ТЗ на задачу в области, который не шаришь, по моему опыту, есть один фреймворк.
Разбиваете задачу на то, что на входе, что должно получится на выходе и преобразовательные процессы между ними.
Сначала спрашиваете стейкхолдера: что происходит на входе? Какие параметры? Какие действия пользователя должны произойти? В каком виде?
Потом, что на выходе: какой образ результата? Что должно отобразиться? Что должно произойти? Какой результат должен появится?
После, какие процессы происходят между входом и выходом.
Например, мы делаем калькулятор. Понятное дело, что математику (что и как считать) понимают только люди, которые разбираются в этом, поэтому каждый шаг математики мы также визуализируем и декомпозируем на шаги для бэкендера. Важно, чтобы для него не появлялись новые параметры из неоткуда. Новые вводные всегда поясняются: идут от пользователя или формируются внутри.
Вы как бы раскручиваете каждый из этих вопросов. Также декомпозируете на те уровни абстракции, которые вам нужны.
Было полезно? Ставь 🔥
К чему я пришла?
Во-первых, ТЗ всегда стараюсь делать в Miro. Визулизация- наше все. В ней сразу все понятно. Из каких блоков задача и что для этого надо. ТЗ сразу отражает последовательность действия пользователей или системы.
Во-вторых, люди которые шарят в доменной области не умеют формулировать ТЗ. Всю их отсебятину "мы тут написали документик" можно выкидывать. Потому что эту по*боту никто не то чтобы не прочитает, ее никто не поймет. Часто с этим просто невозможно работать.
В третьих, если ТЗ непонятное, у разработчиков начинается аллергия, выражающаяся в прокрастинации.
Разбиваете задачу на то, что на входе, что должно получится на выходе и преобразовательные процессы между ними.
Сначала спрашиваете стейкхолдера: что происходит на входе? Какие параметры? Какие действия пользователя должны произойти? В каком виде?
Потом, что на выходе: какой образ результата? Что должно отобразиться? Что должно произойти? Какой результат должен появится?
После, какие процессы происходят между входом и выходом.
Например, мы делаем калькулятор. Понятное дело, что математику (что и как считать) понимают только люди, которые разбираются в этом, поэтому каждый шаг математики мы также визуализируем и декомпозируем на шаги для бэкендера. Важно, чтобы для него не появлялись новые параметры из неоткуда. Новые вводные всегда поясняются: идут от пользователя или формируются внутри.
Вы как бы раскручиваете каждый из этих вопросов. Также декомпозируете на те уровни абстракции, которые вам нужны.
Было полезно? Ставь 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет! Это Лев, продакт и автор канала @levlevitsky_channel. Сегодня хочу поговорить о том, почему команда разработки может терять мотивацию и как я с этим справлялся.
Я работал с разными командами. И часто видел такую ситуацию: фичи делаются все медленнее, творческий подход пропадает, глаза не горят и вот это вот все. Кстати, такой кейс часто дают на собесах на продакта — ведь он регулярно встречается в жизни.
Представьте: вот к разработке пришли с задачкой. Побрейнштормили вместе, пошатали требования (с). Запилили задачку. А что дальше-то? Зачем все это, зачееем?
Важная функция продакта — подсвечивать команде разработки ценность, которую она создает для продукта. Важно, чтобы разработчики не ощущали, что они существуют отдельно от продукта, пишут свой код в вакууме. Их деятельность неразрывно связана с продуктом и оказывает на него прямое влияние. Будем честны — если бы не разработка, ничего бы не было.
— ходить на дейлики разработки: делиться там новостями, которые происходят в продукте, мелкими задачками, показывать связь разработки и продукта
— выступать на демо разработки с результатами: а вот помните, мы запилили два месяца назад такую фичу, она нам принесла столько-то денег, а еще мы узнали из касдевов, что клиентам она нравится потому-то
— честно рефлексировать на ретро: благодаря слаженной работе мы запилили в этот спринт такую-то классную штуку, а могли бы не запилить, но запилили, и клиенты уже сейчас начинают ей пользоваться
— на продуктовых синках и презентациях подсвечивать, что такой-то результат был получен благодаря команде разработки, которая быстро и слаженно запилила фичу или что-то починила
— Как описывать продуктовые кейсы? Фреймворк STAR
— Мощный шаблон резюме для продакта + мой подход к созданию резюме
— Что нужно уметь продакту в мире нейросетей?
— Важнейший принцип ведения задач: всегда уточняйте и фиксируйте сроки
— Где продакту искать вакансии?
— И подборка из ТОП-50 постов: вы точно найдете там для себя что-то интересное
Рад был познакомиться! Ставьте реакции, оставляйте комментарии, подписывайтесь на мой канал! И спасибо Фаре за предоставленную площадку 🙂
Ваш продуктовый Лев
@levlevitsky_channel
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Лев Левицкий
✅ Как ставить задачи, чтобы их с удовольствием выполняли? Не только ставить, но и возвращаться с результатами
Любой продакт часто дает задачи исполнителям. Например, на дизайн, аналитику, разработку, тексты. И есть способы делать это так, чтобы всем Важно!…
Любой продакт часто дает задачи исполнителям. Например, на дизайн, аналитику, разработку, тексты. И есть способы делать это так, чтобы всем Важно!…
Вкусный оффер, распиаренный бренд, ласковый hr- ещё не гарантия, что работать в компании будет хорошо.
Гостевой пост от аналитического авторского канала Тимлида Анны @analyst_lead про аналитику для аналитиков и не только. Ловите полезный пост от Анны про то, как понять какой перед вами работодатель:)
'Гладко стелят, да жёстко спать' - сталкивались с таким?
Мои способы понять, какой перед тобой работодатель:
1. Спрашивать про цели команды, в которую собеседуюсь, на ближайший год - два. Далеко не все умеют сформулировать.
2. Попросить рассказать истории успеха текущих сотрудников внутри компании - грейд повысил, роль поменял, на более интересный проект перешёл и тп.
Слушать и делить на 2)
3. Собрать максимум инфы из открытых источников о компании и работе в ней
4. Наблюдать за эмоциональным состоянием сотрудников, которые тебя собеседуют и расхождениями в ответах.
Бывает очень заметно, что человеку крайне не комфортно и собеседовать, и рассказывать о проекте, компании. Это серьёзный звоночек, особенно когда так выглядит архитектор, тех спецы
5. Ещё хороший вопрос про работу над ошибками в команде - как процесс организован, что считается ошибкой. Иногда попадаются товарищи с ответом 'у нас ошибок не бывает, у нас всё идеально работает' Верите? Вот и я нет.
6. Плюс вопросы по всем 'болям', которые накопились на предыдущих местах работы
По совокупности добытой информации можно делать выводы о том, что ждёт тебя на борту.
Проходить собесы, входить в новую команду и проект тяжело, особенно если ты уже прошёл уровень джуна. Не стесняйся спрашивать - сэкономь себе силы и время.
Анна Аналитическое
Гостевой пост от аналитического авторского канала Тимлида Анны @analyst_lead про аналитику для аналитиков и не только. Ловите полезный пост от Анны про то, как понять какой перед вами работодатель:)
'Гладко стелят, да жёстко спать' - сталкивались с таким?
Мои способы понять, какой перед тобой работодатель:
1. Спрашивать про цели команды, в которую собеседуюсь, на ближайший год - два. Далеко не все умеют сформулировать.
2. Попросить рассказать истории успеха текущих сотрудников внутри компании - грейд повысил, роль поменял, на более интересный проект перешёл и тп.
Слушать и делить на 2)
3. Собрать максимум инфы из открытых источников о компании и работе в ней
4. Наблюдать за эмоциональным состоянием сотрудников, которые тебя собеседуют и расхождениями в ответах.
Бывает очень заметно, что человеку крайне не комфортно и собеседовать, и рассказывать о проекте, компании. Это серьёзный звоночек, особенно когда так выглядит архитектор, тех спецы
5. Ещё хороший вопрос про работу над ошибками в команде - как процесс организован, что считается ошибкой. Иногда попадаются товарищи с ответом 'у нас ошибок не бывает, у нас всё идеально работает' Верите? Вот и я нет.
6. Плюс вопросы по всем 'болям', которые накопились на предыдущих местах работы
По совокупности добытой информации можно делать выводы о том, что ждёт тебя на борту.
Проходить собесы, входить в новую команду и проект тяжело, особенно если ты уже прошёл уровень джуна. Не стесняйся спрашивать - сэкономь себе силы и время.
Анна Аналитическое
Telegram
Anna Sea IT
Менеджмент без нервов
Знаю, как с малыми командами делать большие дела
Анонимные айтишники живут тут
https://tttttt.me/+zUD4kNG
Поработать со мной
https://seait.yonote.ru/share/f5987a13-2485-43ec-8eb3-85c5c952d395
Для связи @aiti_career отвечаю не торопясь
Знаю, как с малыми командами делать большие дела
Анонимные айтишники живут тут
https://tttttt.me/+zUD4kNG
Поработать со мной
https://seait.yonote.ru/share/f5987a13-2485-43ec-8eb3-85c5c952d395
Для связи @aiti_career отвечаю не торопясь
Scrum на пальцах
Недавно обнаружила, что меня читают люди которые не знают что такое Скрам, но при этом сами не в курсе, что по нему работают
Давайте я вам помогу.
😐 В скраме есть 3 роли: Product Owner, Scrum-мастер и разработчики. Product Owner отвечает за видение продукта, бэклог и приоритеты. Scrum-мастер обеспечивает соблюдение принципов Scrum и поддерживает команду. Разработчики занимаются созданием и тестированием продукта.
Многие думают, что продакт менеджер и оунер - это про разное. Статьи даже разные пишут, чтобы объяснить разницу между Product Owner и Product Manager. По факту, это просто название роли по скраму.
😐 Разработка должна быть инкрементальная. Это принцип пошагового развития продукта. Вместо того чтобы планировать и выпускать продукт целиком, команда разрабатывает его частями. Это позволяет быстрее получать обратную связь от клиентов и вносить корректировки в разработку.
Это в теории, на практике же есть MVP (ограниченное "сочное" количество фич, которые позволят проверять нашу основную гипотезу "купят-некупят") и все остальное ("много-много всего того, что мы хотим и это ОБЗАТЕЛЬНО НАДО!!!")
Вся инкрементальность - это продуктовое виденье того, какими фичами вы будете наслаивать свои продукт.
😐 Спринты и планирование: Спринт представляет собой фиксированный период времени (обычно 1-4 недели), в течение которого команда работает над определенными задачами. Перед каждым спринтом проводится планирование, на котором команда определяет цели и задачи для следующего периода.
Мы стараемся сделать так, чтобы 1 инкремент = набору бизнес фичей, а они, в свою очередь, были равны одному спринту. В реальности не всегда так получается.
😐 Отдельно стоит выделить митинги. В теории их 5:
- ежедневные дейлики, когда вы синхронизируетесь с командой,
- планирование спринта
- ретроспектива спринта
- актуализация бэклога
- обзор
На практике: нахуй можно послать все, кроме планирования спринта и акутализации бэклога. Не всегда конечно))) Но это самые важные митинги для исполнителя
😐 Самое важное, по моему мнению, что дал нам Скрам - это понятие "Definition of Done" (Коротко, DOD)
DOD - это критерий готовности нашего инкримента. Или, если декомпозировать, критерий готовности задачи. Основной вопрос "Как мы поймем, что задача готова? какой критерий?". Обычно стараемся придумывать критерий с физической реализацией и ее критеричми. Типо документ, работающий код, презентация...
Полезно? Ставь 🔥
Недавно обнаружила, что меня читают люди которые не знают что такое Скрам, но при этом сами не в курсе, что по нему работают
Давайте я вам помогу.
Многие думают, что продакт менеджер и оунер - это про разное. Статьи даже разные пишут, чтобы объяснить разницу между Product Owner и Product Manager. По факту, это просто название роли по скраму.
Это в теории, на практике же есть MVP (ограниченное "сочное" количество фич, которые позволят проверять нашу основную гипотезу "купят-некупят") и все остальное ("много-много всего того, что мы хотим и это ОБЗАТЕЛЬНО НАДО!!!")
Вся инкрементальность - это продуктовое виденье того, какими фичами вы будете наслаивать свои продукт.
Мы стараемся сделать так, чтобы 1 инкремент = набору бизнес фичей, а они, в свою очередь, были равны одному спринту. В реальности не всегда так получается.
- ежедневные дейлики, когда вы синхронизируетесь с командой,
- планирование спринта
- ретроспектива спринта
- актуализация бэклога
- обзор
На практике: нахуй можно послать все, кроме планирования спринта и акутализации бэклога. Не всегда конечно))) Но это самые важные митинги для исполнителя
DOD - это критерий готовности нашего инкримента. Или, если декомпозировать, критерий готовности задачи. Основной вопрос "Как мы поймем, что задача готова? какой критерий?". Обычно стараемся придумывать критерий с физической реализацией и ее критеричми. Типо документ, работающий код, презентация...
Полезно? Ставь 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
Протестила плагин ChatGPT для поиска работы Ambition
Ну ребят, совсем другое дело!
Теперь не нужно искать 100500 карьерных платформ и жалобно писать HR. Просто пишете запрос (страна/город, название позиции + специфичные запросы) и плагин, анализируя местные и крупные агрегаторы, выдает 5 релевантных вакансий с ссылками на них
Удобненько.
Ну ребят, совсем другое дело!
Теперь не нужно искать 100500 карьерных платформ и жалобно писать HR. Просто пишете запрос (страна/город, название позиции + специфичные запросы) и плагин, анализируя местные и крупные агрегаторы, выдает 5 релевантных вакансий с ссылками на них
Удобненько.
Как прокачать английский для работы
Мой топ приемов, которые работают.
🤼♀️ Завести чат в телеграме под названием "Английский" и скидывать в него слова и фразы, которые вы находите важными и интересными с переводом. Правило одно: в сообщении должно быть только слово-перевод. Ни грамматики, ни заметок и напоминаний. Никаких переписок. Не засоряйте чат. Когда я туплю в телеграме, я в этот чат невольно захожу и повторяю слова.
Кстати, в него вы можете пригласить друга. Это как игра. Как только друг перестает делится полезным словом или фразой недели, вылетает из группы нахуй))) оч мотивирует) потому что вы очень быстро увидете пользу от такого чатика) Периодически выкидываю мужа, после чего он начинает активно постить полезные словечки из рабочего чата))
🤼♀️ Обучение на английском. Этот метод работает на 100500 баллов. И работает он только на том, что ВАМ ИНТЕРЕСНО. Недавно я писала, что проходила тренинги для сертификации по скраму. Сделано это было на английском. Вы же не думаете, что таких тренингов нет на русском? Найти при желании можно, но не интересно. Самый лучший способ быстро прокачать язык-это учиться предметной области и тем темам, которые вам интересны в данный момент на английском.
Есть вероятность что вы не поймете какой-то процент сказанного. Это нормально! На работе в международной команде ребята с С1 могут не понять процентов 30 из всего, что они услышали (маленький секретик). Самое важное вы поймете или получите пизды и в следующий раз понимать будете)
🤼♀️ Любите психологию? Да полюбас вы drama queen, хоть и бородатый мужик за 40. Все мы там окажемся) К чему я.? Психологию любят все и оказывается, именно по психологии, приемлимые по сложности книжки в перемешку с универсальными словами и смыслами. И, оказывается, когда пишут про твою проблему прочитать ее ой как хочется. Именно в таких книжках хорошо развивается "лингвистическая интуиция". Это когда вы примерно предполагаете значение слова или фразы из общего контекста. Важный навык.
Пока вы выживаете на пункте 2 и страдаете на пункте 3, вы конечно попутно добавляете слова в п 1.
🤼♀️ Последний пункт, которым я также занимаюсь, это использование добавленных слов. Вам нужно моделировать ситуации, возвращаться к новым словам и повторять их в разных контекстах. Есть несколько вариантов: встречаться с иностранцами (даже в России есть встречи экспатов, которые туда эмигрировали), общаться с ChatGPT для прокачки, добавлять в словари и повторять в PuzzleEnglish, продумывать спичи в голове (что я делаю каждый день, невольно).
Есть свои способы? Поделись в комментариях:)
Было полезно? Ставь 🔥
Мой топ приемов, которые работают.
Кстати, в него вы можете пригласить друга. Это как игра. Как только друг перестает делится полезным словом или фразой недели, вылетает из группы нахуй))) оч мотивирует) потому что вы очень быстро увидете пользу от такого чатика) Периодически выкидываю мужа, после чего он начинает активно постить полезные словечки из рабочего чата))
Есть вероятность что вы не поймете какой-то процент сказанного. Это нормально! На работе в международной команде ребята с С1 могут не понять процентов 30 из всего, что они услышали (маленький секретик). Самое важное вы поймете или получите пизды и в следующий раз понимать будете)
Пока вы выживаете на пункте 2 и страдаете на пункте 3, вы конечно попутно добавляете слова в п 1.
Есть свои способы? Поделись в комментариях:)
Было полезно? Ставь 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
API на пальцах
Необходимый минимум, который нужно понимать.
😤 АПИ - это протокол передачи данных. По сути свод правил, по которым два сервиса "общаются" между собой.
😤 Раньше, когда интернет только появился и на его заре АПИ использовалось только для взаимодействия бэкенда и фронтенда между собой. Тогда же сформировались правила GET и POST ( а также еще несколько других, но они редко используются). Это запросы для того, чтобы что-то отправить с фронтенда на бекенд или запросить с него.
😤 Сейчас же АПИ стал более широко использоваться. Теперь АПИ создается под каждый сервис в бизнес логике приложения или сайта. Это называется "микросервисная архитектура". Это позволяет избежать дублирования кода и снизить связанность между компанентами кода для последующего масштабирования. Чтобы объяснить проще представьте, что у вас Озон. Представьте что будет, если весь этот огромный маркетплейс будет написан сплошлным текстом кода? Чтобы добавить функционал вы будете плакать и страдать. А если у вас код разделен на "бизнес-блоки", которые взаимодействуют между собой, вы четко знаете куда засунуть дополнительный функцонал, чтобы ничего не поломать
😤 Чтобы понять верхнеуровнево АПИ нужно знать, что оно состоит из:
- Метода ( по сути команда или функция)
- Пары "Параметр - значение". Параметры - те значения которые нужны на входе для исполнения команды.
Пример:
Допустим у вас есть АПИ конвертирования валюты. Вам нужно сконвертировать валюту (это наша команда, она же метод), ей на вход нужно подать параметры: (1) С какой валюты нужно конвертировать, (2) НА какую валюту, (3) СКОЛЬКО со следующими величинами (3) - USD, (2)-EUR, (3)-1000
.../convert?from=USD&to=EUR&amount=1000
😤 Чтобы сервисы передавали друг другу большие объемы информации, используется текстовый формат JSON. То есть когда будете слышать это слово, просто знайте, что это некий документ, который передается с фрондента на бэкенд для корректного обмена
Полезно? Ставь 🔥
Необходимый минимум, который нужно понимать.
- Метода ( по сути команда или функция)
- Пары "Параметр - значение". Параметры - те значения которые нужны на входе для исполнения команды.
Пример:
Допустим у вас есть АПИ конвертирования валюты. Вам нужно сконвертировать валюту (это наша команда, она же метод), ей на вход нужно подать параметры: (1) С какой валюты нужно конвертировать, (2) НА какую валюту, (3) СКОЛЬКО со следующими величинами (3) - USD, (2)-EUR, (3)-1000
.../convert?from=USD&to=EUR&amount=1000
Полезно? Ставь 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
Правила работы с данными
Я для себя определила несколько правил работы с данными. Какие-то я подчерпнула в процессе своей работы, какие-то позаимствовала у коллег.
😐 Когда работаешь с данными, нужно знать ответы на все вопросы, буквально по каждой циферке. Ты никогда не знаешь до чего доебется стейкхолдер.
😐 Одна мысль - один график. Всегда нужно помнить, что любая визуализация - это про донесение каких-то мыслей другим людям. Так вот, если этих мыслей в одном графике больше чем одна, то обязательно чей-то мозг на этом потечет
😐 Несмотря на пункт 1, людям нужны выводы. Большинство не погружается в то, что вы проанализировали и как. Это немножко давит на чувство ответственности, ибо все равно будешь сомневаться то ли ты нахуевертил и к правильным выводам ли ты пришел.
😐 Чистота данных - это круто, но если есть возможность, то лучше провалидировать результаты через анализ данных "с двух сторон". Это касается открытых источников. Допустим, вы анализируете рынок мобильных приложений в Зимбабве. Есть открытые данные. Вы получаете по ним выводы. Так вот провалидируйте эти данные через опросы, например, и убедитесь что они совпадают. По возможности...
😐 Всегда нужно задавать себе вопрос "могу ли я доверять этим данным?" Это будет напрямую влиять на перекосы в выводах.
Например, жила была копания Data.ai. Продавала данные крупным компаниям. А потом оказалось, что она ими манипулировала и получила за это штраф в 21 году в 10 миллионов долларов. Можем ли мы доверять данным на ее портале до 21 года?
Понравилось? Ставь 🔥
Я для себя определила несколько правил работы с данными. Какие-то я подчерпнула в процессе своей работы, какие-то позаимствовала у коллег.
Например, жила была копания Data.ai. Продавала данные крупным компаниям. А потом оказалось, что она ими манипулировала и получила за это штраф в 21 году в 10 миллионов долларов. Можем ли мы доверять данным на ее портале до 21 года?
Понравилось? Ставь 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
1.5 минуты моего питчинга на английском
Скидываю свой кусочек с ошибками и as is, какгрится)
Прошла практикум от AgileFluent по бизнес-английскому, который купила за тысяч 25 и прошла все от корки до корки. Что я могу сказать?
🔥 Очень круто тьюторы погружали нас в рабочие ситуации на английском. У нас был учебный кейс, мы брейнштормили, проводили кастевы, формулировали Jobs to be done и гипотезы. Прям погружает. Особенно понравилось, как собрались матерые продакты и долго пытались бесится - а юнит экономику считал вообще кто нибудь?)))
🔥Курс не только прокачивает предметный словарный запас, но и учит вежливым формулировкам. Я когда была на тренингах по скраму заметила, что наших ребят сразу видно. Мы какие то прямолинейные и жесткие. Я это прям почувствовала. Бизнес-практикум очень хорошо фокусируются на сглаживании и вежливой коммуникации.
🔥 В конце, собрав все что было сделано на практикумах, мы сделали презентацию и пропитчили свою идею типо стекхолдерам. В их качестве выступили продакты, которые уже работают на зарубежные компании и хорошо владеют языком. Очень интересный опыт я вам скажу)
🔥 Я была в восторге от обратной связи по каждому практикуму. Я скриншотах приложила, посмотрите. Это только наверно треть от написанного, больше не поместилось. Сидит второй тьютор и слушает каждого, а потом строчит фидбэк
Чего не хватило?
🤬 Финансовых терминов. Мы не касались метрик, Unit - экономики и Pnl. Жду вторую часть)
🤬 Разрозненная по уровню группа. Кто-то говорит бегло, а кто то 3 минуты собирается с мыслью.
❗️Для многих айтишников языковой барьер и недостаток бизнес-лексики — препятствие к офферу, ведь работа предполагает общение и коммуникацию.
Если вам не достает практики, то приходите на бесплатную онлайн-встречу AgileFluent 9 августа в 19:00.
На встрече тьютор расскажет, как брейнштормить, кастдевить и тестировать гипотезы на английском языке. А еще обсудят каких знаний вам не хватает для работы в международной компании.
Встреча будет полезна всем IT-специалистам.
Записывайтесь по ссылке 🙂
Скидываю свой кусочек с ошибками и as is, какгрится)
Прошла практикум от AgileFluent по бизнес-английскому, который купила за тысяч 25 и прошла все от корки до корки. Что я могу сказать?
🔥 Очень круто тьюторы погружали нас в рабочие ситуации на английском. У нас был учебный кейс, мы брейнштормили, проводили кастевы, формулировали Jobs to be done и гипотезы. Прям погружает. Особенно понравилось, как собрались матерые продакты и долго пытались бесится - а юнит экономику считал вообще кто нибудь?)))
🔥Курс не только прокачивает предметный словарный запас, но и учит вежливым формулировкам. Я когда была на тренингах по скраму заметила, что наших ребят сразу видно. Мы какие то прямолинейные и жесткие. Я это прям почувствовала. Бизнес-практикум очень хорошо фокусируются на сглаживании и вежливой коммуникации.
🔥 В конце, собрав все что было сделано на практикумах, мы сделали презентацию и пропитчили свою идею типо стекхолдерам. В их качестве выступили продакты, которые уже работают на зарубежные компании и хорошо владеют языком. Очень интересный опыт я вам скажу)
🔥 Я была в восторге от обратной связи по каждому практикуму. Я скриншотах приложила, посмотрите. Это только наверно треть от написанного, больше не поместилось. Сидит второй тьютор и слушает каждого, а потом строчит фидбэк
Чего не хватило?
❗️Для многих айтишников языковой барьер и недостаток бизнес-лексики — препятствие к офферу, ведь работа предполагает общение и коммуникацию.
Если вам не достает практики, то приходите на бесплатную онлайн-встречу AgileFluent 9 августа в 19:00.
На встрече тьютор расскажет, как брейнштормить, кастдевить и тестировать гипотезы на английском языке. А еще обсудят каких знаний вам не хватает для работы в международной компании.
Встреча будет полезна всем IT-специалистам.
Записывайтесь по ссылке 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Сustomer девелопьменьть😮
Несколько лет назад, когда я начинала в управлении и создании продуктов, я слушала продвинутых коллег и все говорили о кастдеве, как о чем-то важном и обязательном.
Потом я проводила много коридорок, кастдевов и просто разговоров с пользователями.
Когда ко мне обращаются за консультацией по запуску продукта, я сразу отправляю "спросить" у своего клиента и "поговорить" с ним.
🥶 НО... я чувствовала какой-то подвох.
Поймите меня правильно. Я не отказываюсь от своих слов. Говорить с клиентами нужно. Кастдев, сам по себе, если его проводить правильно, помогает и значит очень много на старте продукта и в последующем. Но это чувство странное по отношению к кастдеву, я никогда не могла сформулировать.
😃Недавно я встретила пост Валерии Розовой и она, как с языка сняла. Я добавлю своего возмущения на кастдев.
У меня был кейс, когда меня внезапно начала раздражать фраза "ну пользователи хотят, чтобы мы запустили вот этот продукт. На кастеве они постоянно это говорят".
Я понимаю, что есть записи разговоров, что можно провести кастев самому и проверить....но ох уж этот межотрослевой элефант ин зе рум
1. Кастдевами спекулируют по разным причинам (продвигать свои интересы, просто, что то сказать, чтобы скрыть косяки и вообще много для чего)
2. Кастдевы реально сложно проводить. Заебисто и сложно. Каждый раз продумывая сценарии я ухожу в дебри, либо в детали и постоянно вынуждена возвращать себя к сути и гипотезам. Проводить их - это не просто вопросики позадавать. Это реально лидировать диалог и следить за тем, что "между строк"
У меня один коллега проводил опросы по телефону ориентированные на массовость и называл это качественными интервью. Но это не кастдев. Это опросы!
Другой коллега продумывает сценарии, а сами интервью делегирует своим миньонам помошникам. Это точно про качественные исследования?
😮 Есть ли у вас реальные люди, курсы, книги, которые прям боженьки кастева? Сдавайте явки пароли в комментариях)
Несколько лет назад, когда я начинала в управлении и создании продуктов, я слушала продвинутых коллег и все говорили о кастдеве, как о чем-то важном и обязательном.
Потом я проводила много коридорок, кастдевов и просто разговоров с пользователями.
Когда ко мне обращаются за консультацией по запуску продукта, я сразу отправляю "спросить" у своего клиента и "поговорить" с ним.
Поймите меня правильно. Я не отказываюсь от своих слов. Говорить с клиентами нужно. Кастдев, сам по себе, если его проводить правильно, помогает и значит очень много на старте продукта и в последующем. Но это чувство странное по отношению к кастдеву, я никогда не могла сформулировать.
😃Недавно я встретила пост Валерии Розовой и она, как с языка сняла. Я добавлю своего возмущения на кастдев.
У меня был кейс, когда меня внезапно начала раздражать фраза "ну пользователи хотят, чтобы мы запустили вот этот продукт. На кастеве они постоянно это говорят".
Я понимаю, что есть записи разговоров, что можно провести кастев самому и проверить....но ох уж этот межотрослевой элефант ин зе рум
1. Кастдевами спекулируют по разным причинам (продвигать свои интересы, просто, что то сказать, чтобы скрыть косяки и вообще много для чего)
2. Кастдевы реально сложно проводить. Заебисто и сложно. Каждый раз продумывая сценарии я ухожу в дебри, либо в детали и постоянно вынуждена возвращать себя к сути и гипотезам. Проводить их - это не просто вопросики позадавать. Это реально лидировать диалог и следить за тем, что "между строк"
У меня один коллега проводил опросы по телефону ориентированные на массовость и называл это качественными интервью. Но это не кастдев. Это опросы!
Другой коллега продумывает сценарии, а сами интервью делегирует своим миньонам помошникам. Это точно про качественные исследования?
Please open Telegram to view this post
VIEW IN TELEGRAM
Как эффективно работать с продуктовым дизайнером
Я люблю дизайнеров. Они почти из любого говна и полета фантазий могут сделать конфетку.
У меня в запасе есть несколько штук и я постоянно к ним обращаюсь.
Продуктовый дизайнер - это не "художник, который так видит". Это очень, как правило, системный взгляд. Это про распутывание проблем и изучение поведения клиента.
Как я работаю с дизайнером
1. Мыслить бизнес задачами и проблемами
Найти решение проблемы - задача дизайнера. Не нужно думать за него, как клиентам находить ту или иную кнопку, как она должна выглядеть и где ее размещать. Ваша задача обозначить проблему.
Например, нам нужно внедрить такую-то функцию в такой то блок, чтобы клиенты делали то или то.
Если вы будете думать за дизайнера, то это не будет эффективно. Это ограничивает дизайнера и вас. На основе насмотренности и опыта вероятно он найдет решение покруче и лаконичнее.
2. Дизайнера я подключаю на старте. Это практически всегда самый первый человек, с которым мы работаем. Это сокращает время в будущем на всех этапах. Как минимум фронтенд на старте работы у вас спросит "а как это будет выглядеть?".
3. Референсы. Они хороши, когда продукт совсем на старте. Когда продукт уже есть и вы что-то допиливаете, смотри пункт 2.
Ребята из DevCrowd проводят исследование продуктовых дизайнеров:
- Какие навыки для продуктовых дизайнеров самые важные
- Какие инструменты используются в работе
- Как попадают в профессию и куда из нее уходят
- Полезные для развития каналы, курсы и книги
Проходите опрос, рассказывайте про ваш опыт и помогите сделать исследование максимально охватным. Его результаты будут в открытом доступе, и помогут вам сравнить свои ожидания от продуктовых дизайнеров с рыночными, построить план своего развития, и просто понять, что происходит с индустрией!
👉 Пройти опрос
Я люблю дизайнеров. Они почти из любого говна и полета фантазий могут сделать конфетку.
У меня в запасе есть несколько штук и я постоянно к ним обращаюсь.
Продуктовый дизайнер - это не "художник, который так видит". Это очень, как правило, системный взгляд. Это про распутывание проблем и изучение поведения клиента.
Как я работаю с дизайнером
1. Мыслить бизнес задачами и проблемами
Найти решение проблемы - задача дизайнера. Не нужно думать за него, как клиентам находить ту или иную кнопку, как она должна выглядеть и где ее размещать. Ваша задача обозначить проблему.
Например, нам нужно внедрить такую-то функцию в такой то блок, чтобы клиенты делали то или то.
Если вы будете думать за дизайнера, то это не будет эффективно. Это ограничивает дизайнера и вас. На основе насмотренности и опыта вероятно он найдет решение покруче и лаконичнее.
2. Дизайнера я подключаю на старте. Это практически всегда самый первый человек, с которым мы работаем. Это сокращает время в будущем на всех этапах. Как минимум фронтенд на старте работы у вас спросит "а как это будет выглядеть?".
3. Референсы. Они хороши, когда продукт совсем на старте. Когда продукт уже есть и вы что-то допиливаете, смотри пункт 2.
Ребята из DevCrowd проводят исследование продуктовых дизайнеров:
- Какие навыки для продуктовых дизайнеров самые важные
- Какие инструменты используются в работе
- Как попадают в профессию и куда из нее уходят
- Полезные для развития каналы, курсы и книги
Проходите опрос, рассказывайте про ваш опыт и помогите сделать исследование максимально охватным. Его результаты будут в открытом доступе, и помогут вам сравнить свои ожидания от продуктовых дизайнеров с рыночными, построить план своего развития, и просто понять, что происходит с индустрией!
👉 Пройти опрос
survey.alchemer.eu
Исследование рынка продуктовых дизайнеров, 2023
Исследование рынка продуктовых дизайнеров, 2023.