Обновить
22
0
Anton MegaPort @AlexTest

Magento, Telegram bots

Отправить сообщение
Извинение принято.
У вас по прежнему каша в голове — вы слишком сумбурно излагаете свои мысли, задаете странные вопросы типа:
Чем покупка сотового телефона отличается от заказа услуг фрилансеров?
На которые не может быть конкретного ответа, да что там конкретного — разумного ответа дать нельзя.
Ваша проблема именно в этом — вы не знаете какие конкретно вопросы надо задавать заказчику, чтобы и вы и он сам понял чего же на самом деле он хочет. Без перехода к конкретной ситуации (да хотя бы уточните специализацию вашего абстрактного фрилансера) фантазировать можно бесконечно долго.
И да — ТЗ обязательно нужно делать в том или ином виде, хотя бы для того, чтобы у заказчика и исполнителя было обоюдное понимание относительно самого главного вопроса: когда задача (или задачи) из ТЗ признается заказчиком выполненной.
Давай по порядку.
Мы почему-то уже «на ты» — ок, ладно.

Я объединил услугу и товар по критерию: за все исполнитель получит деньги.
Бред какой-то написал. «Исполнитель услуги» — это я понимаю, «исполнитель товара» — это мне не понятно.

А вообще, перестань фантазировать и придумывать абстрактные ситуации для реальных и тем более таких рутинных операций как покупка еды или сотовых телефонов и уж тем более сравнивать их с продажей услуг.
Хочешь обсудить что-то конкретное и/или узнать как это делают другие — так и пиши статью о конкретной ситуации, в обсуждении конструктива будет больше!
Автор перепутал услугу с товаром.
У любой услуги есть критерии оценки, даже для того чтобы сказать сколько стоит убрать квартиру — надо знать количество комнат, площадь комнат, тип полового покрытия в каждой комнате и т.д. и т.п.
Т.е. продажа услуги сильно отличается от продажи готового товара и без обсуждения всех критериев оценки назвать даже приблизительную цену не получится.

А что касается ситуации в статье, то продавец в магазине не прячет от покупателей свои товары, как правило, все что есть в наличии — находится на полках и витринах и снабжено ценниками, ведь черт побери именно для этого и создаются магазины! И если покупатель не желает тратить много денег на ресторан, а хочет сэкономить и купить готовый к употреблению в пищу товар в магазине, то не стоит ожидать такого же самого сервиса как в ресторане с объяснением подробно по каждому блюду, у продавца просто нет столько времени на обслуживание каждого покупателя.
Таким образом, предполагается, что в магазине покупатель в состоянии сам осмотреть товары, ознакомиться с ценами и датами производства товаров, сделать свой выбор и оплатить выбранное на кассе. Если же он хочет просто потрахать мозги продавцу и заставить его вместо себя делать выбор да еще и читать ему все ценники и этикетки — то такой покупатель просто мудак, о чем его и должен культурно проинформировать вменяемый продавец, не вступать с ним в дальнейшие разговоры и продолжать обслуживать остальных адекватных клиентов.
Не проще. В разных реализациях-настройках рнр сессий на различных веб-серверах возможны проблемы блокировки сессий в такой ситуации, и это надо будет как-то «разруливать» так как: Session data is usually stored after your script terminated.
Вам достаточно первый раз отдавая страницу launcher.html клиенту проставить в ней уникальный ID для процесса и использовать его при запуске процесса и при запросе статуса, например прямо в URL: /process.php?id=ID и /status.php?id=ID, свой статус process.php сообщает в status.php используя этот же ID, а это состояние status.php может хранить в своей сессии также используя этот же ID. Причем передавать можно гораздо больше информации о состоянии процесса, ну там текущий шаг к примеру и сколько осталось по этому шагу и т.д. + ничего в настройках сервера и php связанного с буферизацией вывода менять не придется. В вашем варианте надо всегда настраивать конкретный сервер, а это далеко не всегда можно легко и просто сделать.
Вас не смущает, что весь этот файловый мусор потом надо будет как-то убирать?
Ваша реализация сильно зависит от настроек конкретного веб-сервера, где устанавливаются размеры буферов ответа, причем это может быть даже в нескольких местах — не хочу вдаваться в подробности.
Более «серверонезависимым» будет вариант когда клиент запускает одним ajax-запросом «тяжелый» php скрипт (назовем его process.php) и с помощью другого ajax-запроса в цикле проверяет прогресс, запрашивая второй php скрипт (назовем его status.php). Во время своей работы process.php с помощью curl (или любым другим способом) сообщает status.php свое состояние используя любой удобный вариант идентификации.
Такой вариант мне кажется намного надежнее, чем «борьба» с буферами ответа.
Интересно — этот % способных легко убивать себе подобных в человеческой популяции исторически постоянен, или несколькими веками ранее таких было намного больше, соответственно число психопатов в обществе было выше?
Если в последних войнах основные потери в армии скажем так от «дистанционного» оружия, и якобы можно не стрелять в сторону врага, то как быть с войнами где основной урон наносился холодным оружием в ближнем бою — там ведь нельзя было махать мечем мимо противника?
Получается наши предки были на всю голову отмороженными кровожадными психопатами убийцами?
Основная цель моего переговорного процесса — не влезать в fixed-price разработку без стадии прототипирования.
Вот в этом я полностью с вами согласен, fixed-price разработка без прототипа — это проблема как для заказчика так и для разработчика. Я смотрю на это в основном со своей «колокольни» вебразработки и давно уже понял, что без хотя бы fireframe макета сайта в fixed-price лучше не лезть! Вот написал недавно статью по довольно толковому инструменту, как мне кажется. Думаю нужно эту мысль (про предварительное прототипирование) всеми возможными способами продвигать т.с. в массы, как заказчиков так и исполнителей, показывая именно экономическую привлекательность такого подхода. Сейчас планирую написать еще одну статью по прототипированию вебсайтов именно с убеждающей логикой на примере прототипов в Google Презентациях. Хотел бы предложить вам ознакомится с черновиком статьи и дополнить его вашей аргументацией. Если у вас найдется на это желание и время — предлагаю продолжить общение в личных «диалогах» на хабре.
Пожалуйста:
Не квалифицированному клиенту сложно выбрать…
Квалифицированных клиентов не бывает, что и подтверждает ваша история про утюг, где в этом месте:
Я попросил продавца-консультанта объяснить мне разницу
вы попытались стать квалифицированным клиентом, и выяснили что это невозможно
голос продавщицы показался мне песней… на китайском языке
Но дальше вы рассказываете, как вы сами, по сути пытаетесь сделать из «не квалифицированного» клиента — квалифицированного.
Но это ему не нужно, ему к примеру нужен интернет-магазин и он хотел бы знать пресловутые «стоимость» и «срок». На самом деле его интересует именно стоимость т.к. срок просто влияет на этот параметр.
Точно так же как и в гипермаркете с утюгами — продажник называет вилку цен вашей компании: к примеру от 2000 до 100000 USD. Клиент просит объяснить разницу и точно так же слышит «песню на китайском языке» — знакомо?

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

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

Но к сожалению я попал на такого толкового продавца в гипермаркете только один раз за последние 30 лет, и именно в этом страшная правда. Таких квалифицированных продавцов на самом деле катастрофически мало! Так что ваше желание :
пристрелить отдел продаж
скоре всего вполне обосновано.
И каждый день им приходится бороться с кучей возражений клиентов из серии «а один подрядчик из Индии пообещал разработать точно такую-же систему в два раза быстрее и дешевле».
И как конкретно с этим возражением клиента борются продажники в вашей компании?
А вы статью полностью прочли?
Там все описано — это есть и называется компоненты, и у компонента гораздо больше возможностей.
Например на некоторых экранах можно перекрыть параметры компонента своими и теперь при изменении этих параметров в самом компоненте они будут меняться везде кроме тех случаев где они перекрыты локальными параметрами конкретного экрана.
В момент, когда я пишу этот материал, в работе 54 проекта и 426 задач.
Т.е. примерно всего по 8 задач на проект, может несколько больше т.к. часть проектов может быть на завершающей стадии — я правильно все понимаю?
Интересно было бы узнать более точное среднее число задач на один проект сайта в вашей фирме, но судя по всему оно не превышает 16 — я не могу в это поверить без пояснений.
Можете также предоставить список типовых задач по проекту для лучшего понимания того, что вы называете задачей?
Отработано часов: 30.93 из 32
0.93 часа это 55мин 48сек.
Вы вполне серьезно учитываете залогированное работниками время до сотых долей часа, т.е. до секунд?
Не хотел бы я работать в такой конторе!
я не совсем правильно в первом своем посте написал про Бернарда, он то конечно может дать на этом шаге правильный ответ, если Шерил сказала ему любое из чисел 15,16,17, т.к. они однозначно указывают на конкретный месяц: 15 и 17 на Август, а 16 на Июль. Т.е. возможны все три варианта на 4м шаге, и только если Бернарду было сказано 16 число, последнее утверждение Альберта может быть верным, подчеркиваю — именно МОЖЕТ БЫТЬ ВЕРНЫМ! Т.е. как я и писал выше в задачу надо добавить условие:
Выберите единственно возможную дату ДР, при которой заявления всех участников МОГУТ БЫТЬ ВЕРНЫ без учета их очередности во времени.
Т.е. задача имела бы единственное решение, если бы в условии было так:
Выберите единственно возможную дату ДР, при которой заявления всех участников верны без учета их очередности во времени.
4) Бернард, зная число, выбирает единственно правильный ответ и говорит, что знает дату ДР

Ну вот как на вашем 4-м шаге Бернард может дать единственно правильный ответ, зная только число и исключив два первых месяца?
Он ведь еще не услышал последней фразы Альберта (что Альберт тоже знает дату ДР)?
Как мне кажется в такой постановке эта задача на 4-м шаге для Бернарда не имеет решения, и он никак не может на этом шаге заявлять, что он знает решение — ему просто не хватает информации (той, что скажет Альберт в будущем)!
Но все остальное рассуждение строится именно на том, что уже на 4-м шаге Бернард знает правильный ответ, причем не только у вас.
Возможно я не прав, но я думаю, что задача в такой постановке просто не имеет решения (если учитывать очередность событий ).
пред. цитата отсюда megamozg.ru/post/2218

А вот еще одна dic.academic.ru/dic.nsf/econ_dict/22078:
ПРОКЛЯТЬЕ ПОБЕДИТЕЛЯ
(winner\'s curse) Опасность того, что победитель, выигравший контракт (contract), потеряет деньги на его выполнении. Если контракт заключается на основании конкурентных торгов (competitive tendering), победителем обычно является фирма, предложившая самую низкую цену. При оценке затрат могут быть допущены ошибки, а потому существует опасность, что победителем окажется фирма, которая сильно недооценит подлинную величину затрат и потеряет деньги в результате выполнения контракта

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность