Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта User Story Mapping

Часть 1. Пользовательская история: https://medium.com/xraizor/b0b0d724d77e

Карта историй создаётся для нового продукта или когда существующий продукт надо частично или полностью переделать, и требуется описать объём имеющейся функциональности.

На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Хорошо, если есть картирование процессов в форматах Customer Journey Map или Service Blueprint.

На выходе: набор задач на проектирование и разработку, привязанных к пользовательским историям.

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

Любая пользовательская истории записывается для действующего лица: персоны или функциональной роли в системе. Близкая методика Use Cases лишена эмпатии к человеку, для которого создаётся программа.

Важно:
— Чтобы в истории было и действие, и его ценность для действующего лица;
— Не фиксировать определённый образ достижения полезного действия, чтобы не мыслить готовыми решениями. Избегайте названий интерфейсных элементов и паттернов.

Часть 2. Алгоритм проведения и рекомендации для ведущего: https://medium.com/xraizor/9a90beb2ff57

Часть 3. Чистка историй от ложных требований. Критика метода: https://medium.com/xraizor/2f7bd967a54a

Спрашивали про точки развития для дизайнера.

Спрашивали про точки развития для дизайнера.

Точек роста для дизайнера четыре:

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

— Творческое развитие. Создание индивидуальной творческой траектории независимости и автономной работы. Частный проект в котором дизайнер один на один со своей личной задачей. Создание личного проекта с осознанными и глубокими мотивами самореализации.

— Postdigital. Отказ от цифровых методов создания вещей в пользу любой натуральной, аналоговой технологии создания объектов. Классические методы производства, длительные, основательные, трудоемкие, но развивающие практическое, прикладное мышление.

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

Денис Ломов #1 - о номинации «Агенство года» и процессах.

Креативный директор Red Collar.
http://redcollar.ru/

— Привет, давай начнем. Вы стали первой студией из России, которая выиграла в номинации «Агенство года» по версии CSS Design Awards. Почему так сложилось и что было залогом успеха?

Я сам был удивлен, и до сих пор не могу это осознать. После того, как мы взяли первый «Сайт дня» с нашим сайтом, начали стараться делать на высочайшем уровне для клиентов. И последние 2 года старались не выпускать проходных проектов. В каждый вкладывались по максимуму. За год выиграли 10 наград на CSS Design Awards. Видимо это огромный скачок, и жюри решили что мы достойны называться лучшими в мире по итогам 2017 года.

— Круто ) Что-нибудь изменилось в жизни агенства после?

В жизни агентства пока не знаю, а в моей да. Поскольку это было на праздниках, то после выходных была сложная неделя — меня просто разрывали на всякие интервью, передачи и радио. Ну и вот неделя только закончилась, надеюсь на следующей будет проще. Хочу спокойно поработать 🙂

— Воронеж наверное гордится вами ) А какой может быть твоя следующая цель?

Да, Воронеж гордится! А следующая цель — хочу монетизировать это достижение. Хочу привлекать крупные западные бренды для работы с нами. Ведь когда тебе признали Агентством года, то доверие у клиентов будет больше.

— Желаю удачи! Давай поговорим про процесс. Большинство твоих работ — промо с крутым дизайном и качественной разработкой. Как у тебя происходит процесс поиска дизайн-решения?

Мы собираемся на обсуждение креативной концепции командой, привлекая даже разработчиков. И самое важное, что придумываем концепцию до скетчей и прототипов. Ну а в процессе брейншторма стараемся максимально изящно решить задачу, которая стоит перед сайтом.

— Интересно ) А как ты налаживаешь взаимодействие дизайнеров и разработчиков?
Я пишу в фейсбуке про Creative Frontend Developer. Так вот у нас именно такие. Дизайнер и фронтенд-разработчик совещаются, обсуждают, предлагают решения. Нет такого, что все, что предложил дизайнер должно быть реализовано 1 в 1. От некоторых вещей можно отказаться, а другие изменить. И разработчик часто сам предлагает очень интересные решения, о которых дизайнер и не думал даже. А возможные конфликты между ними решаются арт-директором.

Core Protocols 2

На прошлой неделе я начал писать про Core Protocols и мы посмотрели на список Core Commitments. Если вы пропустили пост и не понимаете, о чем вообще речь, можете вернуться вот к этому посту — https://t.me/designgest/377.

Сегодня хочется перейти к самим протоколам. Но не хочется пересказывать 100% того, что вы и сами можете прочитать в статьях и книжках, а хочется подсветить части протоколов, которые кажутся наиболее интересными.

И первый протокол, о котором хочется поговорить — Check In.

Чек-ин чаще всего используется в начале встречи рабочей группы. Цель чек-ина — в заранее определенной форме поделиться мыслями и эмоциями по поводу ситуации, проекта, задачи с другими членами команды.

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

Чек-ин протокол предлагает простую схему для изложения чувств, он предлагает использовать всего 4 основные эмоции (напишу их на английском, чтобы у вас потом не было путаницы, если пойдете читать книгу):

GLAD (радость)
SAD (грусть)
MAD (бешенство)
AFRAID (испуг).

Ребята выделили именно эти 4 базовые эмоции, потому что считают, что они понимаются всеми однозначно, что снимает вопросы по поводу разного толкования одних и тех же слов разными людьми.

Плюс комбинацией этих базовых эмоций можно получать описание более сложных эмоций. Так например, EXCITEMENT = GLAD + AFRAID.

Стандартные правила для чек-ина следующие:
1) высказывать свои чувства без оценки и цензуры. Можно объяснить причину, по которой вы испытываете конкретные эмоции. Нельзя преуменьшать свои эмоции, говоря, например: «немного грустно».
2) нужно говорить только о своих эмоциях
3) с уважением слушать чек-ины других
4) не обсуждать и не ссылаться на чек-ины других, если нет явного приглашения для этого.

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

Вы можете даже сами с собой зачекиниться прямо сейчас, попытавшись описать свое текущее состояние по поводу вашей работы/проекта/ситуации, выделив те из 4 эмоций, которые испытываете и подумать, почему именно они выделились сейчас.

4 правила хороших видео

Сегодня делюсь кусочком нашей внутренней документации о том, как записывать понятные для коллег видео.

Когда хочется продемонстрировать баг, нужно показать результат работы по задаче, показать как работает интерфейс — лучше говорить, чем писать. Чтобы передать мысль быстро, а не ждать назначенной встречи, мы прибегаем к «лумам» — коротким видео, записанным при помощи https://useloom.com.

Чтобы лум сэкономил время тебе и коллегам — соблюдай простые правила:

— Не молчи. Хороший лум — это не урок из скучного курса, а живой рассказ живого человека. Когда ты молча возишь мышкой по экрану — это понятно только тебе.
— Включи камеру. С живым человеком гораздо приятнее общаться, чем с его экраном. И пофиг, что на фоне любимая рюмочная — живое общение всё компенсирует.
— Не тяни время. Если твое видео можно уместить в минуту — не записывай пятиминутный сериал. Цени время коллег.
— У готового видео обязательно укажи заголовок. Когда твоя проблема называется «HTTP://LOCALHOST:3000», её не очень хочется решать. Клёво — когда тема понятна сразу: «Не отправляется заказ с дробной ценой», «тормозит загрузка картинок» и т.д.

Вопрос: есть команда из трёх человек

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

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

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

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