Кто ж спорит? Только вы и в первом и во втором примере озвучили какие-то сроки. А здесь речь идёт об избегании указания сроков. Это может сработать, когда приходишь к специалисту с редкой профессией и хочешь от него получить что-то когда-то в будущем, но не важно, когда именно. Картину, например, заказываешь у кого-то конкретного. Вот договорился с ним, денег заплатил, а дальше художник может через неделю прийти с результатом, а может через два года.
Отчего же, тоже подход. Главное не заниматься чем-нибудь вроде организации свадеб, доставки билетов, запусков рекламных кампаний или разработки проектов под конкретные события.
Когда я приезжаю на автосервис, с меня берут несколько тысяч рублей за диагностику. Это что-то сродни проектированию интерфейсов. Сначала разобраться в задаче и прикинуть её решение. И только потом браться за работу.
Вашу позицию я понял. Вы очень уверенно рассуждаете. Сами связаны с разработкой информационных систем?
Представляю: приходит ко мне очередной клиент за cms, crm или erp системой. Или за каким-нибудь приложением для мониторинга чего-нибудь. Или за каким-нибудь рекламным кабинетом на свой проект. И я такой: ща шаблон за копейки найдём — и за три дня всё будет готово :)
По времени нет точного ответа, иногда отвлекался и делал перерывы. К редакторам не обращался. С редактурой помог друг Антон Григорьев, отдельный профессиональный бета-ридер, а также я сам не боялся относиться к своему труду как к финальному (особенности профессии проектировщика интерфейсов) и можно сказать выступил редактором собственного результата. В день тратил не больше полутора часов.
У Продамуса 10 000 за интеграцию. А я за всё время продал книг на 10 000. Не та ниша, где стоит заморачиваться. За всё время у меня только одна продажа за пределы России.
Нет, не пробовал. У меня основной задачей было написать книгу. О трудностях, с которыми я столкнусь при форматировании и редактуре, я ещё не догадывался. Но в целом результат получился приемлемым и без дополнительных софтин. А вот к следующей книге подойду уже немного по-другому. Из всего, что вы перечислили, для меня на текущий момент самой ценной будет поддержка версионирования через гит.
Автор подобных фраз был бы должен исследовать рынки фриланса — Российский и зарубежный — в разных отраслях (IT, рукоделие, консалтинг и так далее). А я просто делюсь своим опытом.
Я тот человек, к которому приходит клиент за формулированием функциональных требований к стартапам (и не только). Сформулированные функциональные требования — это не спроектированный проект. Проектирование — это процесс, результат которого сильно расплывчат (иначе это бы не называлось проектированием). Фишка в том, что даже если бы я был тем супермозгом, который по короткому описанию может смоделировать в голове сразу готовую систему (а ко мне иногда обращаются и за ERP-системами на несколько сотен экранов), то дальше мне всё равно пришлось бы проделать ооочень трудоёмкую работу, у которой две цели: — Ознакомить клиента с моей моделью и согласовать её; — Описать эту модель достаточно подробно, чтобы разработчики могли сделать оценку.
И вот только после того, как появится проектная документация, из которой всем становится ясно, что клиент собирается разрабатывать, можно сделать оценку разработки.
Да не, нормальный коммент. Технически всё, о чём я пишу, — очевидно для меня. Поэтому, если бы меня это останавливало, то никаких обучающих материалов я бы не создавал.
Но в данном случае я личным опытом поделился, а не какими-то правилами. Возможно, в комментарии придут те, чей опыт отличается от моего, и мы все станем чуточку умнее.
Зачем написал? Чтобы те, кто расстраиваются от того, что их прототипы уходят «в стол», поменьше расстраивались :)
Там такое определение: «3.1 услуга торговли: Результат взаимодействия продавца и покупателя, а также собственная деятельность продавца по удовлетворению потребностей покупателя при покупке и продаже (реализации) товаров».
— Окажите мне услугу, продайте стакан лимонада, пожалуйста. — Пожалуйста, с вас 30 рублей. Только это не услуга. Это я вам товар продал.
В общем, без пол-литра не разберёшься :) Задача главы — объяснить, что лично я вкладываю в термины простых и сложных услуг, т.к. использую их дальше в книге. Ничего страшного, если я ошибаюсь в общепринятой терминологии, главное передать смысл.
То есть, я не оказываю услугу по проектированию интерфейсов, а продаю товары: интерактивные прототипы? А человек, который наливает лимонад в стакан, не оказывает услугу по обслуживанию клиента, обратившегося за лимонадом, а продаёт ему товар?
В договоре не указываете никаких сроков работ?
Кто ж спорит? Только вы и в первом и во втором примере озвучили какие-то сроки. А здесь речь идёт об избегании указания сроков. Это может сработать, когда приходишь к специалисту с редкой профессией и хочешь от него получить что-то когда-то в будущем, но не важно, когда именно. Картину, например, заказываешь у кого-то конкретного. Вот договорился с ним, денег заплатил, а дальше художник может через неделю прийти с результатом, а может через два года.
Отчего же, тоже подход. Главное не заниматься чем-нибудь вроде организации свадеб, доставки билетов, запусков рекламных кампаний или разработки проектов под конкретные события.
Когда я приезжаю на автосервис, с меня берут несколько тысяч рублей за диагностику. Это что-то сродни проектированию интерфейсов. Сначала разобраться в задаче и прикинуть её решение. И только потом браться за работу.
Вашу позицию я понял. Вы очень уверенно рассуждаете. Сами связаны с разработкой информационных систем?
Представляю: приходит ко мне очередной клиент за cms, crm или erp системой. Или за каким-нибудь приложением для мониторинга чего-нибудь. Или за каким-нибудь рекламным кабинетом на свой проект. И я такой: ща шаблон за копейки найдём — и за три дня всё будет готово :)
Главный по Фигме у нас уже есть — это Алексей Бычков. Прекрасные обучающие материалы. Вот его канал.
По времени нет точного ответа, иногда отвлекался и делал перерывы. К редакторам не обращался. С редактурой помог друг Антон Григорьев, отдельный профессиональный бета-ридер, а также я сам не боялся относиться к своему труду как к финальному (особенности профессии проектировщика интерфейсов) и можно сказать выступил редактором собственного результата. В день тратил не больше полутора часов.
У Продамуса 10 000 за интеграцию. А я за всё время продал книг на 10 000. Не та ниша, где стоит заморачиваться. За всё время у меня только одна продажа за пределы России.
Спасибо!
Нет, не пробовал. У меня основной задачей было написать книгу. О трудностях, с которыми я столкнусь при форматировании и редактуре, я ещё не догадывался. Но в целом результат получился приемлемым и без дополнительных софтин. А вот к следующей книге подойду уже немного по-другому. Из всего, что вы перечислили, для меня на текущий момент самой ценной будет поддержка версионирования через гит.
Печатная книга — это то, над чем я буду работать до конца этого года. Её ещё не существует.
О, да!
Автор подобных фраз был бы должен исследовать рынки фриланса — Российский и зарубежный — в разных отраслях (IT, рукоделие, консалтинг и так далее). А я просто делюсь своим опытом.
Я тот человек, к которому приходит клиент за формулированием функциональных требований к стартапам (и не только). Сформулированные функциональные требования — это не спроектированный проект. Проектирование — это процесс, результат которого сильно расплывчат (иначе это бы не называлось проектированием). Фишка в том, что даже если бы я был тем супермозгом, который по короткому описанию может смоделировать в голове сразу готовую систему (а ко мне иногда обращаются и за ERP-системами на несколько сотен экранов), то дальше мне всё равно пришлось бы проделать ооочень трудоёмкую работу, у которой две цели:
— Ознакомить клиента с моей моделью и согласовать её;
— Описать эту модель достаточно подробно, чтобы разработчики могли сделать оценку.
И вот только после того, как появится проектная документация, из которой всем становится ясно, что клиент собирается разрабатывать, можно сделать оценку разработки.
Да не, нормальный коммент. Технически всё, о чём я пишу, — очевидно для меня. Поэтому, если бы меня это останавливало, то никаких обучающих материалов я бы не создавал.
Но в данном случае я личным опытом поделился, а не какими-то правилами. Возможно, в комментарии придут те, чей опыт отличается от моего, и мы все станем чуточку умнее.
Зачем написал? Чтобы те, кто расстраиваются от того, что их прототипы уходят «в стол», поменьше расстраивались :)
Пол-литра затем, что есть, например, такой ГОСТ, про услуги торговли: https://gostassistent.ru/doc/9ed4aa8b-0945-4547-ac55-c461bcf117d7?ysclid=lcon5c3t64694808068
Там такое определение: «3.1 услуга торговли: Результат взаимодействия продавца и покупателя, а также собственная деятельность продавца по удовлетворению потребностей покупателя при покупке и продаже (реализации) товаров».
— Окажите мне услугу, продайте стакан лимонада, пожалуйста.
— Пожалуйста, с вас 30 рублей. Только это не услуга. Это я вам товар продал.
В общем, без пол-литра не разберёшься :) Задача главы — объяснить, что лично я вкладываю в термины простых и сложных услуг, т.к. использую их дальше в книге. Ничего страшного, если я ошибаюсь в общепринятой терминологии, главное передать смысл.
А про лимонад? Обслуживание клиента на кассе — это ведь всё-таки услуга, а не товар?
То есть, я не оказываю услугу по проектированию интерфейсов, а продаю товары: интерактивные прототипы? А человек, который наливает лимонад в стакан, не оказывает услугу по обслуживанию клиента, обратившегося за лимонадом, а продаёт ему товар?
Интерактивный прототип или документация — это тоже товар?