Введение

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

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

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

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

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

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

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

В первую очередь эта статья предназначена тем, кто планирует или только рассматривает вариант запуска своего бизнеса.
Оглядываясь на 15 летний опыт работы в IT c бизнес процессами, решил, написать данный мануал. Это будет серия статей, так как материал выходит объемистый.

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



Открыт для конструктивной критики и буду рад оказать помощь, если она вам потребуется.

Статья содержит названия некоторых продуктов и компаний, ссылки я не даю так как это может быть воспринято как реклама. Всё, продукты, что я указываю, это опыт работы и не является рекламой.
Буду рад если вы поделитесь своими наработками с теми или иными сервисами.

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

Это статья для руководителей отделов разработки, бывших разработчиков. Я очень часто слышу два противоположных мнения. Они звучат примерно так:

• «Нам важен готовый продукт — плевать на плохой код»
• «Нам важен поддерживаемый продукт — пусть это и будет долго»

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

Привет, меня зовут Александр Волков, я проектирую интерфейсы в компании Docsvision. Цель этой статьи — помощь разработчикам сложных программных продуктов. Ключевое слово — сложных. Спроектировать сайт-визитку сегодня может даже пятиклассник прямо на своем смартфоне, и при желании можно скачать зип-архив с готовым шаблоном блога или корпоративного сайта. Однако если ваше приложение посложнее обычного интернет-магазина, то, вполне вероятно, строить структуру и определять принципы навигации вам придется самостоятельно, наступая на разбросанные повсюду грабли. Здесь может пригодиться наш опыт. Я опишу один из возможных способов проектирования интерфейсов, который успешно опробован в нашей компании. Это делается легко и просто (практически в полуавтоматическом режиме) при помощи программы FlyingLogic.

Axure — инструмент для создания интерактивных прототипов сайтов и мобильных приложений. Навыков работы с ним часто требуют работодатели, ищущие проектировщика интерфейсов или UX&UI-дизайнера. В России это почти что отраслевой стандарт. Axure 7 — последняя версия программы. Восьмая версия сейчас в бете.

В одной школе интернет-технологий (не упоминаю, чтобы не сочли за рекламу) с мая 2015 года я рассказываю начинающим дизайнерам об Axure 7. В течение 3 часов (минус небольшой перерыв) объясняю, как работают те возможности программы, которые нужны мне для большинства проектов. И закрепляю знания практикой.

Примерная структура занятия:

• Примеры прототипов;
• Виджеты, их настройка и расстановка по холсту с помощью сетки, направляющих и выравнивания;
• Мастера;
• Динамические панели;
• Создание интерактива (ивенты, экшены, кейсы, условия);
• Под конец: способы передачи прототипа заказчику, свойства страниц, стили.

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

Предисловие

Важно! Если Вам хочется побыстрее приступить к технической стороне дела – просто пропустите эту главу.

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

Кстати картинка «человека дождя» на заглавной не просто для привлечения внимания и именно для этого в повествование добавлена «лирика», все события, имена и прочее есть суть фантазии автора. Как обычно, никто ни за что не несет ответственности :)

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

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

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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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