Антон Григорьев как всегда сделал хорошую выжимку из новой главы книги

Вадим Митякин опубликовал 5-ю главу книги «Метод параноика» о базовом принципе метода — проектировании.

— Проект требует усилий постоянно. Надо следить за возникающими рисками и вовремя их устранять. Главный противник — неопределённость;
— Без правильной мотивации, которая учитывает их личные цели, люди не могут день за днём быть изобретательными и творческими;
— Метод максимально полезен для проектов типа «Мозги», в которых происходит поиск новых способов использования технологических инструментов в бизнесе;
— Базовый принцип метода — проектирование, то есть продумывание решения до воплощения. Альтернатива — не отсутствие продумывания, а одновременность поиска решения и его воплощения;
— Разделение проектирования и воплощения всего проекта на 2 этапа было бы возвратом к водопадной модели. Вместо этого метод предполагает разделять на 2 этапа отдельные задачи;
— Проблема в том, что те, кто говорят, что делают проектирование, фактически его не делают. Проектирование ≠ UX Design;
— В рамках метода принцип проектирования распространяется на все аспекты проекта: от организационных задач до технических вопросов;
— Проблема традиционного подхода в том, что бизнес перед проектированием плохо формулирует цели, а разработчики игнорируют решения проектировщиков;
— Проектировщики работают с первоначальными требованиями и условиями, которые даёт бизнес (описание бизнес-модели, набор функций, схемы процессов, цели проекта), но в них тоже могут быть ошибки, это скрытая неопределённость;
— Проектирование должно быть фильтром для идей и решений, отсеивающим те, которым не стоит жить и на реализацию которых не стоит тратить ресурсы;
— 3 базовых идеи: 1) Каждое решение в проекте должно уменьшать неопределённость; 2) Каждое решение требует своего уровня абстракции, компетенции и ответственности; 3) Все решения должны быть связаны между собой;
— При проектировании будущего продукта ключевая задача состоит в том, чтобы в принципе разобраться, каковы действительные требования;
— С добавлением компонентов сложность системы возрастает не только за счёт количества новых компонентов, но и за счёт их взаимодействия (новые связи, новые сценарии, затрагивающие несколько компонентов);
— В проекте должен быть тот, кто будет в дальнейшем использовать разрабатываемый продукт;
— Продукт должен быть всегда готов, но с разным уровнем детализации и проработки в зависимости от этапа работ.

https://paranoidmethod.org/paranoid-method-book-05

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