Не так давно Стивен Синофски (экс-вице-президент подразделения Windows в Microsoft) начал вести свой блог, в котором он делится мыслями о продуктах, продуктовой разработке и управлении.
Мы с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.
Одна из масштабных проблем в создании технологичных продуктов заключается в том, что для вывода продукта или услуги на рынок нужно, чтобы блестящие инженеры добились блестящих результатов — при этом они не могут знать, приведет ли их выбор к успеху или провалу. Это кажется очевидным, но часто такая загвоздка – главный виновник напряжения в команде разработчиков или просто любой группе.
Примечание: Говоря «инженер», под этим мы подразумеваем все специализированные навыки, необходимые для создания продукта, включая разработку, тестирование, дизайн и прочее. Более того, под «продажами» или «маркетингом» мы имеем в виду все специализированные умения, которые требуются для передачи продукта клиентам и его поддержки — это целый спектр навыков и обязанностей, которые крайне важны. Независимо от того, сколько существует специализаций, границы между ролями всегда нечеткие — и это хорошо.
Каждый не-инженер, который хоть раз общался с инженером, знает как сложно (или неприятно) выслушивать, что «что-то возможно, а что-то — нет», или что «это правильно, то бессмысленно, а вот это — глупее некуда». Точно так же и каждому инженеру знакомы неприятности в общении со специалистом по продажам, продавцом, или потребителем, который настаивает на том, что «делать нужно именно так», но не может хоть сколь-нибудь разумно объяснить, почему. Это обычно называют «естественным напряжением» или «организованный баланс сил», влияющих на команду.
Но кому нужно это «организованное напряжение»? Даже когда вы просто делаете, то что должно, вам и без того хватает стресса — зачем добавлять новый, от которого к тому же никак нельзя будет избавиться?
Справиться с этим непросто. Конечно, можно отправить инженеров к потребителям или же заставить «продажников» сидеть на совещаниях по архитектуре, но это смешно и никак не влияет на указанные проблемы и обстоятельства каждой из сторон. На самом деле, простого решения нет, поскольку реальность основана на опыте, культуре, а иногда и временных рамках для разных членов команды разработчиков. Чем принимать естественное напряжение как нечто неизбежное, полагаться на байки или пытаться совместить ДНК команды, можно найти более верный подход.
Если под командой вы понимаете горстку ребят, которые приходят на работу, чтобы каждый день (и ночь!) принимать сложные решения, тогда самым важным для нее будет разделяемое всеми и подробно очерченное представление общего плана продукта. Исторически сложилось так, что планирование софта еще не дозрело до того уровня планирования, на котором оно находится в большинстве других инженерных областей (строительство, транспорт). По большей части это можно считать плюсом — это та самая «мягкая» часть софта, которая делает его разработку юркой, гибкой и способной быстро подстроиться под текущую обстановку. Это сродни тому, как в сфере блогов и социальных медиа переформулировать сообщение о продукте, адресованное клиентам можно гораздо быстрее, чем во времена затянутых сроков разработки и печатной рекламы. Опять же, это и хорошо.
Но, если каждый из подходов в команде увеличивает ее креативность и гибкость, то и хаос не заставит себя долго ждать. И, что еще хуже, если все путается и никак не сходится, начинаются взаимные обвинения. А вкупе с оценкой производительности или операционными собраниями, проблема, возникшая как небольшое разногласие, очень быстро становится камнем преткновения или даже вовсе «политическим вопросом». Иногда поражаешься, как быстро даже те люди, которые искренне были настроены на совместную работу, могут начать страдать от так называемого «естественного напряжения», которое затем превращается в полный разлад в работе.
План того, над чем работает команда, может выглядеть тяжелым и сложным. Может. Но не должен. Другими словами, план — это «основа для принятия решений». Легко создать такой план, который расскажет, каким чудесным будет результат работы, и как чудесно будет делать на нем деньги. Это легкая часть плана.
Еще одна простая часть — перечисление всего, что не будет сделано — чтобы все понимали идею, инвертируя то, что планируется реализовать. Звучит несколько странно. Помню, как впервые узнал о методе намеренного детального описания всего, что не входит в цели проекта. Мне это напомнило разгадывание головоломки — и, возможно, этот специфичный инструмент полезен для некоторых команд разработчиков. Если вы перечислили цели проекта, нужно ли тогда говорить о «не-целях»? То же самое касается ранжирования задач или планов по приоритетам Часто, когда видишь списки задач/целей с приоритетами, непонятно, какие из них будут реализованы (Все обязательные и несколько необязательных? Большинство обязательных? и т.д.). Лучше всего было бы просто перечислить то, что вы обязуетесь действительно выполнить, так как, по большому счету, я не думаю, что хоть кто-то из вас работал над проектами, располагавшими избытком времени или денег!
Сложная же часть в подготовке плана — сформулировать, зачем создается продукт и каким образом он станет успешным. Эта сторона относится к общественным наукам, а у инженеров с ними туго. Вы не можете доказать, что какая-либо разработка будет успешна на рынке, поскольку нет уравнений, которые регулировали бы его поведение. Аналогично, роль технолога — очертить траекторию развития технологий в таком мире, который, возможно, будет отличаться от того, в котором мы сейчас живем, и от той реальности, в которой люди тратят деньги сегодня. Это социальный аспект, который сложен для сотрудников отделов продаж и маркетинга.
Для любого проекта, объем которого выходит за рамки команды из нескольких человек или отличается сложностью, крайне важен первый шаг – сформулировать «как» и «зачем» создается продукт, а не только «что» создается. Реальность такова, что каждый член команды только выигрывает от описания ситуации и мотивации для воплощения проекта. Вооружившись такой информацией, мы получаем основу для принятия решений о том, как реализовать детали проекта, их приоритетности, о том, как продукт будет позиционироваться или продаваться и тому подобное. Удивительно, как часто видишь инженеров, которые точно знают, что именно «нужно» сделать, при этом, не имея хорошо продуманной «истории продукта», то, зачем он создается. Равно, как нередко встречаешь и маркетологов, которые знают, какого рода история будет хорошо продаваться, но не знают, как ее создать. Смысл плана — создать основу, объясняющую «как» и «зачем», но не «что» нужно сделать.
Конечно, все меняется. Писать код сложнее, чем хотелось бы. Конкуренты занимают свободные места. Взгляды клиентов изменяются. Фактически, любой проект будет проходить через фазу пересмотра разделов и изменения деталей плана. Самая неочевидная особенность плана в том, что само его наличие означает, что у вас есть инструменты, чтобы его изменить, совместно, как единая команда. Отсутствие плана создает хаос, взаимные обвинения, уклонение от ответственности, которые мы все хорошо знаем. План не предполагает жесткости, но, как и любой инструмент, он может быть использован некорректно. Есть люди, которые считают, что план – то, что не вырубить топором. Есть так же люди, которые, напротив, думают, что это всего лишь отправная точка и все в нем должно быть подвижно. Разработка продукта — это динамичная система с планами, в которых определены междисциплинарные опорные точки для команды в целом.
При разработке плана имеет смысл учитывать:
При взгляде на эту систему есть три вещи, которые стоит упомянуть.
Во-первых, план — это не первостепенная бизнес-цель, согласно которой нужно «получить N% из Y», где Y — пользователи, деньги или некоторая единица измерения доли (рынка – прим. пер.). Также это и не «прикрутить 5 таких-то фич». Это возможные способы оценки успеха, но не главное в плане. Самое главное в плане — решение проблемы: либо такой, которая возникла из-за недовольства клиентов (сформулированная необходимость) или же такой, которую команда предвидит заранее (несформулированная необходимость).
Во-вторых, план — это продукт командной работы. Даже сама разработка плана требует скоординированных усилий всей команды. Можно сказать, что план – это не «спущенное сверху» (от руководителей к исполнителям) и не «сгенерированное на местах» (краудсорсинг) решение. Планирование – это процесс, скорее, требующий совместных действий «сверху», «снизу» и «из середины». Лучшие планы — те, которые объединяют самые удачные идеи от наиболее широкого круга людей, участвующих в разработке продукта.
В-третьих, может возникнуть соблазн представить план в виде схемы в PowerPoint и сделать на каждый шаг по слайду. Многие планы так и пишутся :-) Единственно верный подход к планированию — это написать план словами, в Word’е, а затем убедиться, что в нем есть последовательность и смысл. Процесс написания плана так же важен, как и сами идеи, изложенные в нем. Возможно, это тема для будущих постов.
Когда у команды возникает общее понимание всех вопросов, изложенных выше, следующий шаг можно сделать вместе. Есть две ключевые части плана, которые сводят всё воедино и помогают соединить «план разработки» и «общественную науку».
Есть много других частей плана — сам бизнес-план, маркетинговый план, PR-план, структура ценообразования, материалы для обучения тех.поддержки и продавцов, операционный и план масштабируемости, тест-план, self-host план и множество других. Все вышесказанное описывает некоторые меры, которые помогут работе всей команды, если принять их до фактического старта проекта. Когда команда входит в резонанс, то многое становится возможным сделать вместе и заранее. Это просто система, созданная для того, чтобы первая же поставленная цель объединяла членов команды на одном и том же этапе работы.
Как бы мы ни хотели, волшебного рецепта не существует. Если бы он был, каждый план составлялся бы по нему и работал идеально. Ни один продукт не разрабатывается повторно, поэтому наша способность сообща экспериментировать и создавать/изменять отдельные образцы продукта — ограничена. Все, что у нас есть это опыт и возможность особо внимательно отнестись к ситуации и существующей реальности при разработке продукта.
P.S. Спасибо, что прочли. Данный пост — первый в этом блоге, учебный процесс. Буду рад обратной связи касательно тона, структуры и подхода к повествованию. Всё это сложные темы, и, возможно, я вижу скорее полутона и нюансы, чем четкий «ответ на вопрос». Дайте мне знать, что вы думаете об этом.
P.P.S. Этот пост общего характера, а не о чем-то конкретном, реализованном в прошлом или настоящем.
Мы с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.
Одна из масштабных проблем в создании технологичных продуктов заключается в том, что для вывода продукта или услуги на рынок нужно, чтобы блестящие инженеры добились блестящих результатов — при этом они не могут знать, приведет ли их выбор к успеху или провалу. Это кажется очевидным, но часто такая загвоздка – главный виновник напряжения в команде разработчиков или просто любой группе.
Примечание: Говоря «инженер», под этим мы подразумеваем все специализированные навыки, необходимые для создания продукта, включая разработку, тестирование, дизайн и прочее. Более того, под «продажами» или «маркетингом» мы имеем в виду все специализированные умения, которые требуются для передачи продукта клиентам и его поддержки — это целый спектр навыков и обязанностей, которые крайне важны. Независимо от того, сколько существует специализаций, границы между ролями всегда нечеткие — и это хорошо.
Естественное напряжение (sic!)
Каждый не-инженер, который хоть раз общался с инженером, знает как сложно (или неприятно) выслушивать, что «что-то возможно, а что-то — нет», или что «это правильно, то бессмысленно, а вот это — глупее некуда». Точно так же и каждому инженеру знакомы неприятности в общении со специалистом по продажам, продавцом, или потребителем, который настаивает на том, что «делать нужно именно так», но не может хоть сколь-нибудь разумно объяснить, почему. Это обычно называют «естественным напряжением» или «организованный баланс сил», влияющих на команду.
Но кому нужно это «организованное напряжение»? Даже когда вы просто делаете, то что должно, вам и без того хватает стресса — зачем добавлять новый, от которого к тому же никак нельзя будет избавиться?
Справиться с этим непросто. Конечно, можно отправить инженеров к потребителям или же заставить «продажников» сидеть на совещаниях по архитектуре, но это смешно и никак не влияет на указанные проблемы и обстоятельства каждой из сторон. На самом деле, простого решения нет, поскольку реальность основана на опыте, культуре, а иногда и временных рамках для разных членов команды разработчиков. Чем принимать естественное напряжение как нечто неизбежное, полагаться на байки или пытаться совместить ДНК команды, можно найти более верный подход.
Если под командой вы понимаете горстку ребят, которые приходят на работу, чтобы каждый день (и ночь!) принимать сложные решения, тогда самым важным для нее будет разделяемое всеми и подробно очерченное представление общего плана продукта. Исторически сложилось так, что планирование софта еще не дозрело до того уровня планирования, на котором оно находится в большинстве других инженерных областей (строительство, транспорт). По большей части это можно считать плюсом — это та самая «мягкая» часть софта, которая делает его разработку юркой, гибкой и способной быстро подстроиться под текущую обстановку. Это сродни тому, как в сфере блогов и социальных медиа переформулировать сообщение о продукте, адресованное клиентам можно гораздо быстрее, чем во времена затянутых сроков разработки и печатной рекламы. Опять же, это и хорошо.
Но, если каждый из подходов в команде увеличивает ее креативность и гибкость, то и хаос не заставит себя долго ждать. И, что еще хуже, если все путается и никак не сходится, начинаются взаимные обвинения. А вкупе с оценкой производительности или операционными собраниями, проблема, возникшая как небольшое разногласие, очень быстро становится камнем преткновения или даже вовсе «политическим вопросом». Иногда поражаешься, как быстро даже те люди, которые искренне были настроены на совместную работу, могут начать страдать от так называемого «естественного напряжения», которое затем превращается в полный разлад в работе.
План того, над чем работает команда, может выглядеть тяжелым и сложным. Может. Но не должен. Другими словами, план — это «основа для принятия решений». Легко создать такой план, который расскажет, каким чудесным будет результат работы, и как чудесно будет делать на нем деньги. Это легкая часть плана.
Еще одна простая часть — перечисление всего, что не будет сделано — чтобы все понимали идею, инвертируя то, что планируется реализовать. Звучит несколько странно. Помню, как впервые узнал о методе намеренного детального описания всего, что не входит в цели проекта. Мне это напомнило разгадывание головоломки — и, возможно, этот специфичный инструмент полезен для некоторых команд разработчиков. Если вы перечислили цели проекта, нужно ли тогда говорить о «не-целях»? То же самое касается ранжирования задач или планов по приоритетам Часто, когда видишь списки задач/целей с приоритетами, непонятно, какие из них будут реализованы (Все обязательные и несколько необязательных? Большинство обязательных? и т.д.). Лучше всего было бы просто перечислить то, что вы обязуетесь действительно выполнить, так как, по большому счету, я не думаю, что хоть кто-то из вас работал над проектами, располагавшими избытком времени или денег!
Сложная же часть в подготовке плана — сформулировать, зачем создается продукт и каким образом он станет успешным. Эта сторона относится к общественным наукам, а у инженеров с ними туго. Вы не можете доказать, что какая-либо разработка будет успешна на рынке, поскольку нет уравнений, которые регулировали бы его поведение. Аналогично, роль технолога — очертить траекторию развития технологий в таком мире, который, возможно, будет отличаться от того, в котором мы сейчас живем, и от той реальности, в которой люди тратят деньги сегодня. Это социальный аспект, который сложен для сотрудников отделов продаж и маркетинга.
Что в плане
Для любого проекта, объем которого выходит за рамки команды из нескольких человек или отличается сложностью, крайне важен первый шаг – сформулировать «как» и «зачем» создается продукт, а не только «что» создается. Реальность такова, что каждый член команды только выигрывает от описания ситуации и мотивации для воплощения проекта. Вооружившись такой информацией, мы получаем основу для принятия решений о том, как реализовать детали проекта, их приоритетности, о том, как продукт будет позиционироваться или продаваться и тому подобное. Удивительно, как часто видишь инженеров, которые точно знают, что именно «нужно» сделать, при этом, не имея хорошо продуманной «истории продукта», то, зачем он создается. Равно, как нередко встречаешь и маркетологов, которые знают, какого рода история будет хорошо продаваться, но не знают, как ее создать. Смысл плана — создать основу, объясняющую «как» и «зачем», но не «что» нужно сделать.
Конечно, все меняется. Писать код сложнее, чем хотелось бы. Конкуренты занимают свободные места. Взгляды клиентов изменяются. Фактически, любой проект будет проходить через фазу пересмотра разделов и изменения деталей плана. Самая неочевидная особенность плана в том, что само его наличие означает, что у вас есть инструменты, чтобы его изменить, совместно, как единая команда. Отсутствие плана создает хаос, взаимные обвинения, уклонение от ответственности, которые мы все хорошо знаем. План не предполагает жесткости, но, как и любой инструмент, он может быть использован некорректно. Есть люди, которые считают, что план – то, что не вырубить топором. Есть так же люди, которые, напротив, думают, что это всего лишь отправная точка и все в нем должно быть подвижно. Разработка продукта — это динамичная система с планами, в которых определены междисциплинарные опорные точки для команды в целом.
При разработке плана имеет смысл учитывать:
- Текущее состояние продукта. Если вы обновляете существующий продукт, то должно быть совместное понимание, как текущий продукт принимается рынком. Каковы его сильные и слабые стороны — как технические, так и с точки зрения бизнеса? Работой над этой частью плана должны заниматься те, кто отвечает за продажи и поддержку текущего продукта.
- Бизнес-возможности. Где потребители тратят деньги? Где бы они хотели их тратить? Для конкурирующих продуктов — как они продаются? В большинстве команд есть люди, которые глубоко понимают способы монетизации и структуру ценообразования для продукта, и именно они должны проработать этот аспект.
- Конкуренция. Всем необходимо понимать конкуренцию. Она не из разряда вещей, которыми можно управлять по наитию, каждый в команде должен знать внутреннюю и внешнюю конкуренцию и постоянно использовать конкурирующие продукты. Многие планы страдают из-за того, что люди поверхностно пробуют продукцию конкурентов и не концентрируются на том, почему именно покупатели могут выбрать именно ее. И не забывайте, что конкуренция может быть «подрывной» и предлагать продукт с «меньшей» функциональностью, но используя другой способ получения денег (иногда и вообще другой схемой бизнеса — прим. пер.). Развитие этой части плана требует командной работы.
- Партнерство. Создание любого технологичного продукта основано на сотрудничестве. Построение платформы, приложения, аппаратных средств или софта требует сотрудничества с разработчиками, производителями «железа», производителями или поставщиками комплектующих, послепродажной установки/поддержки (для корпоративных продуктов) и так далее. Даже такие простые вещи как модель плагинов или API расширяемости должны быть тщательно продуманы, если вы хотите, чтобы они были частью системы решений команды. Данный раздел плана также требует работы всей команды.
- Отраслевые тенденции. Как только команда начинает задумываться о тенденциях в развитии технологий, в ход идет всё, чему учат общественные науки касательно разработки плана. Каковы временные рамки? Какова вероятность того, что тенденция действительно проявится? Какие выгоды/упущения появятся для проекта, если тренд проявится и если нет? Это важные вопросы. Но заранее договориться о том, на каких течениях продукт должен «выплыть», и проговорить это настолько детально, насколько это нужно для понимания всеми членами команды, крайне важно. Вот где вступают в игру нюансы плана. Сегодня в каждом плане можно встретить понятие «мобильный», но вопрос становится гораздо глубже, когда заходит речь о том, как действовать — как это связано с монетизацией, какие будут платформы, зависимость от бразуера — всё это обязательно нужно проговорить.
- Описание успеха. Как выглядит успех? В качестве элемента планирования, иногда полезно объединить всё вышесказанное и написать анонс в блоге (то есть, по сути, пресс-релиз). Поверят ли в это? Как отреагируют конкуренты? Разработчики должны задуматься над тем, что будет для них успехом в отношении одновременных пользователей, транзакций или производительности в дополнение к функциям. Чтобы определить успех, все работают вместе.
- График. Каждый хороший проект начинается с графика. И в большинстве проектов его вскоре пересматривают. В любом планировании настоящей проблемой будет заранее выбрать график, в реальность которого вы искренне верите всей командой, а затем использовать вышеперечисленные меры, чтобы находить компромиссы, которые помогут укладываться в сроки. Распределив объем работы в соответствии с графиком и установив реалистичные сроки, впоследствии вы сможете менять его из-за возникающих непредвиденных обстоятельств, поддерживая нормальное рабочее состояние проекта. Поскольку разработка плана итеративна, график диктуется планом — не нужно брать план, а затем решать, что может не получиться (или сколько времени это займет), как в водопадной модели.
При взгляде на эту систему есть три вещи, которые стоит упомянуть.
Во-первых, план — это не первостепенная бизнес-цель, согласно которой нужно «получить N% из Y», где Y — пользователи, деньги или некоторая единица измерения доли (рынка – прим. пер.). Также это и не «прикрутить 5 таких-то фич». Это возможные способы оценки успеха, но не главное в плане. Самое главное в плане — решение проблемы: либо такой, которая возникла из-за недовольства клиентов (сформулированная необходимость) или же такой, которую команда предвидит заранее (несформулированная необходимость).
Во-вторых, план — это продукт командной работы. Даже сама разработка плана требует скоординированных усилий всей команды. Можно сказать, что план – это не «спущенное сверху» (от руководителей к исполнителям) и не «сгенерированное на местах» (краудсорсинг) решение. Планирование – это процесс, скорее, требующий совместных действий «сверху», «снизу» и «из середины». Лучшие планы — те, которые объединяют самые удачные идеи от наиболее широкого круга людей, участвующих в разработке продукта.
В-третьих, может возникнуть соблазн представить план в виде схемы в PowerPoint и сделать на каждый шаг по слайду. Многие планы так и пишутся :-) Единственно верный подход к планированию — это написать план словами, в Word’е, а затем убедиться, что в нем есть последовательность и смысл. Процесс написания плана так же важен, как и сами идеи, изложенные в нем. Возможно, это тема для будущих постов.
Строим мост
Когда у команды возникает общее понимание всех вопросов, изложенных выше, следующий шаг можно сделать вместе. Есть две ключевые части плана, которые сводят всё воедино и помогают соединить «план разработки» и «общественную науку».
- Крупные ставки. Каждый проект основан на 1-2-х крупных ставках. Это могут быть новые технологии, представляющие качественный скачок по сравнению с прошлым, или же новые области продуктов. Такие цели – это нечто большее, чем просто «плановое улучшение» (относительно собственной предыдущей версии или конкурирующего продукта из той же области). Заранее детально описать их очень полезно, т.к. это будет означать, что это единственные крупные цели, которые вы ставите перед проектом. Крупные ставки, как правило, — неизменная часть плана: план не может существовать без них, и вряд ли в процессе его реализации проекта вы добавите другие масштабные цели. Таким образом, крупные цели – это фундамент, от которого можно будет отталкиваться, принимая в будущем решения относительно проекта. Заманчиво поставить сразу много больших задач, но даже самые крупные проекты не могут иметь больше двух — запомните, что если команда обязуется достичь некоей масштабной цели, она должна во что бы то ни стало это сделать, или, другими словами, суть проекта – в том, чтобы выполнить как следует именно эту задачу.
- План разработки. План разработки можно считать планом реализуемых возможностей («фич»), но лучше понимать его как сценарий действий, рассматриваемый сквозь призму разработки. Если посмотреть на него со стороны отдела продаж или маркетологов, то план разработки должен звучать как «мы решили такие-то проблемы», что можно будет относительно легко превратить в «историю» проекта/услуги или «позиционирование». Неплохо было бы отделить инженерный план от организационной структуры и представить в нем усилия, которые будет принимать вся команда (если это возможно). В наше время даже самое простое приложение состоит из фронтенда/приложения/интерфейса и бэкенда/сервиса/службы и часто над ними тоже работают целые команды (либо отдельные люди). Если цели создания продукта будут сформулированы как совокупность всего, что вы сделаете вместе, а не просто набор отдельных действий, это также поможет объединить план разработки и, в конечном счете, бизнес- и маркетинговую стратегию.
Есть много других частей плана — сам бизнес-план, маркетинговый план, PR-план, структура ценообразования, материалы для обучения тех.поддержки и продавцов, операционный и план масштабируемости, тест-план, self-host план и множество других. Все вышесказанное описывает некоторые меры, которые помогут работе всей команды, если принять их до фактического старта проекта. Когда команда входит в резонанс, то многое становится возможным сделать вместе и заранее. Это просто система, созданная для того, чтобы первая же поставленная цель объединяла членов команды на одном и том же этапе работы.
Как бы мы ни хотели, волшебного рецепта не существует. Если бы он был, каждый план составлялся бы по нему и работал идеально. Ни один продукт не разрабатывается повторно, поэтому наша способность сообща экспериментировать и создавать/изменять отдельные образцы продукта — ограничена. Все, что у нас есть это опыт и возможность особо внимательно отнестись к ситуации и существующей реальности при разработке продукта.
P.S. Спасибо, что прочли. Данный пост — первый в этом блоге, учебный процесс. Буду рад обратной связи касательно тона, структуры и подхода к повествованию. Всё это сложные темы, и, возможно, я вижу скорее полутона и нюансы, чем четкий «ответ на вопрос». Дайте мне знать, что вы думаете об этом.
P.P.S. Этот пост общего характера, а не о чем-то конкретном, реализованном в прошлом или настоящем.
