Каждый раз, когда у тебя что-то получается, появляется масса людей, которые говорят, что это получилось благодаря им и их советам. Вот только ты их не слушал и делал по своему.
Кстати, раз уже вы тут все собрались, у меня к вам просьба. Этот канал изначально создан для поддержки моей работы над книгой о продюсировании и проектировании цифровых продуктов. Подход назван Методом параноика, поэтому так называется и телеграм-канал. Если вы здесь недавно, то загляните на ресурс книги. Уже много глав готово и возможно вы найдете для себя что-то интересное. Будут вопросы – пишите напрямую или комментируйте: https://paranoidmethod.org
Если вы уже давно следите за моей работой и прочитали несколько глав, то будет круто, если датите фитбек, а еще круче, если оставите короткую или не очень рецензию на книгу на Литресе. Покупать ее для этого не надо, достаточно зарегистрироваться: https://www.litres.ru/vadim-viktorovich-mi/metod-paranoika-kniga-o-sozdanii-cifrovyh-produktov-v/
Я периодически получаю отклик от разных людей после прочтения и это важно для моей работы над книгой. Поэтому если вы давно хотели высказать свое мнение, но не было повода, то вот он) Пора!
Если вы уже давно следите за моей работой и прочитали несколько глав, то будет круто, если датите фитбек, а еще круче, если оставите короткую или не очень рецензию на книгу на Литресе. Покупать ее для этого не надо, достаточно зарегистрироваться: 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)
Следующие главы будут публиковаться по мере перевода.
В ролях:
– Перевод: Андрей Лучина (@loocheenah)
– Обложка (как и русский вариант): Сергей Гуров (@molokopluss)
Medium
Digital Products in Business
First chapter of The Paranoid Method book (Red)
Итак, рубрика #ответынавопросы ))
Люди все разные и кроме разницы в опыте и профессиональных знаниях, есть отличия в темпераменте и том, как люди мыслят. Одним легко даются абстракции и логические рассуждения, другим важно вначале увидеть образ, который создаст у них представление о предмете.
У нас например, с моим партнером по картелю Пашей Шерером все время споры, показывать на ранних стадиях концепции продукта и проектирования визуальные макеты интерфейса. Паша настаивает на том, что ничего показывать нельзя, потому что клиент «влюбляется» в картинку и потом видит будущий продукт именно таким и не сможет отказаться от него, даже если этого потребует логика проектирования. Я же наоборот, стараюсь дать визуальный образ, чтобы с его помощью обсуждать на ранних стадиях те аспекты проекты, о которых сложно говорить абстрактно.
Я вижу тут две истории. Как строится взаимодействие с клиентом в принципе и что именно мы визуализируем.
Начнём с того, что визуализация идей нужна как раз для того, чтобы у вас с клиентом не было разных представлений о предмете работы. Слова – очень обманчивая вещь, разными людьми одно и то же слово вызывает свой образ. Это примерно, как обсуждать музыку. Пока не послушаешь, ничего не поймёшь, а главное не почувствуешь. Точно также и с обсуждением концепции будущего продукта. Прежде всего нужно понять, насколько вы с клиентом совпадаете на уровне восприятия. Есть ситуации, когда не стоит даже начинать работу, потому что вы разговариваете на разных языках. Чтобы это выяснить, нужно сначала попробовать договориться о самых базовых вещах, прежде всего целях работы.
Кажется просто и примитивно, многим кажется этот вопрос очевидным. И на этом обычно все и обманываются. Любимая фраза в конце проекта «аааа, так вот что вы имели ввиду....». Короче! Вам при знакомстве нужно «сработаться», на практике, обсуждая цели проекта, проверить разные способы обсуждения, с упором на абстрактное или наоборот на конкретное представление. Нужная встречная слепая проверка, когда одно и то же вы попробуете донести двумя разными способами и проверить, одинаково ли понимает клиент, то о чем, вы говорите. Своеобразная калибровка. Может получится так, что на уровне абстракции, например, нам «нужен сайт для взаимодействия с клиентами», вы делаете текстовую схему контентного сайта с возможностью комментирования, а потом показываете набросок, прототип, и только в этот момент клиент говорит «а где витрина товаров?...». Получается ваш текст он даже не считал, а в понятие «взаимодействие с клиентом» вкладывал идею продажи. И тут есть повод подумать над тем, сможете ли вы все идеи обсуждать в том формате, в котором ваш клиент понимает. Возможно для вас это будет сложно, вы другого психотипа и тогда в принципе стоит отказаться от этой работы.
Есть еще один аспект. Терпение. Многие люди настолько убеждены в том, что мир устроен так, как они его представляют в своей голове, что любые попытки обсудить варианты, вызывают у них раздражение. Им кажется, что их собеседник тупой и не видит очевидных вещей. Поэтому если вы с таким человеком не совпали сразу, то ваши попытки с ним установить контакт – будет игра в одни ворота, в которых вы все время будете проигрывать. Стоит также помнить, что таким упёртым человеком можете оказаться вы сами, раздражаясь от того, что клиент не понимает того языка, на котором вы с ним разговариваете. В общем, первоначальная пристрелка позволяет выбрать подходящую схему взаимодействия друг с другом и иногда лучше отказаться от работы. Но бывают и действительно классные совпадения!
Продолжение следует...
Люди все разные и кроме разницы в опыте и профессиональных знаниях, есть отличия в темпераменте и том, как люди мыслят. Одним легко даются абстракции и логические рассуждения, другим важно вначале увидеть образ, который создаст у них представление о предмете.
У нас например, с моим партнером по картелю Пашей Шерером все время споры, показывать на ранних стадиях концепции продукта и проектирования визуальные макеты интерфейса. Паша настаивает на том, что ничего показывать нельзя, потому что клиент «влюбляется» в картинку и потом видит будущий продукт именно таким и не сможет отказаться от него, даже если этого потребует логика проектирования. Я же наоборот, стараюсь дать визуальный образ, чтобы с его помощью обсуждать на ранних стадиях те аспекты проекты, о которых сложно говорить абстрактно.
Я вижу тут две истории. Как строится взаимодействие с клиентом в принципе и что именно мы визуализируем.
Начнём с того, что визуализация идей нужна как раз для того, чтобы у вас с клиентом не было разных представлений о предмете работы. Слова – очень обманчивая вещь, разными людьми одно и то же слово вызывает свой образ. Это примерно, как обсуждать музыку. Пока не послушаешь, ничего не поймёшь, а главное не почувствуешь. Точно также и с обсуждением концепции будущего продукта. Прежде всего нужно понять, насколько вы с клиентом совпадаете на уровне восприятия. Есть ситуации, когда не стоит даже начинать работу, потому что вы разговариваете на разных языках. Чтобы это выяснить, нужно сначала попробовать договориться о самых базовых вещах, прежде всего целях работы.
Кажется просто и примитивно, многим кажется этот вопрос очевидным. И на этом обычно все и обманываются. Любимая фраза в конце проекта «аааа, так вот что вы имели ввиду....». Короче! Вам при знакомстве нужно «сработаться», на практике, обсуждая цели проекта, проверить разные способы обсуждения, с упором на абстрактное или наоборот на конкретное представление. Нужная встречная слепая проверка, когда одно и то же вы попробуете донести двумя разными способами и проверить, одинаково ли понимает клиент, то о чем, вы говорите. Своеобразная калибровка. Может получится так, что на уровне абстракции, например, нам «нужен сайт для взаимодействия с клиентами», вы делаете текстовую схему контентного сайта с возможностью комментирования, а потом показываете набросок, прототип, и только в этот момент клиент говорит «а где витрина товаров?...». Получается ваш текст он даже не считал, а в понятие «взаимодействие с клиентом» вкладывал идею продажи. И тут есть повод подумать над тем, сможете ли вы все идеи обсуждать в том формате, в котором ваш клиент понимает. Возможно для вас это будет сложно, вы другого психотипа и тогда в принципе стоит отказаться от этой работы.
Есть еще один аспект. Терпение. Многие люди настолько убеждены в том, что мир устроен так, как они его представляют в своей голове, что любые попытки обсудить варианты, вызывают у них раздражение. Им кажется, что их собеседник тупой и не видит очевидных вещей. Поэтому если вы с таким человеком не совпали сразу, то ваши попытки с ним установить контакт – будет игра в одни ворота, в которых вы все время будете проигрывать. Стоит также помнить, что таким упёртым человеком можете оказаться вы сами, раздражаясь от того, что клиент не понимает того языка, на котором вы с ним разговариваете. В общем, первоначальная пристрелка позволяет выбрать подходящую схему взаимодействия друг с другом и иногда лучше отказаться от работы. Но бывают и действительно классные совпадения!
Продолжение следует...
Ну и чтобы закончить день на радостной ноте, еще один совет в рубрике #ответынавопросы из области проектных коммуникаций. Внимание! 18+
Когда люди говорят, что написание книги – это создание продукта, они путают издательский бизнес с творческим процессом.
В то же время, если говорить об успешности именно продуктов, то здесь все строго наоборот. Цитата из первой главы:
«Все остальное – удобство использования, охват аудитории, цена обслуживания и прочее – является качественными и количественными характеристиками успеха. Нельзя утверждать, что продукт является хорошим, но не успешным. В его успешности проявляется его качество. Поэтому, когда в следующий раз вам скажут, что они сделали классное мобильное приложение, но были проблемы с запуском для пользователей, это будет означать, что ваши собеседники путают качественное программирование с созданием работающих продуктов.»
«Все остальное – удобство использования, охват аудитории, цена обслуживания и прочее – является качественными и количественными характеристиками успеха. Нельзя утверждать, что продукт является хорошим, но не успешным. В его успешности проявляется его качество. Поэтому, когда в следующий раз вам скажут, что они сделали классное мобильное приложение, но были проблемы с запуском для пользователей, это будет означать, что ваши собеседники путают качественное программирование с созданием работающих продуктов.»
Фрагмент из шестой главы про устройство проектных команд по методу параноика, над которой я сейчас работаю:
"Вы никогда не задавались вопросом, почему самые интересные и удачные решения рождаются на стыке разных дисциплин. Дело в том, что те, кто находит такие решения, обладают контролем над всеми частями создаваемой системы. В большинстве случаев, чтобы получить такой контроль, нужно владеть несколькими компетенциями. Мой любимый пример совсем не из ИТ-области, тем не менее он отлично все показывает.
Представьте себе дизайнера бытовых приборов. Помимо художественных навыков, в его компетенции входит в том числе и знания по технологии производства и свойствам материалов. Спроектировать скажем чайник невозможно без учета того, какие существуют ограничения при литье пластмассы. Да, можно придумать устройство в крайней степени красивое, и возможно даже функциональное, только его нельзя будет изготовить!
Точно также, создавая продукт, если вы замыкаетесь в рамках одной специализации, например, UX, вы не имеете возможность увидеть все части, которые в сумме создают работающую систему. Нужно выйти за границы дисциплины, к которой вы принадлежите в силу своей базовой профессии, чтобы иметь возможности учесть факторы, влияющие на итоговое решение. Поэтому ключевые участники проекта должны обладать опытом в смежных дисциплинах и иметь несколько профессиональных компетенций."
Уже готовые главы тут: https://paranoidmethod.org
"Вы никогда не задавались вопросом, почему самые интересные и удачные решения рождаются на стыке разных дисциплин. Дело в том, что те, кто находит такие решения, обладают контролем над всеми частями создаваемой системы. В большинстве случаев, чтобы получить такой контроль, нужно владеть несколькими компетенциями. Мой любимый пример совсем не из ИТ-области, тем не менее он отлично все показывает.
Представьте себе дизайнера бытовых приборов. Помимо художественных навыков, в его компетенции входит в том числе и знания по технологии производства и свойствам материалов. Спроектировать скажем чайник невозможно без учета того, какие существуют ограничения при литье пластмассы. Да, можно придумать устройство в крайней степени красивое, и возможно даже функциональное, только его нельзя будет изготовить!
Точно также, создавая продукт, если вы замыкаетесь в рамках одной специализации, например, UX, вы не имеете возможность увидеть все части, которые в сумме создают работающую систему. Нужно выйти за границы дисциплины, к которой вы принадлежите в силу своей базовой профессии, чтобы иметь возможности учесть факторы, влияющие на итоговое решение. Поэтому ключевые участники проекта должны обладать опытом в смежных дисциплинах и иметь несколько профессиональных компетенций."
Уже готовые главы тут: https://paranoidmethod.org
Интересно наблюдать, как компании, создающие цифровые инструменты для удаленной работы, сами страдают от карантина и разрозненности проектных команд. А казалось бы...
Стало ясно, что к пятой главе нужно будет вернуться и дополнить ее практическими соображениями о том, как оценивать и планировать работы исходя из идей принципа проектирования. Сейчас там этого нет, а в третьей главе, которая так и называется "Оценка проектов, планирование и другие сложности" больше сказано о причинах проблем, чем о способах их решения. Поэтому между работами над последними главами выберу время и дополню ее: https://paranoidmethod.org/paranoid-method-book-05
Что интересно, для работы над книгой я использую кроме текущих идей, массу накопившихся заметок и материалов. Вот кое-что трехлетней давности по теме Оценка и передача в разработку после проектирования:
– Оценка должна основываться на фактах
– Итогом каждой задачи разработки должен быть результат, который можно “потрогать” (верить никому нельзя, нужны объективные критерии оценки текущего статуса, то, что уже работает — вселяет во всех участников уверенность)
– Разработчики должны понимать сценарии как работает продукт, а не просто логику своей отдельной функции. Им нужно понимать причины проектных решений, а не просто их знать эти конечные решения
– Структура документации должна позволять делать оценку по функциональным разделам и “включать/выключать” пользовательскую функцию из проекта. Это удобно в дальнейшем при общении с клиентом на стадии согласовании бюджета.
Что интересно, для работы над книгой я использую кроме текущих идей, массу накопившихся заметок и материалов. Вот кое-что трехлетней давности по теме Оценка и передача в разработку после проектирования:
– Оценка должна основываться на фактах
– Итогом каждой задачи разработки должен быть результат, который можно “потрогать” (верить никому нельзя, нужны объективные критерии оценки текущего статуса, то, что уже работает — вселяет во всех участников уверенность)
– Разработчики должны понимать сценарии как работает продукт, а не просто логику своей отдельной функции. Им нужно понимать причины проектных решений, а не просто их знать эти конечные решения
– Структура документации должна позволять делать оценку по функциональным разделам и “включать/выключать” пользовательскую функцию из проекта. Это удобно в дальнейшем при общении с клиентом на стадии согласовании бюджета.
Мне важно про вас кое-что понять. Вам знакомо и понятно выражение "по гамбурскому счету"? Обещаю потом раскрыть тему.
Final Results
21%
Да
79%
Нет
Договорные соревнования были всегда. Популярный бокс в конце 19 начале 20 века тоже этого не избежал. Подозреваю, что это было похоже на современный реслинг по сути. Короче, зарабатывать деньги – это одно, а профессиональное достоинство – другое. Уверен, вы по своей работе понимаете, что оценить по достинству крутость результата вашей работы могут только ваши коллеги по цеху, т.е. другие профессионалы, прошедшие долгий путь и от того понимающие всю тонкость игры. Обычный обыватель не даст и копейки за то, над чем вы могли работать долгое время и что считаете своим шедевром.
Бокс – такое же мастерство, поэтому периодически профессионалы собирались в Гамбурге за закрытыми дверьми, чтобы выяснить, кто чего стоит на самом деле. Еще раз, оценить могли только те, кто в этом разбирается по факту, т.е. другие боксеры. Отсюда появилось выражение "по гамбургскому счету", означающее настоящее положение дел.
Бокс – такое же мастерство, поэтому периодически профессионалы собирались в Гамбурге за закрытыми дверьми, чтобы выяснить, кто чего стоит на самом деле. Еще раз, оценить могли только те, кто в этом разбирается по факту, т.е. другие боксеры. Отсюда появилось выражение "по гамбургскому счету", означающее настоящее положение дел.
Прочитал у кого-то в канале, что лучший способ увеличить количество подписчиков, это ничего не писать. Надо попробовать...
Если что-то и заставляет людей быть более ответственными и вовлечёнными при управлении бизнесом, так это разделение убытков. Разделение прибылей делает из них просто привилегированных сотрудников.
Как так случилось, что в современном мире здравый смысл стал контркультурой?