В теме 67 ответов, и 7 участников, последнее обновление сделано пользователем 
Андрей Курьян 13 г, 6 мес. назад.
-
Сообщения
-
Всем привет. Я недавно конкретно всех достал здесь со странными разборками на тему того как поднять продуктивность аналитика до максимума, избежав анализа тупиковых и слабо нужных вещей, и исключив ошибки в анализе. Заодно сделав этим работу аналитика не такой нудной.
Скорее всего я прослыл из-за этого невежей и маньяком (человеком со странностями). Но, т.к. все-таки члены сообщества помогали мне в моих блужданиях в потемках, я попытаюсь сделать выводы и изложить результаты своих исканий.Есть шансы что я изложу известные многим очевидные вещи, но это только поможет мне укрепиться в том что я сделал верные выводы и чему-то научился, а более опытные товарищи смогут прийти к заключению что смогли ответить на мои каверзные вопросы и разъяснить мне невеже самую суть анализа.
Результатом моих исканий стало описание процесса который дает гарантированный результат с минимумом лишних телодвижений и максимумом полезных продуктов анализ.
И так, общий алгоритм "хорошего" анализа:
1) Определить основную цель проекта.
2) Выделить бизнес требования.
3) Переформулировать требования в виде проблем.
4) Определить степень влияния проблем на достижимость цели.
5) Ранжировать проблемы по важности.
6) Переформулировать проблемы ввиде противоречий (например, применив ТРИЗ).
7) Разрешить противоречия (например, с помощью ТРИЗ).
8) Оценить найденные решения.
9) Согласовать бюджет и скорректировать или исключить часть решений.
10) Переформулировать решения в требования. (Получатся требования удовлетворяющие критериям хороших требований).
11) Применить приемы анализа к получившемуся набору требований.Можно применить на всех уровнях декомпозиции требований, с некоторыми корректировками.
Хотелось бы узнать ваши комментарии и позицию который вы придерживаетесь относительно данного поста:
а) На ваш взгляд, я изобрел велосипед. (Если да, то где про него можно почитать?)
б) Вы это и так всегда знали это абсолютно очевидно просто никогда так не формализовывали, т.к. это не нужно, потому что знания которые нужны аналитику и так приводят к такому порядку действий.
в) Для вас это не было очевидным, но что-то в этом есть.
г) На ваш взгляд это полная хрень (слишком долго и проще перебирать возможные варианты и сделать как обычно или что-то в таком роде).Привет, Phyro,Я считаю, что это вариант г (но без пояснения в скобках), только без обид.
Во-первых, вы исходите из ложных предпосылок:
- в процессе работы над требованиями все аналитики неизбежно тратят время на анализ тупиковых и слабо нужных вещей
- работа аналитика нуднаВо-вторых, не установив причину проблемы, вы пытаетесь найти некий универсальный способ ее решения, который будет работать для всех аналитиков на всех проектах. Как говорится, "Если все, что у тебя есть, это молоток, любая проблема начинает выглядеть как гвоздь." В то же время проблема, о которой вы рассуждаете, может быть вызвана разными причинами: низкая квалификация аналитика, незнание предметной области, недостаточный технический бэкграунд, неправильно поставленный процесс сбора требований и т.д. и т.п., и, следовательно, требует разных решений.
В-третьих, в вашем алгоритме намешаны общие рекомендации и частные методологии. Само понятие "противоречие" относится к области ТРИЗ (ну или к диалектике, но сомневаюсь, что вы имели ввиду именно ее). ТРИЗ — это не универсальный прием, которым нужно руководствоваться всегда и везде. Я понимаю, что доклад на аналитической встрече произвел на вас впечатление
, однако не стоит забывать, что у любой методологии помимо сильных сторон есть и слабые, а ТРИЗ — не исключение. Об этом можно почитать подробнее, погуглив, например, "критика ТРИЗ". Ну и в конечном счете, если отбросить все лишнее, получается:
1) Наметить цель
2) Выявить и оценить проблемы
3) Найти причины проблем
4) Устранить причины проблем
5) Достигнуть цели.
А это уже смахивает на велосипед, о котором можно почитать в принципе если не в каждой первой книге по анализу, так в каждой второй.К тому же если даже отбросить все вышеперечисленное, алгоритм отвечает на вопрос "что надо делать", а не "как именно надо действовать", т.е. никак не страхует от анализа тупиковых ветвей.
Ну если бы я собирался обижаться — г) я бы не прделогал.На счет "как" — не согласен. Как раз таки там и приведен ТРИЗ как пример "как".
И в том то и проблема, что если сводить все к последовательности вами описанной, то нарвемся на типичные проблемы которые возникают по тем причинам которые вы описали: квалификация и контекст. А это сужает возможности. Потому что они описывают абстрактный алгоритм который подходит вообще к любой задаче. А меня интересует конкретная инструкция конкретно для аналитика.P.S> Основную причины я нашел: не знание когда остановиться, и потенциальное не знание в какую сторону повернуть решение (т.к. мы не знаем решение пока его не знаем).
И так, общий алгоритм "хорошего" анализа:
1) Определить основную цель проекта.
2) Выделить бизнес требования.
3) Переформулировать требования в виде проблем.
4) Определить степень влияния проблем на достижимость цели.
5) Ранжировать проблемы по важности.
6) Переформулировать проблемы ввиде противоречий (например, применив ТРИЗ).
7) Разрешить противоречия (например, с помощью ТРИЗ).
8) Оценить найденные решения.
9) Согласовать бюджет и скорректировать или исключить часть решений.
10) Переформулировать решения в требования. (Получатся требования удовлетворяющие критериям хороших требований).
11) Применить приемы анализа к получившемуся набору требований.Привет, phyro,
есть пару замечаний…Какова конечная цель работы аналитика? ИМХО, найти решения, удовлетворяющие требованиям.
Исходя из этого, на шаге 3) не обязательно искать проблемы. Если аналитик знает готовое решение, которое удовлетворяет требованиям, то на этом его работа может успешно завершиться. Я как раз рассказывал в докладе на SEF.BY-2011 про патеррны решений и решения 1 рода — готовые решения. Один из критериев уровня аналитика является объем его опыта, другими словами, количество паттернов (типовых решений), которыми он владеет.А что делать, если решение 1-го рода не удовлетворяет требованиям? Точнее, каким-то требованиям оно по-любому удовлетворяет, а каким-то — нет. Собственно, именно такую ситуацию следует называть проблемой. Это важно: проблемы в работе аналитика появляются не всегда! Но когда проблема появилась, то требуется решение 2-го рода — решение, которое позволит устранить противоречие.
Оценка полученных решений. Решение 1-го рода оценить очень просто: это, как правило, стандарт или, в лучшем случае, best business practice. Решение 1-го рода будет плохим только в том случае, если известно лучшее решение.
С решениями 2-го рода ситуация несколько другая. Такое решение хорошее уже хотя бы потому, что оно позволяет устранить проблему. Еще один критерий — цена вопроса. Важно не просто устранить противоречие, а найти такое решение, которое позволяет устранить противоречие при минимальных изменениях в системе. ИМХО, высший пилотаж аналитика — не просто устранить проблему, но найти идеальное решение: все осталось почти (!) без изменений, а проблемы нет (это АРИЗ).Как-то так.
В-третьих, в вашем алгоритме намешаны общие рекомендации и частные методологии. Само понятие "противоречие" относится к области ТРИЗ (ну или к диалектике, но сомневаюсь, что вы имели ввиду именно ее). ТРИЗ — это не универсальный прием, которым нужно руководствоваться всегда и везде. Я понимаю, что доклад на аналитической встрече произвел на вас впечатление
, однако не стоит забывать, что у любой методологии помимо сильных сторон есть и слабые, а ТРИЗ — не исключение. Об этом можно почитать подробнее, погуглив, например, "критика ТРИЗ".
Браво, Belle Morte,
меня до сих пор подташнивает, когда я почитываю какие-нибудь статьи или дискуссии людей, обсуждающих ТРИЗ. Без прикола! Восторженные фантики ТРИЗ очень напрягают… К критикам ТРИЗ это относится в такой же степени.Однако идеи, которые положены в основы ТРИЗ, — это правильные идеи. Косвенное подтверждение тому — Теория ограничений (Theory of Constraints) Голдратта. Совершенно независимо от Альтшуллера (тогда не было Интернета) человек занимался созданием методологии для решения проблем, нащупал понятие конфликта (противоречие), построения и анализа причинно-следственных отношений и т.д.
Простите, дорогой phyro, но я также за вариант Г. Хорошо, что Вы такой необидчивый Сейчас поясню, но хочу сразу оговориться — я не аналитик, я просто слежу за этими рассуждениями с самого начала и успела уже не раз запутаться и распутаться
И пока я еще раз не запуталась, давайте вместе посмотрим. Ваша постановка вопроса: "как поднять продуктивность аналитика до максимума, избежав анализа тупиковых и слабо нужных вещей, и исключив ошибки в анализе. Заодно сделав этим работу аналитика не такой нудной." даже в этой версии многих бы сбила с толку. В ней много допущений:
что максимум продуктивности аналитика достигается отбрасыванием всего "лишнего";
что это "лишнее" можно распознать и отбросить на начальных этапах;
что отбрасывание этого "лишнего" и отсутствие ошибок в анализе плотно коррелируют;
что работа аналитика _такая_нудная_;
что отбрасывание "лишнего" и исключение ошибок гарантируют веселье
А теперь позвольте ни с одним из допущений не согласиться:
продуктивность, как уже не раз указывали, вещь очень многофакторная, и она очень в слабой степени зависит от количества работы, которую нужно выполнить (а "отбрасывание лишнего" я понимаю здесь просто как сокращение этого самого количества, ибо критерии "лишнего" туманны — см. далее);
распознать и отбросить "лишнее" сразу — я не представляю возможным, если опираться на выдвинутый Вами ранее критерий "будет/не будет реализовано". С этаким критерием мне представился заказчик, перебирающий карточки с написанными на них требованиями: "О, хорошее требование — реализуем, а это плохо требование — не будем." Но это ведь совсем не так происходит, нет линейной зависимости, нет и определения "хорошего" требования;
отбрасывание лишнего — не залог отсутствия ошибок;
работа аналитика вовсе не нудная;
ошибки и есть веселье, а главное их исправление и преодоление проблем ("Oh my God, I made a mistake and by being corrected I learned something!") — этот опыт как раз влияет на будущую продуктивность и, пожалуй, может быть важнее "гарантированных описаний".Этот опыт есть основа для "гарантированного результата с минимумом лишних телодвижений", тогда как Ваш алгоритм анализа с многочисленными переформулированиями — множит сущности (требования, они же проблемы, они же противоречия, они же что там еще), создавая больше телодвижений — вероятность лишних среди них повышается, как и повышается вероятность ошибок. Кстати, а не сделает ли "универсальный способ" работу более нудной?
Еще кстати, пункт 3 — Переформулировать требования в виде проблем — я не совсем понимаю. Далеко не всякое требование представляет собой проблему. (Проблема вообще слово очень скользкое, а в английском гораздо более весомое, чем мы привыкли. Моё живое воображение тут же нарисовало такого паникёра в рамках Вашего алгоритма: "Божемойбожемой, куда же поместить чекбокс, двумя пикселями правее или двумя пикселями левее? Вот так противоречие: лево или право. Решение: как Бог на душу положит. "Хорошее" требование: поместить куда-нибудь чекбокс. Ффух." Простите, простите, увлеклась
)Вы мне с этой задачей напомнили абсолютников из "Понедельник начинается в субботу", которые раздавали задачи, для которых доказано отсутствие решения.
Помните?
" — Г-голубчики, — сказал Федор Симеонович озадаченно, разобравшись в почерках. — Это же п-проблема Бен Б-бецалеля. К-калиостро же доказал, что она н-не имеет р-решения.
— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как ее решать.
— К-как-то ты странно рассуждаешь, К-кристо… К-как же искать решение, к-когда его нет? Б-бессмыслица какая-то…
— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идет о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос, который, как я вижу, тебе, прикладнику, к сожалению, не доступен. По-видимому, я напрасно начал с тобой беседовать на эту тему."А я, честно говоря, вообще слабо понял о чем идет речь Наверное, нужно очень вдумчиво перечитать эту дискуссию в другой ветке, но я честно и искренне как-то пытался это сделать и не осилил.
Что же касается чисто аргументов в этой теме, а можно уточняющий вопрос — какие лишние телодвижения были отброшены? Просто без предисловия и не вдаваясь в детали каждого отдельного этапа приведенного процесса, алгоритм вполне логичный и правильный. И таки да, это по большей части — изобретение велосипеда. Гораздо интереснее узнать, что же было сочтено тупиковыми шагами и выкинуто из процесса…2 Hawkeye
в некоторых местах хочу не согласиться.продуктивность, как уже не раз указывали, вещь очень многофакторная, и она очень в слабой степени зависит от [i]количества[/i] работы, которую нужно выполнить (а "отбрасывание лишнего" я понимаю здесь просто как сокращение этого самого количества, ибо критерии "лишнего" туманны — см. далее);
продуктивность = результаты / количество работы. Поэтому продуктивность очень даже сильно зависит от количества работы. Соответственно, уменьшение количества работы — это один из способов повышения продуктивности. Я бы даже сказал, самый основной способ, так как количество результатов в работе аналитика устанавливается заказчиком, т.е., в нашем случае это внешняя константа.
Следовательно, максимальную продуктивность мы можем получить путем минизмизации количества работы. Возникает вопрос: КАК?
Оригинальный ответ — не делать лишней работы, т.е. сделать все правильно с первого раза
работа аналитика вовсе не нудная;
ошибки и есть веселье, а главное их исправление и преодоление проблем ("Oh my God, I made a mistake and by being corrected I learned something!") — этот опыт как раз влияет на будущую продуктивность и, пожалуй, может быть важнее "гарантированных описаний".Этот опыт есть основа для "гарантированного результата с минимумом лишних телодвижений", тогда как Ваш алгоритм анализа с многочисленными переформулированиями — множит сущности (требования, они же проблемы, они же противоречия, они же что там еще), создавая больше телодвижений — вероятность лишних среди них повышается, как и повышается вероятность ошибок. Кстати, а не сделает ли "универсальный способ" работу более нудной?
Из-за некоторых ошибок еда в магазинах пропадает…
А еще ошибки приносят опыт "как не надо делать"; уверяю вас, опыта "как надо делать" ошибки не прибавляют. Не знаю, где вы тут нашли веселье; здесь же сплошная печаль
Еще кстати, пункт 3 — Переформулировать требования в виде проблем — я не совсем понимаю. Далеко не всякое требование представляет собой проблему. (Проблема вообще слово очень скользкое, а в английском гораздо более весомое, чем мы привыкли. Моё живое воображение тут же нарисовало такого паникёра в рамках Вашего алгоритма: "Божемойбожемой, куда же поместить чекбокс, двумя пикселями правее или двумя пикселями левее? Вот так противоречие: лево или право. Решение: как Бог на душу положит. "Хорошее" требование: поместить куда-нибудь чекбокс. Ффух." Простите, простите, увлеклась
)Вы мне с этой задачей напомнили абсолютников из "Понедельник начинается в субботу", которые раздавали задачи, для которых доказано отсутствие решения.
Помните?
" — Г-голубчики, — сказал Федор Симеонович озадаченно, разобравшись в почерках. — Это же п-проблема Бен Б-бецалеля. К-калиостро же доказал, что она н-не имеет р-решения.
— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как ее решать.
— К-как-то ты странно рассуждаешь, К-кристо… К-как же искать решение, к-когда его нет? Б-бессмыслица какая-то…
— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идет о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос, который, как я вижу, тебе, прикладнику, к сожалению, не доступен. По-видимому, я напрасно начал с тобой беседовать на эту тему."А вот за тему из Стругатских отдельное спасибо. Очень даже в тему получилось
2 Hawkeye
в некоторых местах хочу не согласиться.Пожалуйста
продуктивность = результаты / количество работы. Поэтому продуктивность очень даже сильно зависит от количества работы. Соответственно, уменьшение количества работы — это один из способов повышения продуктивности. Я бы даже сказал, самый основной способ, так как количество результатов в работе аналитика устанавливается заказчиком, т.е., в нашем случае это внешняя константа.
Следовательно, максимальную продуктивность мы можем получить путем минизмизации количества работы. Возникает вопрос: КАК?
Оригинальный ответ — не делать лишней работы, т.е. сделать все правильно с первого раза Уф, кажется, Вы меня пытаетесь запутать
Продуктивность — она же производительность — труда есть время, затраченное на единицу продукции (или, соответственно, количество продукции за единицу времени), так что — неа, практически не зависит от объема (только психологические и психофизиологические факторы). А по Вашей формуле как-то не могу подсчитать: дали рабочему 10 заготовок, он сделал 10 деталей, 10/10 равно продуктивность единица 
Если бы был алгоритм "как сделать всё правильно с первого раза", существовала бы вообще тогда профессия аналитика и многие другие?
Из-за некоторых ошибок еда в магазинах пропадает…
А еще ошибки приносят опыт "как не надо делать"; уверяю вас, опыта "как надо делать" ошибки не прибавляют. Не знаю, где вы тут нашли веселье; здесь же сплошная печаль Ну я потому и уточнила — "их исправление и преодоление проблем", но вообще Вы правы, я хотела просто подчеркнуть положительную сторону, а вместо этого выделила её жирным. Естественно, цена некоторых ошибок такова, что никакой опыт уже не утешит. Но я плохо представляю ошибки такого масштаба в рамках вопроса "избежать анализа слабо нужных вещей".
А вот за тему из Стругатских отдельное спасибо. Очень даже в тему получилось
Пожалуйста, у меня эта тема просто в голове крутилась с того момента, как Игорь это на встрече стал излагать
Тааак. Вы решили взорвать мне несколько раз мозг? (:Производи́тельность труда́ — мера (измеритель) эффективности труда. Производительность труда может измеряться количеством времени, затрачиваемым на единицу продукции либо количеством продукции, выпущенной работником за какое-то время.
…
Под ростом производительности труда подразумевается экономия затрат труда (рабочего времени) на изготовление единицы продукции или дополнительное количество произведенной продукции в единицу времени, что непосредственно влияет на повышение эффективности производства, так как в одном случае сокращаются текущие издержки на производство единицы продукции по статье «Заработная плата основных производственных рабочих», а в другом — в единицу времени производится больше продукции.
…
Фактическая производительность труда (выработка) обратно пропорциональна трудоёмкости и определяется из непосредственно наблюдаемых данных по формуле:
Pfact = Qfact / Tfact, где Qfact — фактический выпуск продукции в единицах измерения данного вида продукции, Tfact — фактические затраты живого труда в единицах времени.Взято из Википедии.
Просто из математики следует, что P возрастает, когда Q уменьшается, либо T уменьшается.
Q — это то, что у аналитика на выходе. Причем стоит различать количество (кол-во артефактов на выходе и их объем) и качество (насколько это было нужно для достижения цели). Ведь аналитик может выпустить 10 документов по 1000 страниц каждый. Это выход? Выход.. У него заказчик это запрашивал? Предположим, да. А теперь пусть другой аналитик выпустит 1 документ на 50 страничек для того же проекта и того же заказчика и потом объяснит и убедит заказчика, что этого достаточно (и пусть это будет действительно так). В количественном плане у них гигантская разница с явным перевесом первого аналитика. В качественном — сами понимаете.
T — это затраченное на это всё время. Тут важно понимать, что это _ВСЁ_ время, а не только время, затраченное этим аналитиком. Ведь если он параллельно напряг 5 девелоперов, 2 тестеров, 1го менеджера и 0.5 заказчика (щютка) на 1 человеко-месяц, и сам ещё 2 недели работал, то равнозначно ли это временнЫм затратам второго аналитика, который сделал всё сам за 3 недели с тем же уровнем качества? (м-да, и, кстати, я бы сюда добавил все виды затрат, а не только временнЫе)Вот.. надеюсь, мысль донёс (:
А по поводу порассуждать вместе с Игорем.. я бы лучше вживую, а то вижу, что как-то мы все от темы отклоняемся (:[quote="AndrewK"]продуктивность = результаты / количество работы. Поэтому продуктивность очень даже сильно зависит от количества работы. Соответственно, уменьшение количества работы — это один из способов повышения продуктивности. Я бы даже сказал, самый основной способ, так как количество результатов в работе аналитика устанавливается заказчиком, т.е., в нашем случае это внешняя константа.
Следовательно, максимальную продуктивность мы можем получить путем минизмизации количества работы. Возникает вопрос: КАК?
Оригинальный ответ — не делать лишней работы, т.е. сделать все правильно с первого раза Уф, кажется, Вы меня пытаетесь запутать
Продуктивность — она же производительность — труда есть время, затраченное на единицу продукции (или, соответственно, количество продукции за единицу времени), так что — неа, практически не зависит от объема (только психологические и психофизиологические факторы). А по Вашей формуле как-то не могу подсчитать: дали рабочему 10 заготовок, он сделал 10 деталей, 10/10 равно продуктивность единица [/quote]Это Вы пытаетесь меня запутать
Давайте возьмем хорошего и плохого аналитика с одинаковой скоростью работы (физиологические факторы). Хороший аналитик произведет результат с первой попытки. Плохой аналитик сделает 10 вариантов, чтобы получить такой же результат. Т.е., ему потребуется для получения результата сделать в 10 раз больше работы. Следовательно, продуктивность у хорошего аналитика в 10 раз выше, чем у плохого. Хотя, похоже, у рабочих с деталями все по-другому… Фигня какая-то получается 
Если бы был алгоритм "как сделать всё правильно с первого раза", существовала бы вообще тогда профессия аналитика и многие другие?
Отличный вопрос! Люди, которые знают алгоритм, как сшить правильные сапоги с первого раза, называются сапожниками. Почему бы аналитикам не иметь алгоритма, как произвести правильный результат с первого раза? Тем более, такой алгоритм есть. Смотрите!!! Аналитиков c сапожниками объединяет наличие алгоритма, а с рабочими у аналитиков ничего общего…
[quote="AndrewK"]Из-за некоторых ошибок еда в магазинах пропадает…
А еще ошибки приносят опыт "как не надо делать"; уверяю вас, опыта "как надо делать" ошибки не прибавляют. Не знаю, где вы тут нашли веселье; здесь же сплошная печаль Ну я потому и уточнила — "их исправление и преодоление проблем", но вообще Вы правы, я хотела просто подчеркнуть положительную сторону, а вместо этого выделила её жирным. Естественно, цена некоторых ошибок такова, что никакой опыт уже не утешит. Но я плохо представляю ошибки такого масштаба в рамках вопроса "избежать анализа слабо нужных вещей".[/quote]
"Делать ошибки, а потом их исправлять и преодолевать проблемы" — интересная тактика. Конечно, разбираться со своими ошибками и проблемами гораздо удобнее, чем с проблемами заказчика. Скажите, и много платят?
Вы ошибаетесь в тех рассуждениях, которые у вас положены в основу:Люди, которые знают алгоритм, как сшить правильные сапоги с первого раза, называются сапожниками.
[code]Люди, которые знают алгоритм, как сшить сапоги с первого раза, называются сапожниками.[/code]
При этом они всегда шьют кирзовые сапоги, потому что считают это "правильным". Покупатели же каждый раз желают разные сапоги, потому что каждый покупатель имеет свои потребности и вкусы.[code]Люди, которые знают, как объяснить сапожнику, какие "правильные" сапоги нужно сшить, называются дизайнерами/модельерами. [/code]
Потому что они могут изучить покупателя, выявить его потребности и вкусы, а самые лучшие — сформировать вкусы и выявить скрытые потребности.
Сапожник и модельер могут быть одним человеком, но это либо высший пилотаж, либо неэффективное (не)разделение труда.А от таких, которые считают, что главное производительность (то есть Q и T), у нас многие магазины никому не нужным дерьмом завалены.
Без обид.
Почему бы аналитикам не иметь алгоритма, как произвести правильный результат с первого раза?
Потому что аналитик — профессия творческая. А основная характеристика творческой деятельность — невозможность ее алгоритмизировать. В противном случае деятельность такого рода давно бы уже выполняли машины.
Вы ошибаетесь в тех рассуждениях, которые у вас положены в основу:
[quote]Люди, которые знают алгоритм, как сшить правильные сапоги с первого раза, называются сапожниками.[code]Люди, которые знают алгоритм, как сшить сапоги с первого раза, называются сапожниками.[/code]
При этом они всегда шьют кирзовые сапоги, потому что считают это "правильным". Покупатели же каждый раз желают разные сапоги, потому что каждый покупатель имеет свои потребности и вкусы.[code]Люди, которые знают, как объяснить сапожнику, какие "правильные" сапоги нужно сшить, называются дизайнерами/модельерами. [/code]
Потому что они могут изучить покупателя, выявить его потребности и вкусы, а самые лучшие — сформировать вкусы и выявить скрытые потребности.
Сапожник и модельер могут быть одним человеком, но это либо высший пилотаж, либо неэффективное (не)разделение труда.А от таких, которые считают, что главное производительность (то есть Q и T), у нас многие магазины никому не нужным дерьмом завалены.
Без обид.[/quote]
Дались вам эти сапожники… Это была метафора.
Всем отдельное сори за то что в моем мире слово "невозможно" встречается только рядом со словами "за эти деньги".
Поэтому я позволю себе не согласиться с иронией Стругацких.Belle Morte, я изначально сильно уважаю за объем того что она прочитала (судя по всему). Но мое представление об этом объеме противоречит с ее последним выводом.
Наука появляется когда есть объяснение. А искусство появляется через эмпирический опыт без попытки объяснить. Искусство есть там где наука близорука.
Вспомним просто Леонардо Да Винчи. Помолчим и подумаем.Алгоритм неказистый согласен. Но есть пару замечаний которые ввели меня в недоумение:
"В-третьих, в вашем алгоритме намешаны общие рекомендации и частные методологии." Почему? И где конкретно? И что в этом собственно плохого? Зачем раскрывать общие рекомендации методологии для которых очевидны и прятать методологии там где они определяют суть?
Зашем такой алгоритм? (простите я программист. мне очень сложно понять зачем писать код там где есть готовые стандарные библиотеки которые постояннор используются и игнорировать места где нужен тюнинг или подбор специфической либы?).Маленькое разъяснение: Я не пользуюсь ТРИЗ и тем более не фанат. Хотя меня кое что заинтересовало из того что я про него не знал во время доклада. Просто это одно из возможных решений (либа для алгоритма которая соблюдает интерфейс), которое знакомо аудитории, почему бы его не упомянуть как пример (только пример — в скобочках).
Меня просто слегка удивила позиция AndrewK: "Браво, Belle Morte, меня до сих пор подташнивает,". Либо я ее не понял. Либо оч конркетно не поняли меня.
Вы должны авторизироваться для ответа в этой теме.
