Да нет же:) я же написал «Статья не техническая и отражает взгляд на мир, присущий ограниченным людям». Если бы она была или техническая, или рассматривала вопрос широко, то ей было бы тут самое место.
Например — статья про борщевик не техническая, но она очень интересно, информативно и достоверно раскрывает тему.
Одна из самых больших ценностей, которыми обладает Хабр, это научная культура обращения с информацией — Информативность, доказательность (опровержимость), логическая непротиворечивость, явные отсылки к источникам, явное выделение частного мнения автора, в случае если оно имеет место.
Данный материал не отвечает ни одному из этих критериев, более того, она не только не несет новой информации, но еще и вводит в заблуждение аудиторию, которая не разбирается в предмете, что легко увидеть по комментариям.
Если не считать техническим текст только потому, что там нет инструкций ЯП или формального языка, то это будет печаль, потому что математика начинается с того что:
Множества состоят из элементов
Говорят, что множество A является подмножеством множества B, если все элементы A являются элементами B.
Множества A и B равны, если они содержат одни и те же элементы.
А главная книга отца Visual Basic это «Психбольница в руках пациентов».
Без анализа требований никакое дальнейшее «техническое» содержание в принципе не нужно:)
Дело не в том, можно ли «правильно» понять ту или иную сентенцию автора.
Дело в том, что автор обрисовал неких странных антигероев, изрекающих глупые клеше через фразу, причем сделал это чисто ради хайпа, и чтобы польстить парню в шарфе, с которым они приятели.
Это как графити, или прибивание своих причиндалов к брусчатке.
Ну как бы введите в гугл «Анализ требований», и посмотрите на 2-е место поиска?
Ну или введите «Telegram бот erlang» и посмотрите на 1-е место:)
И таки да, если хотите, чтобы я не использовал квантор всеобщности, то докажите, что публикация таких «фанфиков» в перспективе вам совсем не навредит:)
У Ольги Бузовой подписчиков 14 млн, и что с того? :) именно молчаливое согласие подписчиков позволяет таким как она пропагандировать воинствующее невежество.
Хабр имеет репутацию, и многие люди воспринимают написанное тут, как надежную информацию, мне казалось в интересах всех участников, чтобы эта ситуация сохранялась?
Хабр читают не только сложившиеся люди, но и молодеж, начинающие карьеру. Вы правда считаете, что честно и ответственно сообщать им собирательные образы ИТ-директора и бизнесмена, настолько оторванные от реальности?
Естественно существуют и такие «ИТ-директора», и такие «серийные бизнесмены» (Сделал один сайт = «у меня студия», Сдал квартиру = «я работаю на рынке недвижимости»).
Но нормальный ИТ-директор хорошо разбирается в метриках своего бизнеса, согласует свои действия с корпоративной стратегией, и решения принимает на основе расчетов TCO и ROI.
Нормальный бизнесмен, это не «стартапер», а трудолюбивый и целеустремленный человек, который вкалывает как ломовой конь, до седьмого пота, чтобы создать добавленную ценность для своих клиентов.
Рассмотрим пару примеров других голословных утверждений из статьи:
Вот это про СРМ. Это методика управления тем, чего нет. Что в семье, что в бизнесе – надо создавать и поддерживать отношения, а не управлять ими
Что правда чтоли? Многомиллионная индустрия существует и успешно развивается на том, чего нет? Это примерно тоже самое, что и «Я тут построил самолет, он не взлетел, это потому, что самолеты летать не могут у меня руки кривые».
Я и сама училась на МБА. Давно, правда. Знаете, к какому выводу постепенно пришла? МБА – это агонизирующий монстр.
Что-то мне подсказывает, что герой Автор училась не в Wharton, Harvard Business School, и даже не в MIT.
Проблемы в том, что:
1. Современная разработка ПО это сотни технологий и тысячи фреймворков, и каждый надо предварительно учить.
2. Современное общество производит социопатов, а работать с козлами никто не хочет.
3. Оставшееся меньшинство имеет свои профессионнальные цели и имущественные запросы, которые экономика проекта не всегда позволяет удовлетворить.
Вот и получается типичный процесс подбора:
1. Выложили вакансию
2. Получили 200 заявок за первую неделю
3. Отбросили 150 резюме стажеров и откровенно непрофильных людей.
4. Отправили тестовые задания, половина не ответили, а из второй половины 50% правильных решений.
5. В итоге из 200 осталось 10-12 человек чтобы назначить собеседование, из них 3 не пришло, еще 4 козла, и одна звезда:) осталось 2-4 человек, из которых можно выбрать.
Не вижу противоречия:) Просто use cases должен писать менеджер по продукту или аналитик, желательно сразу с wire frames или дизайн-макетами, а уже потом показывать Заказчику. Опять же я не встречал Заказчиков, которые могли качественно проверить use case, не видя макетов экранов.
Ну не совсем напрямую, а в форму ввода с настроенным срезом из куба.
Часть данных в системе бюджетирования считается и их нельзя исправить руками, но основные цифры вводят руками начальники подразделений и финансисты т.к. никто не знает их планов, кроме них самих.
Можно и по другому взглянуть на этот вопрос — загрузка фактических данных должна быть автоматизирована, но если модель требует десять раз обогащать данные, или ежедневно обновлять справочники, то с системой тоже явно что-то не в порядке.
Спасибо за комплимент:) даже если интегрируются «суровые монстры» — если между двумя системами выполняющими полезную работу появляется третья только для связи между ними — это плохо, потому что это +1 технология и +1 человек поддержку и +1 комплект документации на решение для хранения.
А когда систем работает 100+, то реальна ситуация когда под сокращение кого-то уволят и о ней просто забудут пока ненакроется
Есть хорошее правило — требования к интерфейсу интеграции определяет система-приемник.
Допиливать надо источник и выкладывать конец в Enterprise Service Bus, где в идеале лежит вся интеграция. Чтобы никаких «кротовых нор» не было.
Вы сходите на 10 ИТ-собеседований и скажите — «У меня есть статьи на Хабре», а потом посмотрите на выражение лиц.
А потом сходите еще на 10 ИТ-собеседований и скажите — «У меня есть статьи на Пикабу», и опять посмотрите на выражение лиц.:))
Например — статья про борщевик не техническая, но она очень интересно, информативно и достоверно раскрывает тему.
Одна из самых больших ценностей, которыми обладает Хабр, это научная культура обращения с информацией — Информативность, доказательность (опровержимость), логическая непротиворечивость, явные отсылки к источникам, явное выделение частного мнения автора, в случае если оно имеет место.
Данный материал не отвечает ни одному из этих критериев, более того, она не только не несет новой информации, но еще и вводит в заблуждение аудиторию, которая не разбирается в предмете, что легко увидеть по комментариям.
Если не считать техническим текст только потому, что там нет инструкций ЯП или формального языка, то это будет печаль, потому что математика начинается с того что:
А главная книга отца Visual Basic это «Психбольница в руках пациентов».
Без анализа требований никакое дальнейшее «техническое» содержание в принципе не нужно:)
Дело в том, что автор обрисовал неких странных антигероев, изрекающих глупые клеше через фразу, причем сделал это чисто ради хайпа, и чтобы польстить парню в шарфе, с которым они приятели.
Это как графити, или прибивание своих причиндалов к брусчатке.
Ну или введите «Telegram бот erlang» и посмотрите на 1-е место:)
И таки да, если хотите, чтобы я не использовал квантор всеобщности, то докажите, что публикация таких «фанфиков» в перспективе вам совсем не навредит:)
Это было познавательно, и это была надежная, проверенная информация, отличный пример того — как надо подходить к изучению вопроса
Естественно существуют и такие «ИТ-директора», и такие «серийные бизнесмены» (Сделал один сайт = «у меня студия», Сдал квартиру = «я работаю на рынке недвижимости»).
Но нормальный ИТ-директор хорошо разбирается в метриках своего бизнеса, согласует свои действия с корпоративной стратегией, и решения принимает на основе расчетов TCO и ROI.
Нормальный бизнесмен, это не «стартапер», а трудолюбивый и целеустремленный человек, который вкалывает как ломовой конь, до седьмого пота, чтобы создать добавленную ценность для своих клиентов.
Рассмотрим пару примеров других голословных утверждений из статьи:
Что правда чтоли? Многомиллионная индустрия существует и успешно развивается на том, чего нет? Это примерно тоже самое, что и «Я тут построил самолет, он не взлетел, это потому, что самолеты летать не могут
у меня руки кривые».Что-то мне подсказывает, что герой
Авторучилась не в Wharton, Harvard Business School, и даже не в MIT.Человек заходит, читает это, закрывает -> никогда больше не заходит на Хабр.
Понятно, что одна статья большого вреда не наделает, но это тенденция, и это вредит всем.
Такими материалами Автор паразитирует на репутации ресурса, созданной другими.
Хорошо, конечно, что человек умеет писать тексты, но так и до бульварной прессы недалеко.
Эта статья не техническая, и она отражает взгляд на мир, присущий очень ограниченым людям.
Здесь этому не место, это вредит репутации Хабра и продвижению статей нормальных участников сообщества.
Бизнес-молодость :)) забыли еще добавить [и я езжу на метро].
ПС: У большинства реально богатых людей один бизнес, в который они вложили эдак лет 15 жизни:)
1. Современная разработка ПО это сотни технологий и тысячи фреймворков, и каждый надо предварительно учить.
2. Современное общество производит социопатов, а работать с козлами никто не хочет.
3. Оставшееся меньшинство имеет свои профессионнальные цели и имущественные запросы, которые экономика проекта не всегда позволяет удовлетворить.
Вот и получается типичный процесс подбора:
1. Выложили вакансию
2. Получили 200 заявок за первую неделю
3. Отбросили 150 резюме стажеров и откровенно непрофильных людей.
4. Отправили тестовые задания, половина не ответили, а из второй половины 50% правильных решений.
5. В итоге из 200 осталось 10-12 человек чтобы назначить собеседование, из них 3 не пришло, еще 4 козла, и одна звезда:) осталось 2-4 человек, из которых можно выбрать.
Часть данных в системе бюджетирования считается и их нельзя исправить руками, но основные цифры вводят руками начальники подразделений и финансисты т.к. никто не знает их планов, кроме них самих.
Можно и по другому взглянуть на этот вопрос — загрузка фактических данных должна быть автоматизирована, но если модель требует десять раз обогащать данные, или ежедневно обновлять справочники, то с системой тоже явно что-то не в порядке.
А когда систем работает 100+, то реальна ситуация когда под сокращение кого-то уволят и о ней просто забудут пока ненакроется
Есть хорошее правило — требования к интерфейсу интеграции определяет система-приемник.
Допиливать надо источник и выкладывать конец в Enterprise Service Bus, где в идеале лежит вся интеграция. Чтобы никаких «кротовых нор» не было.