Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>Вообще, суть любого истинно научного (то есть, ориентированного на объективные факты и уверенное воспроизводство результата) метода, предназначенного для практической работы, тем более — с людьми, состоит не в том, чтобы "сделать идеально", а чтобы как-то улучшить то, что есть.
Ну, мы сейчас спорим о терминах. Научный метод — это вполне формальный цикл, который повторяется раз за рабом для решения проблемы.
Картинка
Пишешь ли ты диссертацию, проводишь исследования или пишешь код — едино. Что R&D в западных компаниях, что НИР и НИОКР в отечественных.
1. Есть проблема, ты собираешь материалы по тому, как она решается, пишешь документ или статью. Обсудили коллективом.
2. Выбрали что-то перспективное, собрали код из говна и палок кусков опенсорса, закрытого ПО, что-то сами дописали, написали для этого тесты — готов один или несколько прототипов, они тестируются, замеряются все важные метрики, пишется документ/статья — обсудили с коллективом.
3. Выбранный подход подходит или нужен новый — не важно, пишется уже нормальная реализация, отлаживается, все необходимые метрики должны быть выполнены. Если нет, то возврат в пункт 2.
4. Оптимизация, причёсывание кода, возможно, что переписывание на другой ЯП или на другое железо (GPU, ПЛИС, что-то дохлое и встраивавемое). Работает? Замеряем, пишем документ/статью, докладываем коллегам.
5. Интеграция в конечный продукт, сопровождение, написание конечной документации.
В конечном итоге, кроме самого продукта — софтверного или устройства в железе — является документация, которая позволяет понять процесс разработки, почему выбрано именно такое решение, в чём его теоретическая суть и как оно реализовано. По этой документации можно реализовать тот же продукт уже силами инженеров.
Вот это в моём понимании научный метод решения проблем в нашей области.
То что ты описываешь, в том числе применение научных достижений, формул, теорем и т.д. — это обычный инженерный, системный и здравый подход, который подходит для большинства разработок.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>То есть, если аналитик в состоянии найти в процессах объективные недостатки, предложить способы решения проблем, которые реально работают, то это вполне себе годный аналитик.
Когда задачи поисковые — трудно что-то найти, но легко проверить полезность найденного. Тогда не проблема, любой может что-то найти, даже случайно.
А когда проверять годность идей очень дорого, цена ошибки, риски большие. Тогда особо не поэкспериментируешь с сомнительными решениями.
Например, в Microsoft во времена Windows 8 кому-то пришла идея захватить мир плиточными интерфейсами. И десктоп "модернизировать" и захватить мобильный рынок. Проверяя правильность таких идей можно потерять все — им еще повезло, что на десктопе у них не было конкуренции.
Стив Баллмер: Windows 8 — самый рискованный продукт ...
Вероятно, в Windows 8 будет очень много радикальных изменений, и реакцию пользователей на них предсказать невозможно.
Здравствуйте, Silver_S, Вы писали:
S_S>в Microsoft во времена Windows 8 кому-то пришла идея захватить мир плиточными интерфейсами. И десктоп "модернизировать" и захватить мобильный рынок.
Вот сама эта идея и показывает, что аналитика у них тогда была так себе. Ну, или сама по себе аналитика была на уровне, но кто-то важный настоял на этой идее. Их ведь никто за хвост не тянул внедрять все эти "радикальные изменения". Такое хорошо для какого-нибудь стартапа, не имеющего за душой ничего более значимого, и идущего ва-банк под девизом "а вдруг пипл захавает?", но не для крупной корпорации с долгой историей и множеством серьезных решений.
Ну и то, как они старательно закапывали Windows CE, которая вполне могла бы доминировать на смартфонах вместо Android, тоже показывает...
Здравствуйте, Nuzhny, Вы писали:
N>1. Есть проблема, ты собираешь материалы по тому, как она решается, пишешь документ или статью.
Когда цена ошибки большая, тогда еще полезно заполучить документ, где перечислены все возможные способы решения проблемы. Даже если их много, можно разбить на несколько классов/категорий. И для каждого из них список преимуществ и недостатков(или новых под-проблем). И список — как эти недостатки/под-проблемы можно было бы обойти.
Чтобы это дерево решений не раздувалось придется правильно отбрасывать несущественные детали.
Так можно заполучить почти доказательство, что именно такой-то способ решения нужен.
Здравствуйте, Silver_S, Вы писали:
S_S>Когда цена ошибки большая, тогда еще полезно заполучить документ, где перечислены все возможные способы решения проблемы. Даже если их много, можно разбить на несколько классов/категорий. И для каждого из них список преимуществ и недостатков(или новых под-проблем). И список — как эти недостатки/под-проблемы можно было бы обойти.
Это уже что-то очень большое и сложное, у меня не было опыта участия в подобных проектах. Кажется, что тут административный ресурс будет важнее научных компетенций. Ты же гооворишь о том, чтобы собрать с разногодных узкоспециализированных групп какие-то данные, а потом их обработать.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, gress, Вы писали:
G>>Нужно сперва прочувствовать попаболь от кривых продуктов, сделанных не по феншую, на своей собственной заднице.
ЕМ>Многие кривые продукты как раз "сделаны по феншую", да только феншуй применяли не тот, или не так, или не там.
Лекарство тоже надо уметь применять в правильных дозах, а то оно может привести к побочке и/или к смерти.
G>Нужно сперва прочувствовать попаболь от кривых продуктов, сделанных не по феншую, на своей собственной заднице.
По-моему, обсуждаемый предмет не только к подразумеваемым продуктам имеет отношение. Возможно, это теория вообще о том, как строить работу организации.
Здравствуйте, Marzec19, Вы писали:
M>Возможно, это теория вообще о том, как строить работу организации.
Таких теорий множество, но ни одна не признана достойной массового применения. Примерно как в психологии — моделей много, а с воспроизводством результатов до сих пор проблемы. Каждая из историй "я построил успешную компанию, делайте так же" является, по сути, "ошибкой выжившего".
Здравствуйте, Евгений Музыченко, Вы писали:
G>>Нужно сперва прочувствовать попаболь от кривых продуктов, сделанных не по феншую, на своей собственной заднице.
ЕМ>Многие кривые продукты как раз "сделаны по феншую", да только феншуй применяли не тот, или не так, или не там.
Вобщем, надо признать, это из тех областей знаний, что опираются на персональный опыт и плохо поддаются формализации.
Даже если некий успешный разработчик/бизнесмен/психолог/т.п. и рад бы поделиться своим опытом на склоне лет, но его неправильно понимают и получается очередной карго-культ подражателей.
Здравствуйте, graniar, Вы писали:
G>Даже если некий успешный разработчик/бизнесмен/психолог/т.п. и рад бы поделиться своим опытом на склоне лет, но его неправильно понимают
Его-то вполне могут понимать правильно, но он сам может неправильно понимать и ранжировать факторы, сделавшие его успешным. Например, он может искренне считать, что обязан своим успехом образованию и применению "научных методов", а на деле бОльшая часть того успеха произошла от его личного обаяния, помощи (не всегда заметной и осознаваемой) окружающих, или даже от простого везения.
Здравствуйте, graniar, Вы писали:
G>Вобщем, надо признать, это из тех областей знаний, что опираются на персональный опыт и плохо поддаются формализации. G>Даже если некий успешный разработчик/бизнесмен/психолог/т.п. и рад бы поделиться своим опытом на склоне лет, но его неправильно понимают и получается очередной карго-культ подражателей.
Даже если формализуют, если там большая роль навыков, а не знаний, то знакомства с теорией недостаточно.
Как при изучении языков(иностранных). Грамматика в естественных языках более-менее формализована, но если только ознакомится с теорией, то заговорить просто так не получится. Если нужны языковые навыки, то только активно тренировать, а не пассивно учить/запоминать.
Системный анализ — междисциплинарное направление. Много всего нужно одновременно и целостно.
Например, ТРИЗ. В IT сам ТРИЗ не нужен, а навыки пригодились бы всем. Если ознакомится с теорией, поупражняться в решении задач, после этого забыть про лишнюю теорию и подробности.
Здравствуйте, Silver_S, Вы писали:
S_S>Как при изучении языков(иностранных). Грамматика в естественных языках более-менее формализована, но если только ознакомится с теорией, то заговорить просто так не получится. Если нужны языковые навыки, то только активно тренировать, а не пассивно учить/запоминать.
У меня есть пример лучше: если написать сотню книг на тему "как рассказывать анекдоты, чтобы было смешно", какой доле тех, у кого есть природный талант смешить окружающих, они смогут серьезно помочь? И наоборот, если у кого нет таланта и способностей, насколько им поможет прочтение этих книг?
S_S>Например, ТРИЗ. В IT сам ТРИЗ не нужен, а навыки пригодились бы всем.
А в других областях он нужен? Насколько я знаю, ТРИЗ так и не получилось довести до состояния, в котором изучение именно теории (а просто знание физики, инженерных дисциплин, набора типовых решений, типовых приемов и т.п.) значимо меняло бы способность инженера к изобретательству.
И наоборот, если у кого нет таланта и способностей, насколько им поможет прочтение этих книг? 