Принцип как есть программное обеспечение

Невозможность использования программы или как есть

Невозможность использования программы как основание для признания неисполнения правообладателем своих обязательств по договору. Как следствие, предъявление требований о возврате уплаченного и (или) взыскания штрафных санкций. Впрочем, это не единственно возможные претензии.

Наименование суда: Арбитражный суд города Москвы

Номер дела: А40-131571/2012

Дата судебного акта: 19 ноября 2012

Перейдем к делу. Собственно сама фабула.

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

Суд отказал в удовлетворении иска.

Основания.

1) Суд посчитал доказанным, что лицензиар (как лицо, приобретшее права на использование ПО) знал функциональные особенности программы. В качестве доказательств выступили: а) деловая переписка; б) информация с сайта лицензиата; в) презентация лицензиатом в офисе лицензиара программы.

3) Невозможность использования программы Истцом выразилось в невозможности одновременной работы разными группами проектировщиков в рамках одного (единого) проекта. Однако желаемый вариант работы программы не является возможным, исходя из той версии программного обеспечения, права на использования которой были приобретены Истцом. Договор не содержит обязанности лицензиата изменять функционал предоставляемой программы.

Наши размышления.

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

2) Несмотря на то, что не сторонник включать в договор ненужные условия, согласен, что в данном случае наличие условия о применении принципа «как есть» (скажем так) позволило упростить толкование условий, определение правовых последствий и разрешения ситуации.

3) Также хорошо, что на этапе до заключения истцу предоставляли всю информацию о продуктах. Ну и подобному есть доказательства. Не хотелось бы, эксцессов в арбитражном суде с потребительским мышлением о том, что мы не специалисты в данной сфере. Тем не менее, лучше «подстилать», чтобы не больно было падать)

Источник

Принцип «As is» и защита прав покупателя ПО

настоящее время большинство программ в мире продается по принципу «As is» («Как есть»). В результате за проблемы, возникающие в процессе эксплуатации или установки программы, разработчик и распространитель ответственности не несут: они уже сделали все возможное, чтобы таких проблем не возникало. Проще говоря, разработчик программы не отвечает за ее работу. Кажется, что подобное утверждение противоречит здравому смыслу. Однако принцип «As is» — это общепринятое положение в мировой компьютерной практике. Давайте рассмотрим юридическую сторону продажи программ.

Прежде всего, надо отметить, что программное обеспечение (далее ПО) защищено законом об авторском праве (в том числе и от несанкционированного копирования). Этот закон предусматривает сохранение за автором (издателем) программного обеспечения нескольких исключительных прав, одно из которых — право на производство копий программного обеспечения. Таким образом, приобретение программного продукта пользователем — это приобретение лицензии (права) на его использование. Чаще всего это право неэксклюзивное, то есть пользователь не может рассчитывать на единоличное пользование данным программным продуктом.

Итак, лицензия на ПО предоставляет официальное право на использование конкретной программы. Условия лицензии фиксируются в лицензионном соглашении конечного пользователя (End User License Agreement, EULA).

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

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

Многие разработчики ПО используют лицензионное соглашение для ограничения прав потребителя. Разработчик ПО предполагает, что покупатель, приобретая лицензию по принципу «As is», получает программный продукт со всеми имеющимися в нем ошибками и, следовательно, не вправе требовать возмещения ущерба, причиненного его применением. Обычно в подобной лицензии материальная ответственность производителя ограничивается суммой, уплаченной покупателем за программный продукт. Разработчик и распространитель, как правило, не несут ответственности и за утерю пользователем баз данных программы и не производят ее восстановления.

Почему же возможна подобная безответственность? Основной лозунг производителей ПО в настоящее время звучит так: «Невозможно исключить все ошибки из разрабатываемых приложений!» Однако это неверно. Существует множество ПО, функционирующего без ошибок. Более корректно было бы говорить: «Невозможно гарантировать отсутствие ошибок в ПО, поскольку современное ПО очень сложное». Тестирование не позволяет достичь уверенности в отсутствии ошибок, но увеличивает вероятность их выявления.

Утверждение, что гарантий нельзя давать из-за сложности ПО, не выдерживает критики. Современный самолет — устройство со сложнейшим программным и аппаратным обеспечением. Его производитель не может быть уверен, что все ошибки были полностью устранены. Тем не менее производитель самолетов, как правило, берет на себя всю ответственность за качество своей продукции. Ни одна другая технологичная индустрия не полагается исключительно на тестирование. Человечеством накоплен значительный опыт, позволяющий утверждать, что тестирование — это дорогой и не всегда эффективный способ выявления ошибок, в том числе и в приложениях. Для достижения высокого качества товара необходимо уделить особенно пристальное внимание его производству. Разработаны специальные методы улучшения качества производства, позволяющие производить продукты, не содержащие ошибок. При этом производители берут на себя ответственность за их работу, а также все расходы по возмещению ущерба, к которому привело использование их товара. Ситуация в индустрии программ, однако, противоположна описанной. Очень часто ПО поставляется с заведомыми ошибками, за исправление которых деньги затем берут с пользователя. В целом об индустрии ПО сложилось мнение как о выпускающей ненадежную и некачественную продукцию. Типичный аргумент в защиту: «Ведь никто не делает лучше!» в данном случае неубедителен.

Сегодня во многих системах от работы ПО зависит человеческая жизнь. Как насчет ПО для ядерных реакторов, медицинских инструментов, управления безопасностью автомобиля, производства лекарств? Вы согласны с тем, что его производители не будут нести ответственности за работу своих программ? Смертельное лекарство, авария на атомной электростанции по вине разработчика ПО… Неужели в ближайшем будущем все это произойдет? Нет, это реальность настоящего дня! Известен случай, когда в результате ошибок, допущенных при разработке ПО для медицинского прибора, погибли люди, для лечения которых он применялся. Компьютеры и вычислительные устройства все больше вторгаются в нашу жизнь. Мы всё сильнее зависим от программного обеспечения и полагаемся на его надежную работу. Неужели происшествия, связанные с некачественным ПО, должны стать нормой, чтобы мы задумались? Или уже настало время признать, что качество — это неотъемлемая часть ПО? Производители ПО должны нести ответственность за свои продукты. Баги в программах — это не неудобства, а дефекты, которые требуется устранить. Давайте представим себе другой мир, в котором на программах, продаваемых по принципу «As is», имеется яркая наклейка «Производитель данной программы не гарантирует ее корректную работу» или «Использование этого ПО может быть вредно для вашего здоровья». А в выпуске новостей, например, передают сообщение о том, что корпорация «Макрософтвер» отзывает 422 млн. копий своего продукта Home XP из-за проблем с печатью документов и гарантирует покупателям возмещение материального ущерба. Не пора ли нам задуматься над тем, как претворить эти мечты в жизнь?

Источник

Как обеспечить права пользователей

*1 Здесь вполне уместны параллели с вопросом национальной безопасности, которая охватывает не только вопросы защиты от происков внешних и внутренних врагов с применением насильственных методов, но и сферы образования, демографии, здравоохранения и пр.

Правда, тут возникает вопрос: а каково реальное соотношение внешних и внутренних угроз при оценке безопасности ИС? Я вполне допускаю, что уровень опасности различного рода диверсий гораздо выше, но при этом считаю, что практически полное отсутствие публикаций в профессиональной прессе на тему «защита от разработчика» во многом определяется отражением вялой позиции потребителей ИТ (особенно на фоне дискуссий о хакерах, вирусах, спаме и пр., инициируемых при активном участии поставщиков ПО). С учетом всего этого представляется, что вопросы, затронутые в статье Сергея Свинарева «Кому нужен билль о правах» (PC Week/RE, N 31/2004, с. 27), весьма актуальны и требуют конструктивного обсуждения.

Принцип «As Is» остается неизменным

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

*1 Разумеется, речь идет о «коробочных» программных продуктах. В случае же с заказными ПО взаимоотношения между разработчиком и заказчиком определяются конкретным договором между ними.

Казалось бы, можно вспомнить о благословенных временах середины прошлого столетия, когда программы поставлялись только в составе компьютеров. Но тогда не очень понятно, почему потребители (в лице властей США) заставили корпорацию IBM отказаться от этой практики под угрозой судебного преследования?

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

Идея создания «Билля о правах пользователей ПО» (об этом, в частности, говорится в статье «Кому нужен билль о правах») в общем-то не нова, она обсуждается ровно столько, сколько существует софтверная отрасль. И именно эти вопросы лежат в центре внимания целого ряда классических работ 70-х гг. (Э. Дейкстра, Э. Йордан, Ф. Брукс и др.)*1. И хотя тогда данная проблема рассматривалась в основном с точки зрения технологий разработки программ, в них все же была показана вся сложность (фактически невозможность) формального описания такого понятия, как «качественное ПО», которое является пунктом N 1 упомянутого «Билля».

*1Например, актуальные и сегодня рассуждения содержаться в разделе «Что такое хорошая программа и хорошие программисты» книги Э.Иордана «Структурное проектирование и конструирование программ» (М.: Мир, 1979).

Взять хотя бы требование к отсутствию ошибок. Но ведь еще тридцать лет назад Э. Дейкстра сформулировал очевидное положение: «Тест может показать наличие ошибок, но ни один тест не может доказать их отсутствия». А раз так, то понятие «отсутствие ошибок» может быть применено лишь по отношению к конкретному тесту. Но тогда возникает вопрос: кто должен отвечать за полноту и надежность самих тестов?

Не говоря уже о том, что «качество ПО» отнюдь не ограничивается наличием/отсутствием ошибок. К нему нужно отнести еще и удобство пользовательского интерфейса, и масштабируемость, и возможность сопровождения и адаптации, и наличие хорошей (?!) документации и пр. Но вот проблема: сформулировать все эти понятия на уровне четких проверяемых показателей очень и очень сложно.

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

Open Source не решает всех проблем

Казалось бы, многие вопросы качества и сопровождения ПО должна решить идеология открытых исходных кодов (Open Source). Однако в действительности мы видим, что данная модель не дает каких-то радикальных преимуществ по сравнению с «закрытыми» (proprietary) программными продуктами: решая одни проблемы, она порождает другие, не менее сложные.

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

Обсуждать права сторон нужно

После всего сказанного возникает вопрос, нужно ли тогда вообще вести все эти дискуссии о правах пользователя, критериях «хороших» программ и т. д. Конечно нужно!

Вспомним, что именно после предписания суда по антимонопольному иску IBM пришлось сделать компьютеры рыночным товаром: в 1956 г. она перешла от сдачи машин в аренду к их продаже. В 1969-м, уже не дожидаясь судебных разбирательств, корпорация впервые начала продажу техники, программ и услуг в качестве независимых продуктов; тогда ПО впервые стало рыночным товаром. А с начала 90-х годов прошлого столетия под особое наблюдение властей, конкурентов и широкой общественности попали лидеры коалиции Wintel.

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

Во-первых, вполне конкретные наказания все же последовали: только в начале 2004 г. Microsoft выплатила около 500 млн. долл. штрафов, наложенных Европейской комиссией, и 1,6 млрд.рых, что самое главное, эти долгие и юридически сложные разбирательства стали причиной определенной коррекции бизнес-стратегии Microsoft. Внешне это кажется не очень заметным, но повышенное внимание юридических властей к деятельности корпорации сыграло свою роль в успешном формировании таких мощных альтернатив Windows, как Java и Linux.

Мне представляется, что вопросы юридического регулирования развития софтверной отрасли имеют особую актуальность для нашей страны. Именно у нас чиновники под лозунгом обеспечения качества ПО с удовольствием берутся за сертификацию, регистрацию и т. д. (что зачастую имеет прямо противоположный эффект), но при этом не замечают определенных тенденций проявления монополизма в ИТ-сфере.

Источник

Каждый третий россиянин будет сразу удалять предустановленное отечественное ПО

Почти треть жителей России собираются удалить со своих гаджетов предустановленное российское ПО и заменить его на бесплатные (и даже платные) иностранные аналоги. Многие россияне, в особенности мужчины в возрасте до 55 лет, выказывают недоверие софту отечественных разработчиков. Российское ПО, согласно новому закону, ставится на смарт-ТВ, компьютеры, планшеты и смартфоны, и в общей сложности пользователям придется удалять 28 программ.

Российский софт нужен не всем

Россияне не готовы пользоваться российским программным обеспечением (ПО), которое с сегодняшнего дня (1 апреля 2021 г.) будет предустанавливаться на популярные гаджеты в связи с вступлением силу новых норм. Почти треть населения страны (28%), как сообщила CNews компания ESET, считают его некачественным, а 29% собираются удалить его из памяти устройства сразу после покупки.

Закон, предписывающий предустановку российского софта на смартфоны, смарт-ТВ, компьютеры и ноутбуки – это закон №425-ФЗ «О внесении изменения в ст. 4 закона Российской Федерации «О защите прав потребителей»». Президент России Владимир Путин подписал его в декабре 2019 г., и изначально он должен был вступить в силу 1 июля 2020 г. В дальнейшем эту дату переносили несколько раз, и в итоге он заработал 1 апреля 2021 г. В отчете ESET сказано, что 33% опрошенных россиян уверены, что новый закон поможет развитию отечественной ИТ-сферы и обеспечит поддержку разработчикам ПО. 26% участников исследования, напротив, полагают, что нововведение отрицательно повлияет на качество российского софта и на конкуренцию с иностранными утилитами.

Эксперты ESET выяснили, что если 28% россиян видят в российском ПО некачественный продукт, то, 38% считают наоборот. 66% респондентов, участвовавших в опросе компании, не увидели смысла в оценке качества отечественного софта.

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

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

Удалить нельзя оставить

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

Заменить штатный российский софт респонденты чаще всего собираются на бесплатные аналоги от иностранных разработчиков – так поступят 56% участников опроса ESET, выступивших за полное удаление предустановленного ПО, то есть подавляющее большинство. Еще 22% готовы пользоваться платным иностранным ПО, но только не творением отечественных разработчиков. И лишь 9% россиян готовы поддержать российских программистов не только морально, но и материально – они планируют удалить бесплатный предустановленный софт и установить вместо него платное российское ПО.

Решение примут за пользователя

С другой стороны, удалить штатный российский софт со своих гаджетов, даже при наличии такого желания, смогут далеко не все – такой возможности еще до вступления закона в силу лишила владельцев своих смартфонов компания Samsung. CNews писал, что в конце марта 2021 г. она выпустила прошивку для мобильников, в которой появились неудаляемые приложения «Яндекса», притом эта прошивка предназначалась даже для мобильников, которые под действие закона вовсе не попадали.

Представители Samsung пояснили, что появление неудаляемого российского ПО на устройствах компании связано со «сложностями в трактовке нового закона». «Требования вступившего в силу закона уникальные для российского рынка, у индустрии не было еще подобного опыта. Поэтому много вопросов о порядке исполнения требований закона производителем все еще являются предметом острых дискуссий. В процессе подготовительной работы мы пришли к выводу, что предустановка некоторых приложений в режиме «удаляемых» с высокой степенью вероятности может быть расценена как нарушение законодательства», – сказали представители компании.

Другими словами, пока неизвестно, планирует ли Samsung разрешить владельцам своих смартфонов, по итогам IV квартала 2020 г. признанных самыми популярными (почти 36% рынка, согласно IDC) удалять предустановленное российское ПО.

Какой софт придется удалять россиянам

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

Первый раздел включает только лишь офисный софт «Мой офис стандартный. Домашняя версия», притом устанавливать его будут только на лэптопы и десктопы на базе Windows – компьютеры с Linux и macOS под действие нового закона не попали.

Покупателям смарт-ТВ придется потратить время на удаление 11 российских программ: поисковик и «Кинопоиск» компании «Яндекс», Wink («Ростелеком»), ivi, «Первый» («Первый канал»), Оkkо, Morе.tv, Premier, «Смотрим» (ВГТРК), НТВ («Телекомпания НТВ») и Start.

Больше всего российских приложений, целых 16, будет в составе смартфонов и планшетов, за исключением iPhone и iPad – как сообщал CNews, Apple не будет устанавливать их на свои гаджеты. Вместо этого она встроила в прошивку отдельное меню, появляющееся при первом запуске, в котором пользователи смогут самостоятельно выбрать для установки нужные ему отечественные утилиты. При этом ему ничего не помешает полностью отказаться от них.

Источник

Описание бизнес-процессов «Как есть» (AS IS) и «Как должно быть» (TO BE)

Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — AS IS и TO BE. И все авторы писали, что сначала необходимо составить нотацию AS IS (буквальный перевод — «как есть»), т.е. как система работает в настоящее время, и только потом приступать к процессу модернизации, т.е. создавать нотацию TO BE (Как должно быть).

Проще говоря, сначала следует изучить, как работает предприятие или отдел сейчас, сделать описание бизнес процесса, и только потом, на основе нотации AS IS, начинать оптимизацию. Но все эти теории хороши, когда есть что описывать по схеме «Как есть». В реальности ситуация чаще всего иная.

Описывать нечего

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

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

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

Еще ярче, в тех же продажах, заметна разница между действиями при работе с лидами:
— Один менеджер отправит прайс-лист или коммерческое предложение и успокоится на этом.
— Другой сначала позвонит, все уточнит.
— Третий будет добиваться личной встречи даже там, где без нее можно прекрасно обойтись.

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

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

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

Описывать незачем

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

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

Зачем создают нотации AS IS?

Создавать нотации AS IS для себя вы можете, это даже может быть удобно и полезно. В конце концов, графика помогает упорядочить мысли, разобраться точнее лично для себя, что и как происходит. Но в рекомендованной последовательности действий указывается обязательный этап предоставления этой нотации клиенту.

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

Возникает резонный вопрос. А как без описания того, что есть, вы сможете выдать рекомендации, что нужно изменить? Но ведь вы — специалист, эксперт в своей сфере деятельности, вас потому и позвали, что верят, вы разберетесь и сумеете выдать правильный результат.

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

Потому не имеет смысла тратить силы и время на составление полноценной нотации AS IS с сопроводительной документацией, включать этот этап в план работ и т. д. Если ваш клиент не ждет от вас этого этапа в обязательном порядке, что иногда случается в крупном бизнесе или в случаях, когда заказчики тоже читали те самые учебники, предоставляйте сразу решение — TO BE. Вы должны быть на стороне клиента, и давать ему то, что реально нужно. Это подход продуктивности.

Источник