Знаете, что такое ад для дизайнера?
Нет, это не когда надо рисовать 3 варианта макета одного и того же на выбор.
Нет, это не когда нужно переделывать макеты в ночь перед релизом, потому что менеджер прислал новый брендбук с комик сансом в виде основного шрифта.
И нет, это не когда заказчик отвечает вам на макет, который вы исследовали и строгали 2 недели, «ЭТИ КАРТИНКИ НАРИСОВАЛА БЫ МОЯ СЕКРЕТАРША ЗА 5 МИНУТ»
Нет. Настоящий, сука, ад - это когда твою работу берут и отправляют куда-нибудь в рабочую группу на ОБЩЕЕ ГОЛОСОВАНИЕ. Типа, коллеги, мы не можем выбрать нужный вариант, давайте проголосуем всем миром и выберем лучшее, коллеги. Спасибо, коллеги.
Тем самым дизайнер ставится врастопырку:
1. На профессиональную позицию дизайнера зримо, прилюдно кладут жирный болт - типа, спасибо, вася, что помалевал, дальше мы сами все порешаем.
2. Если все пойдет хорошо и ОБЩЕЕ ГОЛОСОВАНИЕ одобрит макеты дизайнера, то тем самым ему какбе намекают, что, вася, ты сейчас молодец и мы тебя одобрили, но ты смотри… такое не всегда может быть, в следующий раз можешь и не понравиться. Дизайнер чувствует себя во власти толпы.
3. Если все пойдет плохо и ОБЩЕЕ ГОЛОСОВАНИЕ зарубит макеты дизайнера, то тем самым ему какбе выносят вердикт, что ты, вася, не командный игрок, работаешь херово и вообще это тревожный звоночек. Дизайнер чувствует себя говном.
4. И - самое главное - при этом хороший дизайнер задается вопросом: да какого черта?!!
Какого черта эти люди вообще принимают решение, нравится или не нравится дизайн, они не целевая аудитория, они работают в той же компании, они знают его лично (и, например, могут проголосовать против, потому что рожа дизайнерская не понравилась) и вообще не ре-ле-вант-ны? Как вообще можно оценивать дизайн голосованием в почте? Это же, сука, не так делается!
И вот тогда - вот тогда - дизайнер может услышать за спиной перестук копыт, ощутить на своем левом плече когтистую лапу и услышать басовитое: «СЫНОК ДОБРО ПОЖАЛОВАТЬ В АД»
#батинаправда
Нет, это не когда надо рисовать 3 варианта макета одного и того же на выбор.
Нет, это не когда нужно переделывать макеты в ночь перед релизом, потому что менеджер прислал новый брендбук с комик сансом в виде основного шрифта.
И нет, это не когда заказчик отвечает вам на макет, который вы исследовали и строгали 2 недели, «ЭТИ КАРТИНКИ НАРИСОВАЛА БЫ МОЯ СЕКРЕТАРША ЗА 5 МИНУТ»
Нет. Настоящий, сука, ад - это когда твою работу берут и отправляют куда-нибудь в рабочую группу на ОБЩЕЕ ГОЛОСОВАНИЕ. Типа, коллеги, мы не можем выбрать нужный вариант, давайте проголосуем всем миром и выберем лучшее, коллеги. Спасибо, коллеги.
Тем самым дизайнер ставится врастопырку:
1. На профессиональную позицию дизайнера зримо, прилюдно кладут жирный болт - типа, спасибо, вася, что помалевал, дальше мы сами все порешаем.
2. Если все пойдет хорошо и ОБЩЕЕ ГОЛОСОВАНИЕ одобрит макеты дизайнера, то тем самым ему какбе намекают, что, вася, ты сейчас молодец и мы тебя одобрили, но ты смотри… такое не всегда может быть, в следующий раз можешь и не понравиться. Дизайнер чувствует себя во власти толпы.
3. Если все пойдет плохо и ОБЩЕЕ ГОЛОСОВАНИЕ зарубит макеты дизайнера, то тем самым ему какбе выносят вердикт, что ты, вася, не командный игрок, работаешь херово и вообще это тревожный звоночек. Дизайнер чувствует себя говном.
4. И - самое главное - при этом хороший дизайнер задается вопросом: да какого черта?!!
Какого черта эти люди вообще принимают решение, нравится или не нравится дизайн, они не целевая аудитория, они работают в той же компании, они знают его лично (и, например, могут проголосовать против, потому что рожа дизайнерская не понравилась) и вообще не ре-ле-вант-ны? Как вообще можно оценивать дизайн голосованием в почте? Это же, сука, не так делается!
И вот тогда - вот тогда - дизайнер может услышать за спиной перестук копыт, ощутить на своем левом плече когтистую лапу и услышать басовитое: «СЫНОК ДОБРО ПОЖАЛОВАТЬ В АД»
#батинаправда
🔥4
P.S. Еще у нас царская новость - я подключил комментарии к постам. Теперь вы можете рассказывать свои не менее ужасающие истории, я могу не менее ужасающе шутить в ответ, ну и вообще начнем устраивать интерактив. За идею спасибо боярину Кириллу Алексеичу.
Начинать можно с этого поста, всегда-ваш-лёха-коллеги-спасибо-коллеги.
Начинать можно с этого поста, всегда-ваш-лёха-коллеги-спасибо-коллеги.
«ЛЁХА ТЫ РАССКАЗАЛ ПРО АД ДЛЯ ДИЗАЙНЕРА А КАК ПО УМУ ЖИТЬ ТО» - спросили меня дорогие читатели в комментариях.
Нате на лопате 5 правил Лёхи по согласованию дизайна:
🍆 Держите в голове фактор мудака. Если вам попался согласующий мудак, то вам не помогут никакие правила, умные книги и курсы. Поздравляю, вам достался человек-перфоманс, стихийное явление, змея, крокодил, носорог, китобой. Он взорвет вам мозг и заставит плясать под его дуду - только если вы не дернете за один из двух стоп-кранов. Красный стоп-кран предполагает, что вы спасетесь бегством, синий стоп-кран предполагает, что вы выйдете на тех, кто поможет урезонить мудака административными методами - например, начальственным внушением, отстранением его от процесса, ритуальным убийством. Помните, что при этом вы можете наткнуться на новых мудаков и нажить новых друзей.
Других способов - урезонить, уговорить, сломать - не существует. Если вам кто-то будет говорить про то, как он в одиночку победил мудака - он обманывает себя и в реальности мудак победил его.
(не путайте только мудака и въедливого заказчика, но об этой разнице поговорим в отдельном посте)
🍉 Ошибайтесь раньше, ошибайтесь чаще.
Почему не срабатывает тактика «собрали требования-принесли готовый диз через месяц-ушли с мешком денег»? Во-первых, вы можете тупо ошибиться и укопать со своим дизайном не туда вразрез с поставленной задачей. Во-вторых, заказчик мог тупо ошибиться и дать вам неполные или не те вводные (и если вы думаете, что вас в конце спасет победная поза «ДА ВЫ САМИ ТАКИЕ ТРЕБОВАНИЯ ДАЛИ» - нет, она вас не очень спасет). В-третьих, заказчик - зверь хитрый: если ему долго не показывать результаты своего труда, он начинает фантазировать и придумывать в своей голове воздушные замки. Тут его надо регулярно приземлять на прозаическую реальность.
Ошибки на ранних этапах исправляются легко, на поздних этапах это будет очень больно. Попутно формируйте ожидания, чтобы заказчик понимал, когда, где и как вы ему будете показывать - и почему не надо ожидать красот от условной черно-белой схемки.
Дополнительный бонус от частых сверок с клиентом: в какой-то момент он начнет перенимать вашу логику мысли и будет чаще принимать вашу сторону.
🍌 Тащите заказчику только то, что он способен быстро охватить разумом и на основании чего способен принять решение. Первый набросок дизайна от руки, детальный прототип в паре со структурой сайта, скетч, передающий стилистическое решение - ок. Оформление в презентацию - ок. Показ пользовательских сценариев и данных исследований, которые вы закладывали в ваше решение - это охрененный ок.
Тащить каждый набросок дизайна, итерацию кнопки и результаты игры со шрифтами - не ок. Показывать замусоренный файл в фигме (типа, «тут смотрите, а тут не смотрите, это временный набросок…» - я так когда-то с фотографиями Шуфутинского в прототипе прокололся) - тоже не ок. Хорошего заказчика вы утомите, неопытному дадите в руки повод поцепляться за временные мелочи. Помните, что нормальный заказчик не хочет выёривать с вами каждую кнопку по цвету, а хочет убедиться, что вы правильно поняли его задачу и живете в его системе координат.
🍳 Не косячьте на пустом месте. Не ошибаются только мертвые, это нормальная часть творческого процесса - но нет ничего хуже, чем на новой итерации дизайна обнаружить лажу, которую вы обсуждали уже недели три назад. Вы вправе допускать ошибки по незнанию, но не по невнимательности - это плохо и для дизайнера, и для всего процесса.
🍱 Договаривайтесь на берегу о дизайн-процессе - кто, что, когда, каким образом. Чем более структурно и авторитетно вы будете действовать, тем меньше глупых вопросов будет возникать по ходу дела.
Такие вот нехитрые правила. Наверняка их можно придумать еще (ату в комментарии! давайте их собирать!), но конкретно на эти грабли приходилось натыкаться много раз. Фразы «Да вы будете ко мне ходить до скончания века, пока мне не понравится», «Да моя секретарша нарисовала бы это за 15 минут» и «А что тут делает Шуфутинский?» до сих пор эхом звучат в моей голове
#батинаправда
Нате на лопате 5 правил Лёхи по согласованию дизайна:
🍆 Держите в голове фактор мудака. Если вам попался согласующий мудак, то вам не помогут никакие правила, умные книги и курсы. Поздравляю, вам достался человек-перфоманс, стихийное явление, змея, крокодил, носорог, китобой. Он взорвет вам мозг и заставит плясать под его дуду - только если вы не дернете за один из двух стоп-кранов. Красный стоп-кран предполагает, что вы спасетесь бегством, синий стоп-кран предполагает, что вы выйдете на тех, кто поможет урезонить мудака административными методами - например, начальственным внушением, отстранением его от процесса, ритуальным убийством. Помните, что при этом вы можете наткнуться на новых мудаков и нажить новых друзей.
Других способов - урезонить, уговорить, сломать - не существует. Если вам кто-то будет говорить про то, как он в одиночку победил мудака - он обманывает себя и в реальности мудак победил его.
(не путайте только мудака и въедливого заказчика, но об этой разнице поговорим в отдельном посте)
🍉 Ошибайтесь раньше, ошибайтесь чаще.
Почему не срабатывает тактика «собрали требования-принесли готовый диз через месяц-ушли с мешком денег»? Во-первых, вы можете тупо ошибиться и укопать со своим дизайном не туда вразрез с поставленной задачей. Во-вторых, заказчик мог тупо ошибиться и дать вам неполные или не те вводные (и если вы думаете, что вас в конце спасет победная поза «ДА ВЫ САМИ ТАКИЕ ТРЕБОВАНИЯ ДАЛИ» - нет, она вас не очень спасет). В-третьих, заказчик - зверь хитрый: если ему долго не показывать результаты своего труда, он начинает фантазировать и придумывать в своей голове воздушные замки. Тут его надо регулярно приземлять на прозаическую реальность.
Ошибки на ранних этапах исправляются легко, на поздних этапах это будет очень больно. Попутно формируйте ожидания, чтобы заказчик понимал, когда, где и как вы ему будете показывать - и почему не надо ожидать красот от условной черно-белой схемки.
Дополнительный бонус от частых сверок с клиентом: в какой-то момент он начнет перенимать вашу логику мысли и будет чаще принимать вашу сторону.
🍌 Тащите заказчику только то, что он способен быстро охватить разумом и на основании чего способен принять решение. Первый набросок дизайна от руки, детальный прототип в паре со структурой сайта, скетч, передающий стилистическое решение - ок. Оформление в презентацию - ок. Показ пользовательских сценариев и данных исследований, которые вы закладывали в ваше решение - это охрененный ок.
Тащить каждый набросок дизайна, итерацию кнопки и результаты игры со шрифтами - не ок. Показывать замусоренный файл в фигме (типа, «тут смотрите, а тут не смотрите, это временный набросок…» - я так когда-то с фотографиями Шуфутинского в прототипе прокололся) - тоже не ок. Хорошего заказчика вы утомите, неопытному дадите в руки повод поцепляться за временные мелочи. Помните, что нормальный заказчик не хочет выёривать с вами каждую кнопку по цвету, а хочет убедиться, что вы правильно поняли его задачу и живете в его системе координат.
🍳 Не косячьте на пустом месте. Не ошибаются только мертвые, это нормальная часть творческого процесса - но нет ничего хуже, чем на новой итерации дизайна обнаружить лажу, которую вы обсуждали уже недели три назад. Вы вправе допускать ошибки по незнанию, но не по невнимательности - это плохо и для дизайнера, и для всего процесса.
🍱 Договаривайтесь на берегу о дизайн-процессе - кто, что, когда, каким образом. Чем более структурно и авторитетно вы будете действовать, тем меньше глупых вопросов будет возникать по ходу дела.
Такие вот нехитрые правила. Наверняка их можно придумать еще (ату в комментарии! давайте их собирать!), но конкретно на эти грабли приходилось натыкаться много раз. Фразы «Да вы будете ко мне ходить до скончания века, пока мне не понравится», «Да моя секретарша нарисовала бы это за 15 минут» и «А что тут делает Шуфутинский?» до сих пор эхом звучат в моей голове
#батинаправда
Окей, зумеры, поделюсь своей воскресной менеджерской болью.
Есть такая штука - поспринтовая разработка, крайней формой выражения которой является Скрам (или, как выражаются некоторые интересные айтишники, Скрум).
Этот ваш скрум предполагает разработку фиксированными по времени рывками (обычно это 2 недели). В целом логика простая: давайте отберем самые важные задачи, оценим их, договоримся по ним выдать через 2 недели осязаемый, разработанный результат, имеющий клиентскую ценность - и дальше будем сообща фигачить на выполнение этой договоренности.
Скрум - штука религиозная, а потому предполагает набор церемониальных приседаний и ролей, без которых скрум официально перестает быть скрумом, а его участники признаются IT-еретиками. Тут вам и планирование, и ежедневные стендапы, и мудреное мероприятие по причесыванию бэклога (PBR), и подведение итогов спринта (ревью), и клуб анонимных алкоголиков (ретро), и многое другое.
Участники скрума делятся на три категории - это папа римский (т.е. продакт овнер; указывает путь, но не работает), клоун-аниматор (эджайл-коуч, то есть скрам-мастер) и бурлаки (участники команды без разбору, потому что не важна, какая твоя роль - важен результат).
Скрум можно проиллюстрировать вот таким слайдом, который я когда-то собрал для работы:
Есть такая штука - поспринтовая разработка, крайней формой выражения которой является Скрам (или, как выражаются некоторые интересные айтишники, Скрум).
Этот ваш скрум предполагает разработку фиксированными по времени рывками (обычно это 2 недели). В целом логика простая: давайте отберем самые важные задачи, оценим их, договоримся по ним выдать через 2 недели осязаемый, разработанный результат, имеющий клиентскую ценность - и дальше будем сообща фигачить на выполнение этой договоренности.
Скрум - штука религиозная, а потому предполагает набор церемониальных приседаний и ролей, без которых скрум официально перестает быть скрумом, а его участники признаются IT-еретиками. Тут вам и планирование, и ежедневные стендапы, и мудреное мероприятие по причесыванию бэклога (PBR), и подведение итогов спринта (ревью), и клуб анонимных алкоголиков (ретро), и многое другое.
Участники скрума делятся на три категории - это папа римский (т.е. продакт овнер; указывает путь, но не работает), клоун-аниматор (эджайл-коуч, то есть скрам-мастер) и бурлаки (участники команды без разбору, потому что не важна, какая твоя роль - важен результат).
Скрум можно проиллюстрировать вот таким слайдом, который я когда-то собрал для работы:
В теории Скрум выглядит и работает классно, но есть одна беда - в реальных условиях хер ты его запустишь. Кейсов бывает много, например:
👨👨👦👦 У вас нет всех специалистов - например, за аналитикой приходится ходить в отдел аналитики и просить их, чтобы они взяли в работу вашу задачу наподумать. В этом случае принцип «Давайте выберем хотелку из бэклога, возьмемся за руки и выкатим ее первую реализацию через 2 недели» не сработает - придется ждать аналитику от других людей.
🦍 Задача эпически сложная и в прокрустово двухнедельное ложе Скрума не укладывается. Да, я знаю, что апологеты Скрума сейчас начали орать «КАК ЖЕ ТАК ЛЁХА ЛЮБУЮ ЗАДАЧУ МОЖНО ДЕКОМПОЗИРОВАТЬ ДО ЭЛЕМЕНТАРНОГО МИНИМУМА И ЗАПУСКАТЬ ЕГО» - так вот, ни черта подобного. Говорю это как продакт, чье приложение пришлось интегрировать с системой 1982 года выпуска в течение двух, сука, месяцев беспрерывной возни (и это было только начало).
👯♀️ Дизайн херово дружит со Скрумом. В этом убеждался и лично я, и мои любимые деды из Норман-Нильсен групп (см., например, тут: https://www.nngroup.com/articles/ux-agile-backlog). Суть в следующем: работа дизайнера занимает много времени и очень трудно прогнозируема - в самом начале пути сложно сказать, попадем ли мы с первого раза в нашего пользователя и чем закончатся результаты предварительных тестирований прототипов. Нет, конечно, можно крикнуть на дизера «А НУ КА БЕСОВО ОТРОДЬЕ ЧТОБЫ ЧЕРЕЗ НЕДЕЛЮ МАКЕТЫ БЫЛИ У МЕНЯ» - но мы, во-первых, получим лютую херню, а во-вторых - не спасем разработку, потому что дизайн ей нужен не под конец, а в самом начале спринта.
🍄 Возникают вопросы по нагрузке. Берем предыдущий кейс с дизайнером: ну, ок, заставили мы беднягу нарисовать макеты не за неделю даже, а за три дня, а дальше-то что он будет делать? Трогать макет он не может - он в разработке. Скрум-апологеты в этой ситуации не теряются и дают два совета.
Первый - «У НАС ТИ-ШЕЙП И РАЗМАЗАННАЯ КАРТА КОМПЕТЕНЦИЙ ТАК ЧТО В СВОБОДНОЕ ВРЕМЯ ПУСТЬ УЧИТ ВЕРСТКУ ИЛИ ПРОГРАММИРУЕТ» (ага, ехидно отвечу я, конечно - одно удовольствие в мыле рисовать говномакеты, а потом еще подсвинком у программиста пахать).
Второй совет - «А ПУСТЬ ОН ВПРОК МАКЕТЫ ДАЛЬШЕ РИСУЕТ, ИССЛЕДОВАНИЯ ПРОВОДИТ И ТАК ДАЛЕЕ». Но, ребята, вот тут стопэ. На кой хер дизайнера тогда включать в спринт, если он ЗАВЕДОМО будет заниматься не задачами спринта, а какой-то перспективной фигней, проходящей вне церемоний Скрама?
Ответ на этот вопрос - как в целом быть по версии Лёхи - мы дадим в следующей серии. А пока можно всласть посраться в комментариях по поводу того, как на самом деле Скрам прекрасно работает с дизайном, просто мы ололо и у нас пока майндсет не готов (что, конечно, тоже возможно).
#скрумота
👨👨👦👦 У вас нет всех специалистов - например, за аналитикой приходится ходить в отдел аналитики и просить их, чтобы они взяли в работу вашу задачу наподумать. В этом случае принцип «Давайте выберем хотелку из бэклога, возьмемся за руки и выкатим ее первую реализацию через 2 недели» не сработает - придется ждать аналитику от других людей.
🦍 Задача эпически сложная и в прокрустово двухнедельное ложе Скрума не укладывается. Да, я знаю, что апологеты Скрума сейчас начали орать «КАК ЖЕ ТАК ЛЁХА ЛЮБУЮ ЗАДАЧУ МОЖНО ДЕКОМПОЗИРОВАТЬ ДО ЭЛЕМЕНТАРНОГО МИНИМУМА И ЗАПУСКАТЬ ЕГО» - так вот, ни черта подобного. Говорю это как продакт, чье приложение пришлось интегрировать с системой 1982 года выпуска в течение двух, сука, месяцев беспрерывной возни (и это было только начало).
👯♀️ Дизайн херово дружит со Скрумом. В этом убеждался и лично я, и мои любимые деды из Норман-Нильсен групп (см., например, тут: https://www.nngroup.com/articles/ux-agile-backlog). Суть в следующем: работа дизайнера занимает много времени и очень трудно прогнозируема - в самом начале пути сложно сказать, попадем ли мы с первого раза в нашего пользователя и чем закончатся результаты предварительных тестирований прототипов. Нет, конечно, можно крикнуть на дизера «А НУ КА БЕСОВО ОТРОДЬЕ ЧТОБЫ ЧЕРЕЗ НЕДЕЛЮ МАКЕТЫ БЫЛИ У МЕНЯ» - но мы, во-первых, получим лютую херню, а во-вторых - не спасем разработку, потому что дизайн ей нужен не под конец, а в самом начале спринта.
🍄 Возникают вопросы по нагрузке. Берем предыдущий кейс с дизайнером: ну, ок, заставили мы беднягу нарисовать макеты не за неделю даже, а за три дня, а дальше-то что он будет делать? Трогать макет он не может - он в разработке. Скрум-апологеты в этой ситуации не теряются и дают два совета.
Первый - «У НАС ТИ-ШЕЙП И РАЗМАЗАННАЯ КАРТА КОМПЕТЕНЦИЙ ТАК ЧТО В СВОБОДНОЕ ВРЕМЯ ПУСТЬ УЧИТ ВЕРСТКУ ИЛИ ПРОГРАММИРУЕТ» (ага, ехидно отвечу я, конечно - одно удовольствие в мыле рисовать говномакеты, а потом еще подсвинком у программиста пахать).
Второй совет - «А ПУСТЬ ОН ВПРОК МАКЕТЫ ДАЛЬШЕ РИСУЕТ, ИССЛЕДОВАНИЯ ПРОВОДИТ И ТАК ДАЛЕЕ». Но, ребята, вот тут стопэ. На кой хер дизайнера тогда включать в спринт, если он ЗАВЕДОМО будет заниматься не задачами спринта, а какой-то перспективной фигней, проходящей вне церемоний Скрама?
Ответ на этот вопрос - как в целом быть по версии Лёхи - мы дадим в следующей серии. А пока можно всласть посраться в комментариях по поводу того, как на самом деле Скрам прекрасно работает с дизайном, просто мы ололо и у нас пока майндсет не готов (что, конечно, тоже возможно).
#скрумота
👍2
А вот и следующая серия Хуикса!
Видите, я как сериал про Шерлока Холмса (который с Кубмербрджайчем) - каждый сезон выходит раз в столетие. И у этого есть суровая причина: интенсивность моей жарки мыслью напрямую зависит от вдохновения, а оно - от того, насколько мне хорошо на работе. Если мне хорошо - у меня дофига мыслей и спортивной злобы, если мне плохо - то хрен вы меня услышите.
Так что продолжаем, доблестные сэры и сэрки. Сегодня у нас на блюде рассказ, как все-таки можно жить со Скрумом (для освежения памяти рекомендую прочитать мой пост чуть выше).
Вариантов как жить, на самом деле, четыре.
🤡 Вариант первый, пионерский. Вы яростно, как алкаш, хлещете Скрум в чистом виде, натыкаетесь на все подводные камни из предыдущего моего поста, плюетесь, страдаете, не выполняете правил Скрума (хотя отчаянно пытаетесь), катитесь жопой вперед и теряете людей на ходу, но при этом рассказываете рынку, что живете по Скраму. Так можно.
👹 Вариант второй, диссидентский. Вы нахер забиваете на Скрум и укатываетесь в какой-нибудь Канбан, где после жесткача Скрама наслаждаетесь райскими садами, драгоценными коврами и многочисленными гуриями. Там вас тоже может порвать пополам, но про Канбан мы как-нибудь отдельно поговорим.
👽 Вариант третий, задротский. Вы переходите на следующий уровень безумия и начинаете строить суперскрам - что-то наподобие SAFE, LESS и прочего индустриального ада. Тут идите сами читайте.
😻 Вариант четвертый. Я его назову скромно ЛЁХА - не потому, что я его придумал, а потому что он мне нравится; вообще так живут многие. Можете его расшифровывать как Легкий Ёмкий Хромированный Алгоритм. Щас расскажу, в чем его прикол.
Видите, я как сериал про Шерлока Холмса (который с Кубмербрджайчем) - каждый сезон выходит раз в столетие. И у этого есть суровая причина: интенсивность моей жарки мыслью напрямую зависит от вдохновения, а оно - от того, насколько мне хорошо на работе. Если мне хорошо - у меня дофига мыслей и спортивной злобы, если мне плохо - то хрен вы меня услышите.
Так что продолжаем, доблестные сэры и сэрки. Сегодня у нас на блюде рассказ, как все-таки можно жить со Скрумом (для освежения памяти рекомендую прочитать мой пост чуть выше).
Вариантов как жить, на самом деле, четыре.
🤡 Вариант первый, пионерский. Вы яростно, как алкаш, хлещете Скрум в чистом виде, натыкаетесь на все подводные камни из предыдущего моего поста, плюетесь, страдаете, не выполняете правил Скрума (хотя отчаянно пытаетесь), катитесь жопой вперед и теряете людей на ходу, но при этом рассказываете рынку, что живете по Скраму. Так можно.
👹 Вариант второй, диссидентский. Вы нахер забиваете на Скрум и укатываетесь в какой-нибудь Канбан, где после жесткача Скрама наслаждаетесь райскими садами, драгоценными коврами и многочисленными гуриями. Там вас тоже может порвать пополам, но про Канбан мы как-нибудь отдельно поговорим.
👽 Вариант третий, задротский. Вы переходите на следующий уровень безумия и начинаете строить суперскрам - что-то наподобие SAFE, LESS и прочего индустриального ада. Тут идите сами читайте.
😻 Вариант четвертый. Я его назову скромно ЛЁХА - не потому, что я его придумал, а потому что он мне нравится; вообще так живут многие. Можете его расшифровывать как Легкий Ёмкий Хромированный Алгоритм. Щас расскажу, в чем его прикол.
Вариант ЛЁХА строится следующими шагами.
1. Забиваете на пункт из Скрам Гайда, который запрещает вам изменять Скрам. Если что, скажете потом - Лёха разрешил.
2. Разделяете команду на две части - в одну загоняете UXеров, дизайнеров и аналитиков (назовем ее кокетливо Discovery Team), в другую загоняете разработчиков, QA и аналитиков (назовем ее незамысловато Dev Team). Тут вы скажете - Лёха, проснись, ты уже не понимаешь, что сам пишешь - у тебя аналитики сидят и там, и там. Но нет: так надо, слушайте дальше.
Эти две подкоманды будут заниматься радикально разными вещами. Так, Discovery Team возьмет на себя исследовательскую работу, которая сопряжена с большой мерой неопределенности. Она возьмет идею фичи от менеджера и пойдет говорить с бизнесом, пользователями, раскапывать имеющиеся возможности, описывать решение и так далее. Dev Team же будет работать с уже очерченными (и отрисованными!) задачами, вышедшими из-под пера Discovery Team - будет брать в работу постановку и дальше делать свою черную девелоперскую магию.
3. При этом деление между командами должно быть весьма условным - аналитик будет в зависимости от ситуации востребован и там, и там, дизайнер должен быть готов придти на помощь разрабу, а разраб - помочь Discovery Team разобраться с техническими ограничениями новой задачи. Как правило, в такой конструкции больше всего рвет на части аналитиков (ну и продактов, но их и так постоянно рвет на части, служба такая).
4. Пытливый читатель, я думаю, обратил внимание, что Discovery Team и Dev Team отличаются друг от друга степенью рискованности своей работы. Если Discovery работает в режиме «пойди туда не знаю куда, принеси то не знаю что», то Dev Team, в идеале, работает с четко сформулированной задачей, которая, конечно же, может притаить в себе рискованную жопу (кому сейчас легко), но хотя бы на уровне базовых вводных шататься не будет. И в этом есть своя суровая крестьянская правда: разработчики как никто другой ценят определенность, четкость и однозначность, а дизайнеры и исследователи, по долгу работы, не должны пугаться лютой неопределенности.
5. Раз у нас есть две подкоманды с радикально разными ценностями - то и процессы мы им можем дать разные. Следите за руками:
⁃ Discovery Team, вся из себя неопределенная, может работать со своими задачами по Канбану - по сути, постоянному конвейеру задач (который идеально подходит для того, чтобы довести задачи до реализации максимально быстро, насколько позволит неопределенность);
⁃ Dev Team, вся из себя системная и четкая, может работать со своими задачами по Скраму (который идеально подходит для того, чтобы дать команде четкий фронт работ, спрогнозировать результат и не лезть к ним лишний раз с дурацкими изменениями).
6. Иными словами, мы выстраиваем глобальный процесс, при котором канбанный конвейер Discovery Team своим дальним концом упирается в Скрам Dev Team и служит для него постоянно работающим источником задач.
7. Выглядит все это примерно так:
1. Забиваете на пункт из Скрам Гайда, который запрещает вам изменять Скрам. Если что, скажете потом - Лёха разрешил.
2. Разделяете команду на две части - в одну загоняете UXеров, дизайнеров и аналитиков (назовем ее кокетливо Discovery Team), в другую загоняете разработчиков, QA и аналитиков (назовем ее незамысловато Dev Team). Тут вы скажете - Лёха, проснись, ты уже не понимаешь, что сам пишешь - у тебя аналитики сидят и там, и там. Но нет: так надо, слушайте дальше.
Эти две подкоманды будут заниматься радикально разными вещами. Так, Discovery Team возьмет на себя исследовательскую работу, которая сопряжена с большой мерой неопределенности. Она возьмет идею фичи от менеджера и пойдет говорить с бизнесом, пользователями, раскапывать имеющиеся возможности, описывать решение и так далее. Dev Team же будет работать с уже очерченными (и отрисованными!) задачами, вышедшими из-под пера Discovery Team - будет брать в работу постановку и дальше делать свою черную девелоперскую магию.
3. При этом деление между командами должно быть весьма условным - аналитик будет в зависимости от ситуации востребован и там, и там, дизайнер должен быть готов придти на помощь разрабу, а разраб - помочь Discovery Team разобраться с техническими ограничениями новой задачи. Как правило, в такой конструкции больше всего рвет на части аналитиков (ну и продактов, но их и так постоянно рвет на части, служба такая).
4. Пытливый читатель, я думаю, обратил внимание, что Discovery Team и Dev Team отличаются друг от друга степенью рискованности своей работы. Если Discovery работает в режиме «пойди туда не знаю куда, принеси то не знаю что», то Dev Team, в идеале, работает с четко сформулированной задачей, которая, конечно же, может притаить в себе рискованную жопу (кому сейчас легко), но хотя бы на уровне базовых вводных шататься не будет. И в этом есть своя суровая крестьянская правда: разработчики как никто другой ценят определенность, четкость и однозначность, а дизайнеры и исследователи, по долгу работы, не должны пугаться лютой неопределенности.
5. Раз у нас есть две подкоманды с радикально разными ценностями - то и процессы мы им можем дать разные. Следите за руками:
⁃ Discovery Team, вся из себя неопределенная, может работать со своими задачами по Канбану - по сути, постоянному конвейеру задач (который идеально подходит для того, чтобы довести задачи до реализации максимально быстро, насколько позволит неопределенность);
⁃ Dev Team, вся из себя системная и четкая, может работать со своими задачами по Скраму (который идеально подходит для того, чтобы дать команде четкий фронт работ, спрогнозировать результат и не лезть к ним лишний раз с дурацкими изменениями).
6. Иными словами, мы выстраиваем глобальный процесс, при котором канбанный конвейер Discovery Team своим дальним концом упирается в Скрам Dev Team и служит для него постоянно работающим источником задач.
7. Выглядит все это примерно так:
Для особых задротов даже так скажу: мы выстраиваем систему, когда Definition of Done канбанной команды Discovery становится Definition of Ready скрамообразной команды Dev.
В чем плюсы такого подхода:
⁃ Есть стройная производственная схема, соединяющая продуктовую идею на уровне «Ну я хз» с конкретной реализацией;
⁃ Каждый работает в своей комфортной системе координат, никого не надо давить солдатским сапогом и переламывать об колено.
⁃ Если мы что-то можем спрогнозировать - мы это можем спрогнозировать; если где-то должны работать со свистящей неопределенностью - работаем с ней.
⁃ Мы можем масштабироваться и плодить отдельно столько Discovery и Dev-команд, сколько нам нужно.
А вот в чем минусы:
⁃ Управленчески это требует определенной хореографии;
⁃ Есть риск, что команда развалится надвое и будет потеряно горизонтальное общение между Discovery и Dev;
⁃ Аналитиков будет рвать на части. Возможно, вы полечите это разделением на бизнес- и системных аналитиков, а возможно - не полечите.
⁃ Некоторые агиле-коучи будут объявлять вас отступниками и подсылать к вам наемных убийц.
Но вообще - схема рабочая. Так я делал мобильный банк, так я работал над цифровой аптекой, и так я сейчас буду работать на новом продукте. Схема ЛЁХА проверена Лёхой, держите от меня гарантию качества, печать и что там еще вам приложить надо.
Такие дела. Фух, ребята, как же я по вам соскучился.
#скрумота
В чем плюсы такого подхода:
⁃ Есть стройная производственная схема, соединяющая продуктовую идею на уровне «Ну я хз» с конкретной реализацией;
⁃ Каждый работает в своей комфортной системе координат, никого не надо давить солдатским сапогом и переламывать об колено.
⁃ Если мы что-то можем спрогнозировать - мы это можем спрогнозировать; если где-то должны работать со свистящей неопределенностью - работаем с ней.
⁃ Мы можем масштабироваться и плодить отдельно столько Discovery и Dev-команд, сколько нам нужно.
А вот в чем минусы:
⁃ Управленчески это требует определенной хореографии;
⁃ Есть риск, что команда развалится надвое и будет потеряно горизонтальное общение между Discovery и Dev;
⁃ Аналитиков будет рвать на части. Возможно, вы полечите это разделением на бизнес- и системных аналитиков, а возможно - не полечите.
⁃ Некоторые агиле-коучи будут объявлять вас отступниками и подсылать к вам наемных убийц.
Но вообще - схема рабочая. Так я делал мобильный банк, так я работал над цифровой аптекой, и так я сейчас буду работать на новом продукте. Схема ЛЁХА проверена Лёхой, держите от меня гарантию качества, печать и что там еще вам приложить надо.
Такие дела. Фух, ребята, как же я по вам соскучился.
#скрумота
Задали мне недавно вот какой хуикс-вопрос. Дано: у чувака есть сайт, мобильное приложение и два отдельных дизайнера - один отвечает за веб, другой, сталбыть, за мобилу. Каждый из них рисует что-то радикально свое. При этом и сайт, и мобила выполняют одну и ту же функцию - продают товары на одну и ту же аудиторию. То есть продукт, по сути, один.
И вот, спрашивает чувак, нужно ли мне заморачиваться тем, чтобы веб и мобила работали по одним и тем же правилам и выглядели похоже? Или можно дизайнерам все оставить на откуп и НЕ ПЕРЕУБЕЖДАТЬ ИХ ДЕЛАТЬ ЕДИНООБРАЗНО А ТО С НИМИ СПОРИТЬ ТЯЖЕЛО А ОНИ ХУДОЖНИКИ И ТАК ВИДЯТ ПО-РАЗНОМУ?
На последних словах этого вопроса я словил лютый бугурт: мне захотелось выдать таким дизайнерам с сотню шпицрутенов на заднем дворе и отправить на хуикс-галеры куда-нибудь в людоедские страны. Я думаю, у многих из вас уже тоже зачесались кулаки, а для остальных объясню, в чем тут прикол. Пока существуют такие кейсы и бараны-дизайнеры - я буду за это показательно бить.
В UX-дизайне есть несколько принципов, которые будут актуальны во всех продуктах, ситуациях и контекстах - хоть Луна пополам тресни, а они продолжат работать. И одним из таких принципов является консистентность - то бишь единообразие взаимодействия и коммуникации.
Для того, чтобы получше прочувствовать ситуацию, представим, что у вас есть друг Васян. Вы с Васяном классно общаетесь, гуляете, дружите душа в душу и так далее. И вот вы решаете встретиться с Васяном и пишете ему в Телеграм: «ДОРОГОЙ ВАСЯН ГЫГЫГЫ СТАРИК ПОШЛИ ГУЛЯТЬ ДЕРНЕМ ПИВЧАНСКОГО ГЫГЫ ЛЮБЛЮ ТЕБЯ ВСЕЙ ДУШОЙ». А он вам отвечает: «Во-первых, с какого перепугу Вы ко мне обращаетесь на ты, а во-вторых - что за лексикон? Извольте ко Мне обращаться по имени-отчеству и соответственно чину корабельного секретаря, а также запишитесь ко Мне на аудиенцию, послав нарочного казачка с запиской» - и дальше отказывается с вами разговаривать.
Ладно, думаете вы, чорт с тобой, обращаетесь к нему соответственно чину корабельного секретаря, посылаете нарочного и, наконец, договариваетесь о встрече. Предварительно вы решаете контрольно созвониться.
И вот настает день встречи, вы набираете Васяну, говорите «Привет» и начинаете панически решать, как вам к Васяну обращаться - как к ГЫГЫГЫ ВАСЯНУ ЛЮБЛЮ ТЕБЯ ВСЕЙ ДУШОЙ или как к корабельному секретарю. Но Васян сам приходит вам на выручку и молвит скрипучим скучным голосом «Аааа это ты пенёк обоссанный, какая шаболда тебя ко мне занесла, титька ты тараканья? Ты как с дамой общаешься?»
И вот вы мне скажите, дорогие: как вы будете относиться к такому Васяну, с которым вообще не знаешь чего ожидать на каждом этапе коммуникации? Правильно: как к конченому дебилу, от которого надо держаться подальше.
Так отчего же, дорогие мои, мы должны надеяться, что пользователь установит добрые, надежные, предсказуемые отношения с продуктом, если этот продукт ведет себя как непредсказуемая свинья, находящаяся в заложниках у безумных художников?
И как мы должны называть дизайнеров, которые каждый тянет дизайн-одеяло на себя в в ущерб продукта?
Правильно: титьки тараканьи.
#изкрестьянскогобыта
И вот, спрашивает чувак, нужно ли мне заморачиваться тем, чтобы веб и мобила работали по одним и тем же правилам и выглядели похоже? Или можно дизайнерам все оставить на откуп и НЕ ПЕРЕУБЕЖДАТЬ ИХ ДЕЛАТЬ ЕДИНООБРАЗНО А ТО С НИМИ СПОРИТЬ ТЯЖЕЛО А ОНИ ХУДОЖНИКИ И ТАК ВИДЯТ ПО-РАЗНОМУ?
На последних словах этого вопроса я словил лютый бугурт: мне захотелось выдать таким дизайнерам с сотню шпицрутенов на заднем дворе и отправить на хуикс-галеры куда-нибудь в людоедские страны. Я думаю, у многих из вас уже тоже зачесались кулаки, а для остальных объясню, в чем тут прикол. Пока существуют такие кейсы и бараны-дизайнеры - я буду за это показательно бить.
В UX-дизайне есть несколько принципов, которые будут актуальны во всех продуктах, ситуациях и контекстах - хоть Луна пополам тресни, а они продолжат работать. И одним из таких принципов является консистентность - то бишь единообразие взаимодействия и коммуникации.
Для того, чтобы получше прочувствовать ситуацию, представим, что у вас есть друг Васян. Вы с Васяном классно общаетесь, гуляете, дружите душа в душу и так далее. И вот вы решаете встретиться с Васяном и пишете ему в Телеграм: «ДОРОГОЙ ВАСЯН ГЫГЫГЫ СТАРИК ПОШЛИ ГУЛЯТЬ ДЕРНЕМ ПИВЧАНСКОГО ГЫГЫ ЛЮБЛЮ ТЕБЯ ВСЕЙ ДУШОЙ». А он вам отвечает: «Во-первых, с какого перепугу Вы ко мне обращаетесь на ты, а во-вторых - что за лексикон? Извольте ко Мне обращаться по имени-отчеству и соответственно чину корабельного секретаря, а также запишитесь ко Мне на аудиенцию, послав нарочного казачка с запиской» - и дальше отказывается с вами разговаривать.
Ладно, думаете вы, чорт с тобой, обращаетесь к нему соответственно чину корабельного секретаря, посылаете нарочного и, наконец, договариваетесь о встрече. Предварительно вы решаете контрольно созвониться.
И вот настает день встречи, вы набираете Васяну, говорите «Привет» и начинаете панически решать, как вам к Васяну обращаться - как к ГЫГЫГЫ ВАСЯНУ ЛЮБЛЮ ТЕБЯ ВСЕЙ ДУШОЙ или как к корабельному секретарю. Но Васян сам приходит вам на выручку и молвит скрипучим скучным голосом «Аааа это ты пенёк обоссанный, какая шаболда тебя ко мне занесла, титька ты тараканья? Ты как с дамой общаешься?»
И вот вы мне скажите, дорогие: как вы будете относиться к такому Васяну, с которым вообще не знаешь чего ожидать на каждом этапе коммуникации? Правильно: как к конченому дебилу, от которого надо держаться подальше.
Так отчего же, дорогие мои, мы должны надеяться, что пользователь установит добрые, надежные, предсказуемые отношения с продуктом, если этот продукт ведет себя как непредсказуемая свинья, находящаяся в заложниках у безумных художников?
И как мы должны называть дизайнеров, которые каждый тянет дизайн-одеяло на себя в в ущерб продукта?
Правильно: титьки тараканьи.
#изкрестьянскогобыта
👍2
Давно, друзья, к нам не захаживала рубрика БИСКВИТНЫЙ ДВОР, где мы разбираем говнорешения, гоним их, надсмехаемся над ними.
Сегодня у нас в гостях малюсенький кейс-никчемушка от одного зелёного банка - давайте условно называть его Сбербанк.
Кейс простой: мы хотим перевести деньги по номеру телефона. У нас на счету 19 992,04 рубля, мы переводим 19 992 рубля, что может пойти не так?
Сегодня у нас в гостях малюсенький кейс-никчемушка от одного зелёного банка - давайте условно называть его Сбербанк.
Кейс простой: мы хотим перевести деньги по номеру телефона. У нас на счету 19 992,04 рубля, мы переводим 19 992 рубля, что может пойти не так?
Ааа, сука, все может пойти не так. Вы не можете перевести из 19 992,04 рублей 19 992 рубля, потому что 19 992 в загадочной зелёной реальности превышает 19 992,04.
Вы, конечно, можете поправить очки на носу и сказать, что:
⁃ Там наверняка закопана комиссия;
⁃ Срабатывают хитрости округления копеек (на самом деле нет);
⁃ Давно известна лютая ненависть Сбера к переводам по номеру телефона (т.н. СБП), доходящая до анекдотов и маразма, когда функция скрывается за семью экранами, восемью запорами и девятью рычагами, лишь бы не пустить туда пользователя.
Но, Герман Оскарович, я-то тут при чем? Откуда мне знать про комиссию и почему я должен быть заложником неведомой корпоративной херни?
Я вас просто возненавижу, и буду прав. Тут же нарушается сразу два основополагающих принципа, на которых строятся ВСЕ человекоориентированные интерфейсы:
1. Пользователь должен понимать, что произойдёт на следующем шаге (а это я в их божественном интерфейсе не понимаю);
2. Пользователь должен понимать, что только что произошло (этого я тоже не уразумел).
Предупреждений о комиссии нет. Текст ошибки - херовый.
Ну что, я ничегошеньки не понял, взял карточку Тинька и перевёл деньги по-другому. А ещё я сделался зол, и хер я когда-нибудь выберу зелёный банк своим зарплатным проектом - увольте.
#бисквитныйдвор
Вы, конечно, можете поправить очки на носу и сказать, что:
⁃ Там наверняка закопана комиссия;
⁃ Срабатывают хитрости округления копеек (на самом деле нет);
⁃ Давно известна лютая ненависть Сбера к переводам по номеру телефона (т.н. СБП), доходящая до анекдотов и маразма, когда функция скрывается за семью экранами, восемью запорами и девятью рычагами, лишь бы не пустить туда пользователя.
Но, Герман Оскарович, я-то тут при чем? Откуда мне знать про комиссию и почему я должен быть заложником неведомой корпоративной херни?
Я вас просто возненавижу, и буду прав. Тут же нарушается сразу два основополагающих принципа, на которых строятся ВСЕ человекоориентированные интерфейсы:
1. Пользователь должен понимать, что произойдёт на следующем шаге (а это я в их божественном интерфейсе не понимаю);
2. Пользователь должен понимать, что только что произошло (этого я тоже не уразумел).
Предупреждений о комиссии нет. Текст ошибки - херовый.
Ну что, я ничегошеньки не понял, взял карточку Тинька и перевёл деньги по-другому. А ещё я сделался зол, и хер я когда-нибудь выберу зелёный банк своим зарплатным проектом - увольте.
#бисквитныйдвор
Братцы, палю бесплатную годноту.
Если кто-то желал увидеть Того Самого Лёху (т.е. меня) сегодня в прямом эфире, то эта золотая возможность настала: в 18.00 я буду выступать на краснознаменном митапе Epic UX, где буду рассказывать про роли и должности, связанные с UX - с ними творится поистине невероятный терминологический бардак, в который я обожаю кидаться кирпичами и грязью. Сегодня кирпичи и грязь вы сможете увидеть своими глазами.
Запись тоже будет. К слову, на Epic UX выступают и другие, очень годные спикеры: например, дорогой моему сердцу Гриша Коченов из «Агимы», которого слушать - не переслушать, Миша Правдин из Avito и другие. Программа действительно вкусная.
Зарегаться на мероприятие и вообще почитать о происходящем можно тут: https://bit.ly/3AiJUaE
😱😱😱 ВАЖНО! Митап бесплатный + вдовесок организаторы из Epic Growth отсыпают 7 дней бесплатного доступа к своим ресурсам, НО ЕСТЬ НО: если вы не откажетесь за эти 7 дней от подписки, с вас спишутся бабки.
Потом не ругайтесь, что МЕНЯ ЛЁХА НА БАБЛО КИНУЛ Я ЕМУ ДОВЕРЯЛ А ОН СОБАКА ПОГАНАЯ КАПИТАЛИСТИЧЕСКАЯ. Нет, братцы, я не такой, вас за целковый не продаю. Просто будьте внимательны.
#агабесплатнаягоднота
Если кто-то желал увидеть Того Самого Лёху (т.е. меня) сегодня в прямом эфире, то эта золотая возможность настала: в 18.00 я буду выступать на краснознаменном митапе Epic UX, где буду рассказывать про роли и должности, связанные с UX - с ними творится поистине невероятный терминологический бардак, в который я обожаю кидаться кирпичами и грязью. Сегодня кирпичи и грязь вы сможете увидеть своими глазами.
Запись тоже будет. К слову, на Epic UX выступают и другие, очень годные спикеры: например, дорогой моему сердцу Гриша Коченов из «Агимы», которого слушать - не переслушать, Миша Правдин из Avito и другие. Программа действительно вкусная.
Зарегаться на мероприятие и вообще почитать о происходящем можно тут: https://bit.ly/3AiJUaE
😱😱😱 ВАЖНО! Митап бесплатный + вдовесок организаторы из Epic Growth отсыпают 7 дней бесплатного доступа к своим ресурсам, НО ЕСТЬ НО: если вы не откажетесь за эти 7 дней от подписки, с вас спишутся бабки.
Потом не ругайтесь, что МЕНЯ ЛЁХА НА БАБЛО КИНУЛ Я ЕМУ ДОВЕРЯЛ А ОН СОБАКА ПОГАНАЯ КАПИТАЛИСТИЧЕСКАЯ. Нет, братцы, я не такой, вас за целковый не продаю. Просто будьте внимательны.
#агабесплатнаягоднота
Я дизайнер удалой,
@ChastushkiBot
На этом конкурс хуикс-частушек в комментах объявляю открытым.
Редкий случай, когда перед ботом @ChastushkiBot хочется снять шляпу.
UPD. Кто разберется, блин, как в комменты аудиосообщения из бота привешивать - тому ментальный пряник.
Редкий случай, когда перед ботом @ChastushkiBot хочется снять шляпу.
UPD. Кто разберется, блин, как в комменты аудиосообщения из бота привешивать - тому ментальный пряник.
Я юиксом занимался,
@ChastushkiBot
Ладно, хрен с ними, комментами, можете мне в личку присылать, лучшее опубликуем, приз дадим и звание официального хуикс-куплетиста. ЛЁХА РАССТЕГЫВАЙ ГАРМОНЬ
Вот недавно рассказывал на конфе про ЛЮТУЮ ХЕРНЮ, связанную с путаницей названий этих ваших проектировщиков, UI-дизайнеров, UI/UX/CX/HUIX-гуру и, прости господи, CJM- и SJW-экспертов. Как-нибудь соберусь и по итогам презы сбацаю сюда расширенный пост, но пока не буду - не люблю одну мысль дважды подряд думать, уже один раз понервничал, надо отойти.
Вместо этого расскажу вам ПРО ЕЩЕ ОДНУ ЛЮТУЮ ХЕРНЮ - на сей раз в менеджерских названиях (вы же не думали, что только хуикс-специалисты страдают от терминологического бардака)?
ТААК СТЁПКА А НУ-КА ТАЩИ НА ОПЕРАЦИОННЫЙ СТОЛ СЛЕДУЮЩИХ ТОВАРИЩЕЙ:
ЩАС БУДЕМ МНОГОСЛОВНО РЕЗАТЬ!!! ЗАНОСИ ПЕРВОГО ЖМУРА!
Вместо этого расскажу вам ПРО ЕЩЕ ОДНУ ЛЮТУЮ ХЕРНЮ - на сей раз в менеджерских названиях (вы же не думали, что только хуикс-специалисты страдают от терминологического бардака)?
ТААК СТЁПКА А НУ-КА ТАЩИ НА ОПЕРАЦИОННЫЙ СТОЛ СЛЕДУЮЩИХ ТОВАРИЩЕЙ:
• Project Manager• Product Manager• Product Owner• Product Lead.ЩАС БУДЕМ МНОГОСЛОВНО РЕЗАТЬ!!! ЗАНОСИ ПЕРВОГО ЖМУРА!
👍1
Project Manager. С этой ролью проще всего - это страдалец, терпила и средоточие горя, совесть всей отрасли. Гарольд, терпящий боль, Пьеро в бесконечной френдзоне, канонический кум Тыква в карьерном домике из сто восемнадцати выстраданных кирпичей - это все про него.
Project Manager, на бумаге, отвечает за реализацию конкретного проекта - за сроки (коль скоро любой проект когда-то да заканчивается), бюджеты и проектную команду. Типа, предполагается, что проджекту поставили ограниченную во времени и пространстве задачу, он ее с командой разобрал на атомы - и давай фигачить до победного конца. А дальше всё, проект закончен.
На практике же получается, что:
В сухом остатке скажу так: проджект - это отличная школа жизни и полезный навык, но концентрация лютого безумия и крепостного крестьянства там зашкаливает. Если не повезет, вы будете постоянно в позиции, когда вы не можете ничего - и должны всем.
Project Manager, на бумаге, отвечает за реализацию конкретного проекта - за сроки (коль скоро любой проект когда-то да заканчивается), бюджеты и проектную команду. Типа, предполагается, что проджекту поставили ограниченную во времени и пространстве задачу, он ее с командой разобрал на атомы - и давай фигачить до победного конца. А дальше всё, проект закончен.
На практике же получается, что:
• Проджект, будучи стреноженным по рукам и ногам деньгами, сроками и людскими ресурсами, оказывается ответственен за буквально все. Ушел в запой дизайнер? Лидерская проблема проджекта. Заказчик мудак и пересмотрел все договоренности? Коммуникационная проблема проджекта. Продукт, сделанный на основе вводных от заказчика, оказался говном? Стратегическая проблема проджекта. И так далее. Весь проект можно считать одной большой проблемой проджекта;• Поскольку проджект отвечает за проект, на все попытки лезть в стратегию (обсуждать, куда движется продукт, как работает маркетинг, вмешиваться в целеполагание и т.п.) можно делать козью морду и говорить «ДА КУДА ТЫ ЛЕЗЕШЬ ЖОПА ОРЛИНАЯ ИДИ КОМАНДОЙ РУЛИ» - и это сойдет с рук;• Проджект, будучи очень удобной для всех ролью (все его бьют по почкам, а он лишь слабо улыбается и отвечает «коллеги, давайте соберемся и обсудим…»), может скрываться под ЛЮБЫМ другим названием. Вы можете выйти работать аналитиком, разработчиком, дизайнером - а по факту окажетесь несчастным проджектом;• Шик - заманить человека на вакансию продакта (см. ниже), а по факту дать ему роль проджекта. Я с таким сталкивался в жизни неоднократно. Это влияет на личное выгорание примерно так же, как канистра с авиационным керосином - на костер.• Самый лютый пиздец (как вы знаете, я не ругаюсь матом даже в Хуиксе, но тут другого слова не нашлось) - это проджекты во многих агентствах. Это бесправное, вечно страдающее существо, которое должно рулить ожиданиями клиента, собирать от него требования, крутить командой, идиотами-субподрядчиками, разруливать конфликты между людьми на стороне клиента, писать ТЗ, пинать дизайнера за то, что он в очередной раз сделал какаху, вести документооборот, CRM, выцарапывать выплаты, терпеть истерики клиента и собственного руководства и тут не подумайте, что список закончился - я просто устал писать. Я очень сочувствую проджектам на агентской стороне. Вы скалы, парни.В сухом остатке скажу так: проджект - это отличная школа жизни и полезный навык, но концентрация лютого безумия и крепостного крестьянства там зашкаливает. Если не повезет, вы будете постоянно в позиции, когда вы не можете ничего - и должны всем.
❤2👍1🤣1
Product Manager. В теории, с этими ребятами все в порядке. Продакт отвечает за то, чтобы его продукт: а) правильно был придуман и продуман; б) с правильного угла запущен; в) развивался бы и зарабатывал деньги. Некоторые называют продактов бизнесменами без административной нагрузки, и в этом есть своя сермяжная правда.
Тут, впрочем, есть пара своих задниц:
* Продактом хер станешь по щелчку пальцев. В продакта нужно перерастать с уже имеющейся экспертизой - причем чем она ближе к непосредственно разработке, тем круче, поскольку вы глубже будете чувствовать механику продукта. Другой разговор, что менеджерская роль по природе своей близка проджектам - поэтому их среди продактов довольно много. Но мир знает много обратных примеров, когда люди приходили к менеджменту из QA, дизайна, разработки, хуикса (как ваш покорный слуга), да из откуда угодно.
* Я уже писал выше про риск выйти продактом, а оказаться проджектом. Да, так и есть - не все отчетливо понимают, в чем разница между этими понятиями, и вы в итоге со своими стремлениями и законченными продуктовыми курсами окажетесь на позиции подай-принеси-документ-подпиши.
В целом продакт - это удобно, интересно, есть куда развиваться, потолок высоченный - вплоть до Chief Product Officer, заоблачно сидящего где-то наверху, отвечающего за глобальную стратегию и гребущего продуктовые деньги лопатой себе и продукту во благо.
Тут, впрочем, есть пара своих задниц:
* Продактом хер станешь по щелчку пальцев. В продакта нужно перерастать с уже имеющейся экспертизой - причем чем она ближе к непосредственно разработке, тем круче, поскольку вы глубже будете чувствовать механику продукта. Другой разговор, что менеджерская роль по природе своей близка проджектам - поэтому их среди продактов довольно много. Но мир знает много обратных примеров, когда люди приходили к менеджменту из QA, дизайна, разработки, хуикса (как ваш покорный слуга), да из откуда угодно.
* Я уже писал выше про риск выйти продактом, а оказаться проджектом. Да, так и есть - не все отчетливо понимают, в чем разница между этими понятиями, и вы в итоге со своими стремлениями и законченными продуктовыми курсами окажетесь на позиции подай-принеси-документ-подпиши.
В целом продакт - это удобно, интересно, есть куда развиваться, потолок высоченный - вплоть до Chief Product Officer, заоблачно сидящего где-то наверху, отвечающего за глобальную стратегию и гребущего продуктовые деньги лопатой себе и продукту во благо.