Вы правда думаете, что вопрос «где найти теорию портфельного управления» — это вопрос к тексту стандарта?
Ну а как иначе-то? Представьте заинтересованный читатель, увидев такое, набирает в поисковике название Теории, изучает и приобретает ценные знания в области… управления ценными бумагами.
Или я не понял, ваши Менеджеры имею такой широкий профиль, что хватает и для улыбки соответствующего размера — это ещё и спецы рынка ценных бумаг? Представляю себе такого Менеджера: «Босс, мой проект имеет плохую отдачу в этом квартале… давай сольём оборудование и эти деньги я лучше в ГКО вложу...»
Назвав, стандарт "… в вакууме" я не издевался, а высветил отсутствие базиса и внешних связей стандарта.
Почему создатели «стандарта» позволили себе отвергнуть опыт человечества, которое веками снабжала свои шедевры разделом «Список литературы»?
Это же прописные истины, которые обязательно надо знать всем, и особенно составителям стандартов.
Я вам по секрету скажу, что есть Закон:
"… Участники работ по стандартизации, а также национальные стандарты, предварительные национальные стандарты, общероссийские классификаторы технико-экономической и социальной информации, правила их разработки и применения, правила стандартизации, нормы и рекомендации в области стандартизации, своды правил образуют национальную систему стандартизации.
Было в России две беды. И придумали мудрые люди правила безопасного сосуществования с обоими бедами в 3D пространстве.
Но, МинКомСвязи, осваивая пространство им. Вирта, накликал ещё беду. И теперь, если терпеливо исполнять правило 3Д, то с большой вероятностью мимо неторопливо проплывет… менеджер с какой-нибудь специализацией. И скажет нам мудрец восточный: «Я понимать, у Вас Манагер, как Иванов, многая такая фамилия».
Не могу утверждать точно, но похоже Министерства вовлекли грамотных и образованных специалистов в процесс, имеющий целый ряд системных ошибок. Я так полагаю потому, что в хорошем процессе вовлеченные эксперты имели бы, как минимум, несколько шансов указать на эти ошибки и исправить их (на вскидку таких точек для выявления в этом процессе должно было быть быть штук 5-6).
Слово менеджер уже прочно вошло в корпус русского языка.
Да теперь это даже слишком модное словечко у нас. Но это и стало причиной потери его смысла в отличие от английского эквивалентааналога созвучного слова. Согласитесь, что семантика потеряна напрочь.
В случае применения такого слова при разработке какого-нибудь международного стандарта, спецификации или любого подобного документа QA специалист обязательно должен был бы оставить в системе отслеживания ошибок запись со словами «ambiguous term». И я вас уверяю, это было бы исправлено очень быстро.
Задумайтесь, мы заимствовали слово. Ну, типа взяли кредит по которому нам придется расплачиваться долгие годы, каждый раз объясняя: «Ну, у нас это не совсем менеджер в истинном понимании значения этого слова. У нас офис-менеджер это секретарша, менеджер у прилавка это продавец, а ассистент младшего менеджера это… ну, как бы вам объяснить получше… ».
Представьте себе только стоимость чернил, которые на это будет потрачено? Ведь много Менеджеров смогли бы безбедно прожить остаток жизни на такие деньги не пачкаясь в чернилах.
Эх, к Рождеству надо настоящее чудо просить!
Не интересно же спрашивать про то, что уже упомянуто в стандарте. Интереснее про то, чего ещё нет…
Спросите сразу про «Теорию управления рисками» :-)
Это даже более актуально для гильдии менеджеров, чем всё перечисленное. Потому, что это коротко связано с деньгами.
К стати, в прошлом веке в СССР, когда ещё несоблюдение стандартов каралось по закону, эту теорию не оставляли без внимания. Сам свидетель, когда после игр с привлечением «Теории вероятности» выход годного при массовом производстве повышался с 30% до 90%. Вот такое было управление риском брака.
менеджер ИТ-продуктов… профессия очень молодая и ещё не устоялась даже на западе.
Не знаю, как в прошлом веке, но с начала 21 века в западных компаниях это профессия точно существовала и была прекрасно формализована. Однако, менеджер продуктов в понимании западного работодателя это совсем не «коммерсант» и не «самостоятельная боевая единица», прикипевшая к продукту, как это представлено в «стандарте».
Если коротко:
Менеджер продуктов это руководитель работ по поддержке всех (или же только определенных) фаз жизненного цикла продуктов (или одного конкретного продукта). Ему подотчетны различные команды непосредственно осуществляющие выполнение этих работ. Он непосредственно сам или через подотчетных менеджеров команд администрирует работы, связанные с продуктами, за которые он отвечает. Менеджер продуктов, по-сути, является административно-техническим «исполнителем желаний», поступающих от специалистов по маркетингу. Как правило, он работает на основании внутреннего корпоративного документа типа Market Requirements Document, который для конкретного продукта устанавливает соглашение между командами маркетинга и техническими командами. Другими документами, определяющими его работу является разработанные и утвержденные в компании планы жизненных циклов конкретных продуктов.
Вот коротко как-то так.
Помню, я действительно испытал шок, когда открыл для себя, что во многих(!) российских ИТ компаниях Менеджер проекта\продукта это настоящий кудесник-камикадзе, который, не обладая административными полномочиями над исполнителями, отвечает за выполнение проекта или счастливую жизнь продукта.
Это тогда подорвало мою веру:
в непогрешимость IDEF0 — у нас процессы работают даже когда ресурсы\механизмы неподконтрольны.
в необходимость иметь в организации строгую иерархию и единоначалие — «прибегает левый менеджер продукта к исполнителю и в пожарном порядке ориентирует его на выполнение срочной работы, прибегает правый менеджер… и понеслось...».
Думаю что должностные инструкции и тексты вакансий лучше писать человеческим языком, а не формальным.
Вообще-то целью изложения «формальным языком» обычно является повышение однозначности трактовки написанного всеми читателями целевой аудитории (или целевой компьютерной системой).
Или Вы за то, чтобы должностные инструкции и тексты вакансий можно было бы расценивать по принципу «как захочешь»? :-)
Хотя, да, авторов некоторых «формальных» текстов очень хочется попросить изложить свои мысли «человеческим языком».
Но, это чаще возникает совсем не из-за формализма.
Печальный какой-то этот документ. И кегль 12-тый и шрифт черный, и всё вроде бы согласно Методических рекомендаций, но не могу заставить себя назвать стандартом этот набор околоИТшных слов с опасным коммерческим креном.
Искренне жалею уважаемых авторов, которые с подачи Федора Тимофеевича (автора макета стандарта) и Министерства защиты трудностей, создали такой изумительный памятник сферического коня в вакууме в элегантной позе «не в контексте нынче я». Никого не желаю обидеть, просто констатирую факт по уже утвержденному стандарту.
Тем не менее, очень хочется спросить самих авторов документа из компаний со звучными названиями:
Действительно ли использовался "Системный подход" при разработке этого продукта, какой? Почему при таком прогрессивном подходе это осталось не задокументировано?
Какие "… предприятия компьютерных и информационных технологий" были выбраны в качестве эталона для тщательного "… системного анализа" установленных у них технологических и деловых процессов, которые «вдруг» потребовали привлечения трудовых ресурсов именно такого рода? И почему они были избраны, как эталон?
Почему в "1С" входной язык почти русский, а в стандарте применяется странно-неоднозначное заимствованное слово «менеджер» без каких либо разъяснений его значения для русскоязычного читателя?
Есть ли вообще возможность прояснить ситуацию с этой, вроде как по-определению руководящей(!) должностью, в случае «ассистент младшего менеджера» — кто такому в организационной иерархии будет подотчётен? Или предполагается, что эта должность вообще не административная, т.е. это просто недоАналитик с начальным(!) профессиональным образованием «заточенный» на торговлю и нанимаемый для перекладывания бумажек по модерновой безбумажной технологии?
И главный вопрос к авторам:
Какие авторитетные труды\материалы\издания\исследования легли в основу этого стандарта?
Ведь без ответов на подобные вопросы абсолютно невозможно определиться со степенью возможного доверия к этому «стандарту».
Вот, к примеру:
Вдруг мы не знаем, а уже таки появились секретные технологии, позволяющие «разрабатывать требования к качеству продукта» в рамках отдельно взятого «Трудового действия».
То есть делать это как-то отдельно от разработки других требований.
И это даже несмотря на то, что к продукту обычно предъявляется многоаспектный комплекс требований, в котором безусловно каждое значимое требование влияет на качество продукта.
Вдруг мы должны уже просто забыть про то, что качество продукта как раз и определяется его возможностями удовлетворить всяким требованиям, которые к нему предъявляются.
Допускаю, что документ возможно хорош для каких-то своих целей, но в таком виде некоторым ИТ компаниям он явно может оказать «медвежью услугу» и не простую, а многоаспектную.
Конечно же, кроме единственного советского «Оператора ЭВМ» в ИТ отрасли должны быть и какие-то другие специалисты, но есть большие опасения возникновения в компаниях состояния «перебора» от такого количества «мастей» менеджеров-коммерсантов.
Может в этом документе и всё изумительно правильно написано, просто «очень профессиональные» слова использованы и смысл написанного ускользает от обычного ИТ специалиста. Но, как же читателю понять это, если даже самого бестолкового словаря не предусмотрено?
Не знаю, как у вас, а у меня напрашивается вывод один:
Не тянет как-то этот документ на рождественский подарок ИТ сообществу. Не радостный он.
Нашёл…
Для парктроника квадрокоптера использовалось устройство из серии сенсоров XL-MaxSonar®-EZ™.
Конкретно в них в «черном бочонке» и «динамик» и «микрофон».
Но, в этой линейке продуктов весьма точные измерители, и разумеется цена чуть дороже 100 рублей.
Думаю, что пока ваша лампа не стала самоходной, то у вас есть шанс сэкономить…
А по первой попавшейся ссылке с DX, которую я прислал в качестве примера, не могу точно сказать… Вы же сами видите, как там русскими буквами на китайском написано, что и понять то сложно. Но, оптимизм в названии внушает, что это не просто УЗ датчик, а всё-таки «датчик расстояния». И по его картинке похоже, что это именно тот активный элемент, который ставится на плату HC-SR04.
Те датчики, что на видео абсолютно «бесшумные», как летучая мышь! Не помню точные характеристики, но 1-я гармоника излучаемой частоты этих приборов, ну, стопроцентно выше верхней границы слышимого диапазона (> 20 кГц).
К сожалению, не могу сейчас сказать модель этих устройств. Но, точно не дорогие, купленные сынишкой на китайском сайте (типа этого, но ещё и с платой, реализующий первичное автоматическое управление и интерфейс). Он принес их со словами: «Папа, приделай мне это к квадрокоптеру, чтоб безопасно летать в ограниченном пространстве». Поэтому, от модели требовались вполне конкретные характеристики дальности (до 8 метров работали! — в эксперименте на видео они были максимально «задушены»), конфигурации пространственной диаграммы направленности во всех трех измерениях, потреблению, весу, интерфейсу и т.д.
Не уговариваю, но, уверен, что светильник с несколькими УЗ датчиками с подобранными характеристиками и расположением сможет распознавать даже простые жесты (типа «рука вверх», «рука вперед», и т.д.), не говоря уже о весьма точном (до сантиметров) измерении расстояния до управляющего субъекта.
Да, и название модифицированной версии вашего изделия привлекательнее будет:
«Светильник СДБ-ЗУ „Евлампия“ с парктроником со светтроником».
Культура бизнеса (читай «делания денег») определяет культуру производства,
и, следовательно, существенно влияет на то, что производится для нашего потребления.
… ну, и чтобы печально замкнуть цикл процитирую: "мы есть то, что потребляем".
Это важно: НЕ «составляются новые планы», а корректируются существующие планы.
Изначальный «план» ДОЛЖЕН составляться на основании четко проработанного и известного Жизненного цикла человека продукта. Вероятность изменения содержания и последовательности этапов такого цикла весьма мало.
Наличие в компании знаний о Жизненном цикле продукта позволяет на его основе формировать не только инженерно-технические решения. Например, появляется возможность производить обоснованные финансовые расчеты для среднесрочной перспективы в зависимости от складывающейся ситуации в настоящий момент. Ценность таких расчетов для планирования деятельности компании сложно переоценить.
И заметьте, это уже не просто планирование, а это оперативный ситуационный прогноз.
Любой бизнесмен будет несомненно доволен, если такой ораКлёвый процесс прогнозирования будущего будет у него на вооружении. И скорее всего, с тем, кто его обеспечит, он поделится самым сокровенным…
Когда смотрел ваш ролик и вслушивался в музыкальное сопровождение — классно подобранную вариацию на тему популярной нынче песни кометы 67P, сразу как-то вспомнились творения господ Скрябина и Термена.
Прочитал в статье о проблеме с ИК датчиком и на фоне мыслей о звуке вспомнил об одном своем давнем эксперименте с ультразвуковыми сенсорами — может такое решение поможет вам избавиться от текущих проблем и добавит для развлечения других.
Жаль, когда после «наивысшего достижения человечества — разделения труда по специальностям» архитекторы залов как-то самоустраняются от проблем акустики в своих творениях, рассчитывая только на современную аппаратуру.
В акустическом плане меня когда-то поразил актовый зал в Питере в старом здании Бонча (наб. реки Мойка, 61).
Там со сцены можно не напрягаясь шепотом «докричаться» до самого дальнего угла зала, но чтобы из этого же угла стало что-то слышно на сцене надо реально крикнуть. Как так у архитекторов и строителей получилось, ведь никаких «замурованных» амфор под креслами!?
Думаю, что цифры нужно читать, как «гуру» фирмы. И эти ребята были выбраны авторами публикации, чтобы представить годами наработанное мнение 6000-ного коллектива по профессиональному вопросу, который важен для любого программиста.
Без разницы. Программа это идея воплощенная в исходном коде. Комментарий свидетельствует, что в коде воплощена «некрасивая» идея. Процесс разработки обязан уметь отслеживать наличие подобных проблем в коде для возможности их оценки и, возможно, исправления. Рассматриваемый комментарий серьезно затрудняет это. Именно поэтому он некрасивый.
«Красивый» коммерческий(!) код обязан быть прагматичным.
Например, этот комментарий мог бы быть таким: // FixMe #100500
где #100500 это ссылка на запись в используемой системе отслеживания проблем.
Однако, если использовать «notepad» в качестве инструмента разработки, то такой вариант будет не очень удобен. Поэтому, «красота» кода не может рассматриваться вне контекста проекта, процесса разработки и в отрыве от используемых инструментов.
Хочется верить, что подобное не уходит в релиз. Хотя, сам факт возникновения этого поста свидетельствует о том, что Яндекс дошел в своем развитии до необходимости решения таких проблем. И это радует.
Расстраивает другое — когда инженер обосновывает решения своим чувственным восприятием мира, то это значит, что он не знает, как технически правильно решить задачу.
комментарии в коде на английском или на русском?
IMHO Ключевые слова, константы, переменные… — на «английском», тогда логично, что и комментарии на том же языке. Иначе будут ненужные сложности перевода для неминуемо связанного «embedded language» в комментариях. Да, и неоднократно доказано, что правильно написанные комментарии на английском будут короче, обеспечивая тот же объем информации.
Ну а как иначе-то? Представьте заинтересованный читатель, увидев такое, набирает в поисковике название Теории, изучает и приобретает ценные знания в области… управления ценными бумагами.
Или я не понял, ваши Менеджеры имею такой широкий профиль, что хватает и для улыбки соответствующего размера — это ещё и спецы рынка ценных бумаг? Представляю себе такого Менеджера: «Босс, мой проект имеет плохую отдачу в этом квартале… давай сольём оборудование и эти деньги я лучше в ГКО вложу...»
Назвав, стандарт "… в вакууме" я не издевался, а высветил отсутствие базиса и внешних связей стандарта.
Почему создатели «стандарта» позволили себе отвергнуть опыт человечества, которое веками снабжала свои шедевры разделом «Список литературы»?
Это же прописные истины, которые обязательно надо знать всем, и особенно составителям стандартов.
Я вам по секрету скажу, что есть Закон:
"… Участники работ по стандартизации, а также национальные стандарты, предварительные национальные стандарты, общероссийские классификаторы технико-экономической и социальной информации, правила их разработки и применения, правила стандартизации, нормы и рекомендации в области стандартизации, своды правил образуют национальную систему стандартизации.
www.consultant.ru/popular/techreg/45_3.html#p377
© КонсультантПлюс, 1992-2014"
Или у вас есть ноу-хау, позволяющее строить Систему без связей?
Но, не беспокойтесь, юридически составители этого стандарта, вроде как, чисты — ваш «стандарт» не технический.
Он скорее гуманитарный :-)
Но, МинКомСвязи, осваивая пространство им. Вирта, накликал ещё беду. И теперь, если терпеливо исполнять правило 3Д, то с большой вероятностью мимо неторопливо проплывет… менеджер с какой-нибудь специализацией. И скажет нам мудрец восточный: «Я понимать, у Вас Манагер, как Иванов, многая такая фамилия».
Не могу утверждать точно, но похоже Министерства вовлекли грамотных и образованных специалистов в процесс, имеющий целый ряд системных ошибок. Я так полагаю потому, что в хорошем процессе вовлеченные эксперты имели бы, как минимум, несколько шансов указать на эти ошибки и исправить их (на вскидку таких точек для выявления в этом процессе должно было быть быть штук 5-6).
Да теперь это даже слишком модное словечко у нас. Но это и стало причиной потери его смысла в отличие от английского
эквивалентааналогасозвучного слова. Согласитесь, что семантика потеряна напрочь.В случае применения такого слова при разработке какого-нибудь международного стандарта, спецификации или любого подобного документа QA специалист обязательно должен был бы оставить в системе отслеживания ошибок запись со словами «ambiguous term». И я вас уверяю, это было бы исправлено очень быстро.
Задумайтесь, мы заимствовали слово. Ну, типа взяли кредит по которому нам придется расплачиваться долгие годы, каждый раз объясняя: «Ну, у нас это не совсем менеджер в истинном понимании значения этого слова. У нас офис-менеджер это секретарша, менеджер у прилавка это продавец, а ассистент младшего менеджера это… ну, как бы вам объяснить получше… ».
Представьте себе только стоимость чернил, которые на это будет потрачено? Ведь много Менеджеров смогли бы безбедно прожить остаток жизни на такие деньги не пачкаясь в чернилах.
Не интересно же спрашивать про то, что уже упомянуто в стандарте. Интереснее про то, чего ещё нет…
Спросите сразу про «Теорию управления рисками» :-)
Это даже более актуально для гильдии менеджеров, чем всё перечисленное. Потому, что это коротко связано с деньгами.
К стати, в прошлом веке в СССР, когда ещё несоблюдение стандартов каралось по закону, эту теорию не оставляли без внимания. Сам свидетель, когда после игр с привлечением «Теории вероятности» выход годного при массовом производстве повышался с 30% до 90%. Вот такое было управление риском брака.
Не знаю, как в прошлом веке, но с начала 21 века в западных компаниях это профессия точно существовала и была прекрасно формализована. Однако, менеджер продуктов в понимании западного работодателя это совсем не «коммерсант» и не «самостоятельная боевая единица», прикипевшая к продукту, как это представлено в «стандарте».
Если коротко:
Менеджер продуктов это руководитель работ по поддержке всех (или же только определенных) фаз жизненного цикла продуктов (или одного конкретного продукта). Ему подотчетны различные команды непосредственно осуществляющие выполнение этих работ. Он непосредственно сам или через подотчетных менеджеров команд администрирует работы, связанные с продуктами, за которые он отвечает. Менеджер продуктов, по-сути, является административно-техническим «исполнителем желаний», поступающих от специалистов по маркетингу. Как правило, он работает на основании внутреннего корпоративного документа типа Market Requirements Document, который для конкретного продукта устанавливает соглашение между командами маркетинга и техническими командами. Другими документами, определяющими его работу является разработанные и утвержденные в компании планы жизненных циклов конкретных продуктов.
Вот коротко как-то так.
Помню, я действительно испытал шок, когда открыл для себя, что во многих(!) российских ИТ компаниях Менеджер проекта\продукта это настоящий кудесник-камикадзе, который, не обладая административными полномочиями над исполнителями, отвечает за выполнение проекта или счастливую жизнь продукта.
Это тогда подорвало мою веру:
Вообще-то целью изложения «формальным языком» обычно является повышение однозначности трактовки написанного всеми читателями целевой аудитории (или целевой компьютерной системой).
Или Вы за то, чтобы должностные инструкции и тексты вакансий можно было бы расценивать по принципу «как захочешь»? :-)
Хотя, да, авторов некоторых «формальных» текстов очень хочется попросить изложить свои мысли «человеческим языком».
Но, это чаще возникает совсем не из-за формализма.
Искренне жалею уважаемых авторов, которые с подачи Федора Тимофеевича (автора макета стандарта) и Министерства
защиты трудностей, создали такой изумительный памятник сферического коня в вакууме в элегантной позе «не в контексте нынче я».Никого не желаю обидеть, просто констатирую факт по уже утвержденному стандарту.
Тем не менее, очень хочется спросить самих авторов документа из компаний со звучными названиями:
Есть ли вообще возможность прояснить ситуацию с этой, вроде как по-определению руководящей(!) должностью, в случае «ассистент младшего менеджера» — кто такому в организационной иерархии будет подотчётен? Или предполагается, что эта должность вообще не административная, т.е. это просто недоАналитик с начальным(!) профессиональным образованием «заточенный» на торговлю и нанимаемый для перекладывания бумажек по модерновой безбумажной технологии?
И главный вопрос к авторам:
Какие авторитетные труды\материалы\издания\исследования легли в основу этого стандарта?
Ведь без ответов на подобные вопросы абсолютно невозможно определиться со степенью возможного доверия к этому «стандарту».
Вот, к примеру:
Вдруг мы не знаем, а уже таки появились секретные технологии, позволяющие «разрабатывать требования к качеству продукта» в рамках отдельно взятого «Трудового действия».
То есть делать это как-то отдельно от разработки других требований.
И это даже несмотря на то, что к продукту обычно предъявляется многоаспектный комплекс требований, в котором безусловно каждое значимое требование влияет на качество продукта.
Вдруг мы должны уже просто забыть про то, что качество продукта как раз и определяется его возможностями удовлетворить всяким требованиям, которые к нему предъявляются.
Допускаю, что документ возможно хорош для каких-то своих целей, но в таком виде некоторым ИТ компаниям он явно может оказать «медвежью услугу» и не простую, а многоаспектную.
Конечно же, кроме единственного советского «Оператора ЭВМ» в ИТ отрасли должны быть и какие-то другие специалисты, но есть большие опасения возникновения в компаниях состояния «перебора» от такого количества «мастей» менеджеров-коммерсантов.
Может в этом документе и всё изумительно правильно написано, просто «очень профессиональные» слова использованы и смысл написанного ускользает от обычного ИТ специалиста. Но, как же читателю понять это, если даже самого бестолкового словаря не предусмотрено?
Не знаю, как у вас, а у меня напрашивается вывод один:
Не тянет как-то этот документ на рождественский подарок ИТ сообществу. Не радостный он.
Для парктроника квадрокоптера использовалось устройство из серии сенсоров XL-MaxSonar®-EZ™.
Конкретно в них в «черном бочонке» и «динамик» и «микрофон».
Но, в этой линейке продуктов весьма точные измерители, и разумеется цена чуть дороже 100 рублей.
Думаю, что пока ваша лампа не стала самоходной, то у вас есть шанс сэкономить…
А по первой попавшейся ссылке с DX, которую я прислал в качестве примера, не могу точно сказать… Вы же сами видите, как там русскими буквами на китайском написано, что и понять то сложно. Но, оптимизм в названии внушает, что это не просто УЗ датчик, а всё-таки «датчик расстояния». И по его картинке похоже, что это именно тот активный элемент, который ставится на плату HC-SR04.
К сожалению, не могу сейчас сказать модель этих устройств. Но, точно не дорогие, купленные сынишкой на китайском сайте (типа этого, но ещё и с платой, реализующий первичное автоматическое управление и интерфейс). Он принес их со словами: «Папа, приделай мне это к квадрокоптеру, чтоб безопасно летать в ограниченном пространстве». Поэтому, от модели требовались вполне конкретные характеристики дальности (до 8 метров работали! — в эксперименте на видео они были максимально «задушены»), конфигурации пространственной диаграммы направленности во всех трех измерениях, потреблению, весу, интерфейсу и т.д.
Не уговариваю, но, уверен, что светильник с несколькими УЗ датчиками с подобранными характеристиками и расположением сможет распознавать даже простые жесты (типа «рука вверх», «рука вперед», и т.д.), не говоря уже о весьма точном (до сантиметров) измерении расстояния до управляющего субъекта.
Да, и название модифицированной версии вашего изделия привлекательнее будет:
«Светильник СДБ-ЗУ „Евлампия“
с парктроникомсо светтроником».Культура бизнеса (читай «делания денег») определяет культуру производства,
и, следовательно, существенно влияет на то, что производится для нашего потребления.
… ну, и чтобы печально замкнуть цикл процитирую: "мы есть то, что потребляем".
Изначальный «план» ДОЛЖЕН составляться на основании четко проработанного и известного Жизненного цикла
человекапродукта.Вероятность изменения содержания и последовательности этапов такого цикла весьма мало.
Наличие в компании знаний о Жизненном цикле продукта позволяет на его основе формировать не только инженерно-технические решения.
Например, появляется возможность производить обоснованные финансовые расчеты для среднесрочной перспективы в зависимости от складывающейся ситуации в настоящий момент. Ценность таких расчетов для планирования деятельности компании сложно переоценить.
И заметьте, это уже не просто планирование, а это оперативный ситуационный прогноз.
Любой бизнесмен будет несомненно доволен, если такой ораКлёвый процесс прогнозирования будущего будет у него на вооружении. И скорее всего, с тем, кто его обеспечит, он поделится самым сокровенным…
Прочитал в статье о проблеме с ИК датчиком и на фоне мыслей о звуке вспомнил об одном своем давнем эксперименте с ультразвуковыми сенсорами — может такое решение поможет вам избавиться от текущих проблем
и добавит для развлечения других.оGOLDелое внедрение — внедрение с целью ни чем не сдерживаемого обогащения.
В акустическом плане меня когда-то поразил актовый зал в Питере в старом здании Бонча (наб. реки Мойка, 61).
Там со сцены можно не напрягаясь шепотом «докричаться» до самого дальнего угла зала, но чтобы из этого же угла стало что-то слышно на сцене надо реально крикнуть. Как так у архитекторов и строителей получилось, ведь никаких «замурованных» амфор под креслами!?
IMHO Это нехороший «положительный» пример в статье.
Для технического текста на русском языке правильнее написать:
Мы не достигли нужной производительности
Тогда будет проще понять смысл написанного.
А, манерное слово «перформанс» лучше оставить специалистам от «шоу бизнеса».
«Красивый» коммерческий(!) код обязан быть прагматичным.
Например, этот комментарий мог бы быть таким:
// FixMe #100500где #100500 это ссылка на запись в используемой системе отслеживания проблем.
Однако, если использовать «notepad» в качестве инструмента разработки, то такой вариант будет не очень удобен. Поэтому, «красота» кода не может рассматриваться вне контекста проекта, процесса разработки и в отрыве от используемых инструментов.
Расстраивает другое — когда инженер обосновывает решения своим чувственным восприятием мира, то это значит, что он не знает, как технически правильно решить задачу.
IMHO Ключевые слова, константы, переменные… — на «английском», тогда логично, что и комментарии на том же языке. Иначе будут ненужные сложности перевода для неминуемо связанного «embedded language» в комментариях. Да, и неоднократно доказано, что правильно написанные комментарии на английском будут короче, обеспечивая тот же объем информации.
// The following code is no longer required ......<boat anchor>...Допустимы ли антишаблоны в красивом исходном коде?