Форум
Читайте нас также:

об электронной торговле - для интернет-магазинов и ритейла. портал и сообщество

Форум

Посыл разработчикам ИМ от неблагодарного пользователя



Ссылка на сообщение


learn and learn:

Но функционал, удобство пользователя (а значит и продажи), скорость работы и т.д. по примерам увидеть можно, верно? А пока все предлагают "джинсы в пакете" толкучек советских времён: заплатил, а там пол-штанины.


Здесь не все просто. Например, у нас есть несколько довольно продвинутых магазинов для риэлтерских компаний. Витрины этих магазинов похожи, функционал бэкофисов совершенно различный и создавался на заказ. По договору мы не можем рассказывать о том, какие именно заказные бизнес-процессы поддерживаются и как именно, т.к. это приватная информация компаний.

Поэтому по функционалу заказных решений показать можно очень немногое, а функционал стандартных решений не особенно интересен - там есть все обычные средства для работы с каталогом, товарами, заказами, информационными разделами, покупателями и т.п. Все основано на заполнении форм, на удобство никто не жаловался. Кстати, в заказных решениях все это еще можно и дорабатывать, если требуется.

Что касается витрин магазинов, то на них есть ссылки в портфолио, можно оценить скорость их работы и удобство для покупателей.

Над демо бэкофиса стандартных решений думаем, возможно, будет просто ряд презентаций.

В сложных случаях мы очень рекомендуем встречу на нашей территории, где можно все обсудить, посмотреть и понять. Если встреча невозможна, обходимся перепиской и переговорами по телефону.



Ссылка на сообщение


learn and learn:

Александр Фролов :
Кроме того, мы открываем магазины только в доменах заказчиков. Содержимое базы данных, добавленное клиентами и менеджерами, а также файлы дизайна, разработанные для заказчика, принадлежат заказчику. При необходимости он все это может получить и передать другой ИТ-компании (так в договоре).


...ни о чём.


Вероятно, Вы не сталкивались с ситуацией, когда теряется домен. Например, забыли его продлить, и домен оказался захвачен.

В этой ситуации придется открывать магазин в новом домене. Подключить ПО к другому домену не проблема, но вот повторное его продвижение - это на самом деле очень большие расходы.
Поэтому очень важно, чтобы домен принадлежал заказчику, а не кому-нибудь еще. Ну и не надо забывать его продлевать, конечно)

Что касается содержимого базы данных, то прикиньте, сколько нужно заплатить менеджерам для его повторного ввода. А клиентскую базу и заказы вообще не факт, что удастся восстановить.

Поэтому если пользуетесь сервисом SAAS, нужно прояснить вопрос с доменом и с возможностью получения базы данных. Кстати, если у Вас купленный или бесплатный "движок", все эти вопросы остаются, но адресовать их нужно тем специалистам, которые будут сопровождать Ваш магазин. Если договоритесь неправильно, потеряете базу без проблем. Достаточно чем-нибудь обидеть, не заплатить например.

learn and learn:

Александр Фролов :
Никакого возмещения убытков мы не обещаем, впрочем, как и аналогичные сервисы.

[i]

Вот именно, "как и аналогичные сервисы" - поэтому не вижу будущего для думающего клиента с подобными сервисами. Может с развитем рынка и конкуренции что-то и изменится - тогда и будем "подумать".


А Вы думаете, если купите движок или скачаете его бесплатно, Ваши программисты возместят Вам убытки при проблемах с магазином? Или ИТ-компания, которую Вы наймете по аутсорсингу?

А если сами будете сопровождать, то тем более компенсировать будет некому.

Повторюсь, 100% гарантию дает только страховой полис. Хотите гарантий и возмещения убытков - попробуйте обратиться в страховую компанию. Но я пока не знаю таких прецендентов среди обычных магазинов. Вот запуск космических кораблей - там да, это можно застраховать. За космические, опять же, деньги.

В теории, можно было бы создать страховую систему, наподобие КАСКО для автомобилей. Но заниматься этим все же должны специалисты по страхованию, и там, наверное, еще лицензии нужны и куча условий. И по любому, будут страховые взносы)



Ссылка на сообщение


qualified:

А бэкапы сохранять на свои носители, религия не позволяет?


Да, это выход во многих случаях. Опять же, есть много нюансов на SAAS-сервисах и на "своем" движке. В первом случае полные бекапы обычно не представляются, т.к. содержат приватные данные (и этот вопрос надо решать индивидуально), а во втором - многое зависит от того, кто занимается техническим сопровождением.



Ссылка на сообщение


learn and learn:

Я далёк от IT, и готовлюсь размещать заказ на новый сайт. Первый пункт - грамотное ТЗ - уже не просто в проекте - уже в черновике - и это уже достижение. Выложил его для обсуждения на другом ресурсе - все великие специалисты куда-то растворились... Подумываю выложить здесь.


Вообще говоря, составление ТЗ - это большая и сложная работа, которую должен делать не заказчик, а исполнитель. Исходным материалом для составления ТЗ является такой документ, как запрос функциональности. В этом запросе заказчик в произвольном виде формулирует свои требования.

Далее после согласования требований исполнитель составляет ТЗ. Иногда для того чтобы ТЗ не было составлено исполнителем "в свою пользу", его составление поручают третьей компании или независимому от исполнителя специалисту.

Мы практически всегда ограничиваемся запросом функциональности, который заказчик составляет, отвечая на наши вопросы. Это наименее затратный для заказчика путь, т.к. ему не нужно оплачивать работу по составлению ТЗ.

А еще "по науке" есть технический проект, конструкторская документация и т.п. Все это для проектов с большим бюджетом, но позволяет согласовать множество деталей.

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



Ссылка на сообщение


learn and learn:

Если Вам нужен "обучающий" клиент, который будет ставить новые и нестандартные задачи - обращайтесь


У нас сейчас есть такие клиенты, для которых мы сопровождаем и развиваем очень сложные высоконагруженные и отказоустойчивые кластерные системы, содержащие несколько серверов, размещенных в разных датацентрах. Бизнес-процессы там поддерживаются тоже очень не слабые.

Но если Вы станете нашим клиентом, мы скорее всего найдем чему у Вас поучиться - как и у всех наших клиентов. Ведь каждое новое знакомство дает новые знания, обеим сторонам.


learn and learn:

А Ваш сервис предполагает покупку продуктов и размещение их на своём (выбранном) хостинге?


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

Нужно, однако, заметить, что наш сервис не представляет собой простой набор серверов с размещенными на них стандартными или не очень магазинами. В него входят и другие очень сложные системы, необходимые для качественного сопровождения и развития проектов.

Например, это наша внутренняя корпоративная социальная сеть и база знаний для программистов, а также других специалистов, средства разработки и деплоймента (автоматизированного размещения и внедрения) модулей и сайтов, средства автоматизированного тестирования, мониторинга, репликации, многоуровневого резервного копирования данных, наша внутренняя CRM и еще много чего.

Наш бизнес не направлен на создание "движка" или "движков" с целью их продажи и дальнейшего сопровождения. У нас именно интегрированный SAAS-сервис, а это совсем другой бизнес.



Ссылка на сообщение


kehskas:

Уже три года мыкаюсь по разным движкам. Ни устраивает ни один. Опыт общения с ними подсказывает, что основная причина в том что разработкой подобного ПО занимаются программисты, а не продавцы. Это естественно, продавцы ведь в кодеры не годятся, но тем не менее, хотя бы владельцы коммерческих движков могли бы нанять каких нибудь специалистов из области торговли...

Опенсорс ладно, там кто во что горазд лепит, но предложения от разработчиков коммерческих систем доработать элементарные функции ИМ за 4-5-ти значные суммы доставляют особенно Тем более, непонятно как и кто будет в дальнейшем сопровождать эти костыли. И это при наличии over9000 функций которые не будут востребованы в принипе (а платить за них надо!).

Господа, вы предлагаете неполноценный продукт! Который вы сами, в силу своих способностей, не смогли довести до ума! Предлагаете сделать это заказчику за его же деньги.

Честно, посмотрел и попробовал все до чего дотянулся - ни один из тех движков что смотрел, для моих задач не подходит (а они в принципе элементарные). Рад бы уже купить хоть что нибудь достойное, но таких предложений к сожалению нет.

Если вы считаете, что я в чем то ошибаюсь и именно ваш продукт отличается от остальных - кидайте ссылку на демо версию. Отпишу здесь рецензию на ваш продукт с подробным рассказом почему он никуда не годится.

Может найду наконец то, что ищу...


Да вы не ошибаетесь в том, что подавляющее большинство разработчиков предлагаю вам сделать сайт, а не интернет-бизнес.
Вы не ошибаетесь в том, что не возможно найти движок, полностью удовлетворяющий вашим потребностям, потому что каждый разработчик акцентирует внимание и ресурсы при разработке своей платформы на каких-то определенных элементах бизнес-процесса, а не пытается автоматизировать весь процесс целиком. Кроме того, универсальную платформу сделать не возможно по определению. Слишком велики различия между разными торговыми процессами.
Вы абсолютно правы, что кодер не продавец, а продавец не кодер. Но вам нужен не кодер, а в первую очередь проектировщик с навыками консалтинга, который сначала сможет описать и разобрать ваш бизнес-процесс, который и является объектом автоматизации. Большинство же фрилансеров и WEB-студий делают упор на дизайн (они потому и студии). Проектировщик и требования к системе грамотно составит и ТЗ сделает да и кодеров организует правильно. Это особенно важно, когда делается большая торговая система под большой торговый процесс с большим оборотом товаров и большим суточным объемом продаж.
Если вы не можете найти готовый движок, то нужно собирать систему из разного ПО и онлайн-сервисов.
В общем торговля как бинесс-процесс и объект автоматизации намного сложнее чем кажется подавляющему большинству разработчиков. В посте на форуме всего не изложишь, поэтому за подробностями обратитесь сюда http://smartceo.ru/index.php?id=8



Ссылка на сообщение


learn and learn:

Доброта, конечно, безмерная: за десятку в месяц потребитель своими руками и своими же деньгами кладёт свой бизнес в "зону", из которой ему может быть дадут возможность получить надежду на УДО.
IT-рабство.
Выводы? Умный человек сделает их сам.


Я уже писал на этом форуме, что "IT-рабство" будет в любом случае, если только Вы не станете сопровождать и развивать свой проект самостоятельно, т.е. лично.

Если Вы работаете с таким сложным программным продуктом, как интернет-магазин, зависимость от ИТ-специалистов неизбежна.

Даже руководство ИТ-специалистами требует специального образования и знаний предметной области. Иначе Вы не можете оценить качество их работы и объемы сделанного, не сможете грамотно поставить перед ними задачу.

И этот момент многие понимают.

В этом смысле аутсорсинговое сопровождение от ИТ-компании, у которой есть большой опыт работы, намного надежнее, чем сопровождение своими силами или силами случайного фрилансера. А затраты на аутсорсинг в ИТ-компании с опытом окупятся и принесут прибыль, если товары продаются, магазин работает быстро и надежно.



Ссылка на сообщение


Евгений М.:

Вы абсолютно правы, что кодер не продавец, а продавец не кодер. Но вам нужен не кодер, а в первую очередь проектировщик с навыками консалтинга, который сначала сможет описать и разобрать ваш бизнес-процесс, который и является объектом автоматизации.


Да, я тоже так думаю. Чтобы сделать интернет-магазин бизнесом, сначала потребуется маркетолог (оценить рынок, определиться с товарами и ценами, с рекламой), потом консультант по бизнес-процессам, а потом за дело могут приниматься аналитики и постановщики задач ИТ-компании.

Даже самый лучший магазин не станет продавать за Вас, и не поможет продать товар, который никому не нужен. В этом Вам не помогут программисты и Web-студии, тут Вы проводите эти исследования либо самостоятельно, либо обращаетесь к маркетологам.

После этого этапа у Вас будет информация для составления запроса функциональности. И, конечно, этот запрос должен составляться с участием консультанта по бизнес-процессам, своего или исполнителя.



Ссылка на сообщение


Александр Фролов:

e_v_medvedev :
Вы абсолютно правы, что кодер не продавец, а продавец не кодер. Но вам нужен не кодер, а в первую очередь проектировщик с навыками консалтинга, который сначала сможет описать и разобрать ваш бизнес-процесс, который и является объектом автоматизации.


Да, я тоже так думаю. Чтобы сделать интернет-магазин бизнесом, сначала потребуется маркетолог (оценить рынок, определиться с товарами и ценами, с рекламой), потом консультант по бизнес-процессам, а потом за дело могут приниматься аналитики и постановщики задач ИТ-компании.

Даже самый лучший магазин не станет продавать за Вас, и не поможет продать товар, который никому не нужен. В этом Вам не помогут программисты и Web-студии, тут Вы проводите эти исследования либо самостоятельно, либо обращаетесь к маркетологам.

После этого этапа у Вас будет информация для составления запроса функциональности. И, конечно, этот запрос должен составляться с участием консультанта по бизнес-процессам, своего или исполнителя.


Да. Причем что самое интересное, для проведения маркетингового обследования по товарам можно использовать один движок (с минимумом функций), а для полноценного магазина уже понадобится другой. Я по крайней мере своим клиентам так рекомендую.



Ссылка на сообщение


Александр Фролов:

Я уже писал на этом форуме, что "IT-рабство" будет в любом случае, если только Вы не станете сопровождать и развивать свой проект самостоятельно, т.е. лично.

Если Вы работаете с таким сложным программным продуктом, как интернет-магазин, зависимость от ИТ-специалистов неизбежна.


Мы все рабы: во власти ЖКХ, ЕЭС, Газпрома и т.д.
ВОПРОС В СТЕПЕНИ РАБСТВА.
И когда человек не стесняется этого декларировать со страниц своего сайта.... Что тут говорить?

Мои клиенты (я работаю только по предоплате) - тоже в какой-то степени в рабстве предоплаченных денег. Но с момента поступления денег на наш РС до того момента, когда клиент получит свой товар на ТК мы стараемся окружить его заботой, как новорожденного. Наверное, это вопрос воспитания и жизненных взглядов.

А IT-специалист, который знает твои возможности и находится на соседней улице - так же будет с осторожностью относиться к своей власти надо мной. А "ай-ти-шник", который набрал пол-сотни клиентов и знает тебя только виртуально - пока он поймёт, что именно ты из тех клиентов, который не потерпит беалаберного и безответственного отношения к тебе - можно кучу дров наломать...

Плохо то, что на соседней улице пока не нашлось опытного спеца...



Ссылка на сообщение


Александр Фролов:

learn and learn :
Я далёк от IT, и готовлюсь размещать заказ на новый сайт. Первый пункт - грамотное ТЗ - уже не просто в проекте - уже в черновике - и это уже достижение. Выложил его для обсуждения на другом ресурсе - все великие специалисты куда-то растворились... Подумываю выложить здесь.


Вообще говоря, составление ТЗ - это большая и сложная работа, которую должен делать не заказчик, а исполнитель. Исходным материалом для составления ТЗ является такой документ, как запрос функциональности. В этом запросе заказчик в произвольном виде формулирует свои требования.

Далее после согласования требований исполнитель составляет ТЗ. Иногда для того чтобы ТЗ не было составлено исполнителем "в свою пользу", его составление поручают третьей компании или независимому от исполнителя специалисту.

Мы практически всегда ограничиваемся запросом функциональности, который заказчик составляет, отвечая на наши вопросы. Это наименее затратный для заказчика путь, т.к. ему не нужно оплачивать работу по составлению ТЗ.

А еще "по науке" есть технический проект, конструкторская документация и т.п. Все это для проектов с большим бюджетом, но позволяет согласовать множество деталей.

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


Ну не стоит так лезть в дебри и утрировать.
Полагаю, если не придираться к терминологии, я в своей реплике всё достаточно ясно изложил. И все Ваши доводы полностью имеют основание и наполнены смыслом.
Но таким макаром, мы и до согласования с ООН и ЮНЕСКО дойдём...

Полагаю, тут всё ясно все участникам диалога.
:D



Ссылка на сообщение


learn and learn:

Ну не стоит так лезть в дебри и утрировать.


Не то чтобы утрировать - это описание нормального процесса ИТ-разработки. Именно так и работают "хорошие" ИТ-компании (в отличие от тех, кто делает все "на коленке").

Конечно, у "хороших компаний" уже есть наработанные за много лет ТЗ и тех. проекты, опыт итерационных изменений требований, поэтому можно создавать качественные продукты за реальные, а не безумные деньги.



Ссылка на сообщение


Евгений М.:

e_v_medvedev


Я не нуждаюсь ни в чем сверхестественном или особенном. Весь функционал уже давно придуман и реализован. Проблема только в том, что придуман и реализован он в разных движках :mrgreen: Где то его больше, где то меньше, но нет ни одного где он есть целиком.

До того как заниматься интернет-торговлей, я 7-8 лет проработал в IT попутно делая свои и заказные шабашки на LAMP и имею определеное понимание чего подобная работа может стоить и с какой стороны к ней лучше подойти.



Ссылка на сообщение


kehskas:

Я не нуждаюсь ни в чем сверхестественном или особенном. Весь функционал уже давно придуман и реализован. Проблема только в том, что придуман и реализован он в разных движках Где то его больше, где то меньше, но нет ни одного где он есть целиком.


Видимо это и означает, что Вам требуется заказная разработка. Ну или заказная доработка. Массовые движки ориентированы на массового потребителя, причем у создателя каждого движка свои представления о том, что нужно всем.

Но универсальное решение не может быть оптимальным ни в каком конкретном случае, т.к. содержит много компромиссов ради универсальности. Оно также не может быть и полностью универсальным, т.к. могут быть и взаимно исключающие требования.



Ссылка на сообщение


kehskas:

Если вы считаете, что я в чем то ошибаюсь и именно ваш продукт отличается от остальных

Вы ошибаетесь в базовых принципах разработки интернет-проекта.
Любой проект подразумевает наличие и решение задач, которым отвечает план, процесс, результат.
Коробочные версии продуктов систем управления сайтами создавались как универсальное решение позволяющее при наличии профессиональных знаний, членству в группе разработчиков системы ускорить время разработки уникального продукта, отвечающего конкретным задачам.
Ни один подобный продукт не предполагает, что менеджер Иван Иванович у себя дома на диване откроет на базе этого продукта успешный интернет-магазин, отвечающий всем родившимся в голове Ивана Ивановича задумкам.
Современные (по крайней мере глобальные) коробочные системы управления представляют собой своего рода фреймворк с помощью которого программисты развернут систему которая будет отвечать требованиям Ивана Ивановича, напишут с нуля или перепишут существующие модули так, чтобы это не отразилось на производительности, отключат лишний функционал, либо вообще проведут индивидуальную сборку системы из репозитория, оставив только необходимый функционал. Это издержки универсальности. Все иные утверждение об абсолютной универсальности и пользе - не более чем маркетинг и именно так их нужно воспринимать.

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






Ответить


:D
:)
:(
:o
:shock:
:?
8)
:lol:
:x
:P
:oops:
:cry:
:evil:
:twisted:
:roll:
:wink:
:!:
:?:
:idea:
:arrow:
:|
:mrgreen:







2001 - 2018 © Оборот.ру. Все права защищены