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

p.s. Надеюсь никого этим не обижу)

Цитата:

"Во-вторых, понимание того, чем на самом деле является проектирование, не сильно распространено даже в профессиональной среде, не говоря уже о представителях бизнеса. Это выражается в доминировании двух противоположных подходов к проектированию. Один из них — глубокий инженерный, доставшийся нам по наследству от разработчиков комплексных корпоративных систем. Его сила одновременно является и его слабостью. Сложные для понимания абстракции, уходящие в горизонт спецификации, непереводимые на обычный язык термины, академический снобизм специалистов и слабая привязка к практическим задачам бизнеса и пользователей — всё это вместе делает такой подход похожим на современное искусство, когда понять ценность результата, так же как расшифровать содержание, можно только обратившись к дорогому консультанту.

Противоположный подход — упрощение проектирования до дизайна пользовательского интерфейса, того, что принято называть UX. Это стало масс-маркетом в области создания цифровых сервисов, и в представлении большинства непосвященных людей это и есть проектирование. Всё кажется понятным, и создаётся иллюзия, что так могут быть решены все вопросы об устройстве будущего продукта. В результате к этим задачам привлекаются люди без глубоких технических знаний и системного подхода, упускаются важные технические особенности реализации, и всё вместе это отражается на качестве продуктов. Сложные вопросы отдаются на откуп команде разработки в расчёте, что её участникам хватит компетенций и сообразительности в том, как набор схем и картинок превратить в работающий продукт."

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

Серега Гуров (@molokopluss) называет это формой и содержанием, а также способом выяснять степень пластичности. Дизайнер, что с него возьмёшь!))

Профессионалы фокусируются на технике, а мастера – на смысле.

Под главами книги начинают появляться комментарии с правками и вопросами: https://paranoidmethod.org

Это круто, спасибо) Я периодически их смотрю, поэтому если есть какие-то общие вопросы либо замечания/комментарии по отдельным фрагментам книги, велкам

Знаю, знаю, это не по теме, но это канал без темы, так что вопрос. Кто ходил на спектакль ZHOLDAK DREAMS? Если вдруг ходил и вам зашло, то может вы знаете что-то похожее по степени сюра, треша и медитативности. Пишите в комментариях, а то "нужны новые формы" знаете ли

https://bdt.spb.ru/спектакли/zholdak-dreams/

У нас с Сергеем сложился странный симбиоз в профессиональном общении. Вроде бы люди из разных областей, он занимается графическим дизайном, я проектирую цифровые сервисы, но нам интересно вместе разбираться с подходами к тому, как придумывать. Этим летом, еще во время карантина, пока я коротал время в Калининграде, а Сергей спасался от чумы на даче под Питером, мы записали еще один стрим, который получилось смонтировать только сейчас.

https://youtu.be/XQ5k5werwvQ

Мне долго казалось, что бизнес (клиент) вкладывает в проект деньги, а специалисты (исполнители) свои компетенции и усилия. "Вот деньги, дайте нам результат".

Теперь я понимаю, что вкладывать компетенции и усилия должны обе стороны. Клиент является равноправным участником проекта, потому что он обладает недоступным для специалистов знанием о своем бизнесе. И это не просто требования к продукту, которые нужно передать. Работа над проектом как решение уравнения с несколькими переменными, где каждая сторона отвечает за свою X или Y, но решение может быть найдено только совместно.

Бесит, когда на вопрос «вы проектируете?» отвечают «да, у нас есть бизнес-аналитик»

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

Кстати, раз уже вы тут все собрались, у меня к вам просьба. Этот канал изначально создан для поддержки моей работы над книгой о продюсировании и проектировании цифровых продуктов. Подход назван Методом параноика, поэтому так называется и телеграм-канал. Если вы здесь недавно, то загляните на ресурс книги. Уже много глав готово и возможно вы найдете для себя что-то интересное. Будут вопросы – пишите напрямую или комментируйте: https://paranoidmethod.org

Если вы уже давно следите за моей работой и прочитали несколько глав, то будет круто, если датите фитбек, а еще круче, если оставите короткую или не очень рецензию на книгу на Литресе. Покупать ее для этого не надо, достаточно зарегистрироваться: https://www.litres.ru/vadim-viktorovich-mi/metod-paranoika-kniga-o-sozdanii-cifrovyh-produktov-v/

Я периодически получаю отклик от разных людей после прочтения и это важно для моей работы над книгой. Поэтому если вы давно хотели высказать свое мнение, но не было повода, то вот он) Пора!

Знаете, всем лучшим, что у нас есть, мы обязаны людям, которые сказали нам "нет".

Моей, наверно, самой главной претензией к методологиям разработки, является слово «разработка», потому что создание цифровых продуктов ≠ программирование.

Большинство возникающих проблем как раз происходят из-за того, что все остальные активности (анализ, проектирование, дизайн, интеграция, тестирование, обучение, внедрение и т.д.) рассматриваются как вспомогательные, как приставки или суффиксы в слове, но никак не корни.

Будучи сам в прошлом разработчиком, я могу смело сказать, ребята, вы много на себя берёте!

Опубликована первая глава книги в переводе. Если у вас есть англоязычные друзья или коллеги, которым вы хотели показать книгу, теперь ничто вам не помешает: https://mityakin.medium.com/digital-products-in-business-cb1ba0eb1373

Следующие главы будут публиковаться по мере перевода.

В ролях:
– Перевод: Андрей Лучина (@loocheenah)
– Обложка (как и русский вариант): Сергей Гуров (@molokopluss)

Итак, рубрика #ответынавопросы ))

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

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

Я вижу тут две истории. Как строится взаимодействие с клиентом в принципе и что именно мы визуализируем.

Начнём с того, что визуализация идей нужна как раз для того, чтобы у вас с клиентом не было разных представлений о предмете работы. Слова – очень обманчивая вещь, разными людьми одно и то же слово вызывает свой образ. Это примерно, как обсуждать музыку. Пока не послушаешь, ничего не поймёшь, а главное не почувствуешь. Точно также и с обсуждением концепции будущего продукта. Прежде всего нужно понять, насколько вы с клиентом совпадаете на уровне восприятия. Есть ситуации, когда не стоит даже начинать работу, потому что вы разговариваете на разных языках. Чтобы это выяснить, нужно сначала попробовать договориться о самых базовых вещах, прежде всего целях работы.

Кажется просто и примитивно, многим кажется этот вопрос очевидным. И на этом обычно все и обманываются. Любимая фраза в конце проекта «аааа, так вот что вы имели ввиду....». Короче! Вам при знакомстве нужно «сработаться», на практике, обсуждая цели проекта, проверить разные способы обсуждения, с упором на абстрактное или наоборот на конкретное представление. Нужная встречная слепая проверка, когда одно и то же вы попробуете донести двумя разными способами и проверить, одинаково ли понимает клиент, то о чем, вы говорите. Своеобразная калибровка. Может получится так, что на уровне абстракции, например, нам «нужен сайт для взаимодействия с клиентами», вы делаете текстовую схему контентного сайта с возможностью комментирования, а потом показываете набросок, прототип, и только в этот момент клиент говорит «а где витрина товаров?...». Получается ваш текст он даже не считал, а в понятие «взаимодействие с клиентом» вкладывал идею продажи. И тут есть повод подумать над тем, сможете ли вы все идеи обсуждать в том формате, в котором ваш клиент понимает. Возможно для вас это будет сложно, вы другого психотипа и тогда в принципе стоит отказаться от этой работы.

Есть еще один аспект. Терпение. Многие люди настолько убеждены в том, что мир устроен так, как они его представляют в своей голове, что любые попытки обсудить варианты, вызывают у них раздражение. Им кажется, что их собеседник тупой и не видит очевидных вещей. Поэтому если вы с таким человеком не совпали сразу, то ваши попытки с ним установить контакт – будет игра в одни ворота, в которых вы все время будете проигрывать. Стоит также помнить, что таким упёртым человеком можете оказаться вы сами, раздражаясь от того, что клиент не понимает того языка, на котором вы с ним разговариваете. В общем, первоначальная пристрелка позволяет выбрать подходящую схему взаимодействия друг с другом и иногда лучше отказаться от работы. Но бывают и действительно классные совпадения!

Продолжение следует...

Ну и чтобы закончить день на радостной ноте, еще один совет в рубрике #ответынавопросы из области проектных коммуникаций. Внимание! 18+