Создание интернет-магазина: эффективные подходы/методы

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

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

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

Первый вариант сейчас стал простым как никогда. Можно даже не знать HTML и тем более ничего сложнее его:

• заходите на сайт компании, которая предлагает собрать интернет-магазин как конструктор;
• используете шаблонные блоки с разными функциями, чтобы создать структуру страниц;
• выбираете платные или бесплатные варианты дизайна и загружаете свой контент;
• оплачиваете подписку;
• profit!

Если вы собираетесь, например, продавать свой hand-made, в магазине будет +/- 50 товаров, а привлекать пользователей планируете через социальные сети — смело выбирайте этот вариант. Это дешево, удобно и даже увлекательно на этапе сборки. А если «что-то сломается», то в стоимость подписки входит не только хостинг, но и техподдержка. Если вы, конечно, выбрали нормальную платформу.

Если же собираетесь сделать интернет-магазин, который будет чем-то большим, чем красивая витрина с чек-аутом, — вариант выше не для вас. Если нужны необычные функции (а поиск по сайту и оплата через украинские сервисы — уже необычные). Если хотите подключить системы аналитики или какие-нибудь просмотры товаров на 360 градусов. В конце концов, если вы просто собираетесь продавать много товаров большому количеству людей. Все «магазины по подписке» вам не подойдут.

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

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

• укладываться в сжатые дедлайны;
• экономно использовать ресурсы;
• соблюдать процесс;
• все сразу.

Почти во всех статьях про проектное управление есть упоминания про NASA, которым пришлось придумать не только как отправить человека на луну, а еще и как организовать подготовку к этой сверхзадаче. Вспоминают потому, что у главного «менеджера» программы «Аполлон», доктора Джорджа Мюллера, получилось создать систему управления и уговорить всех ей следовать настолько хорошо, что они перевыполнили все планы и уверовали в проектное управление.

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

Классическое проектное управление

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

В классическом подходе к управлению проект разбивается на 5 этапов:

1. Инициация. Самое начало работы. Например, когда вы приходите с идеей создания интернет-магазина в веб-студию и начинаете обсуждать ее с исполнителями. Чтобы определить, каким должен быть результат, нужно не только рассказать, что вам хочется, и выслушать, как это можно сделать, но также провести аналитику, учесть много нюансов и, разумеется, участвовать в мозговых штурмах и совещаниях.
2. Планирование. Когда становится ясно, какой результат нужен, начинается разработка ТЗ настолько подробно, насколько это нужно, чтобы начать работу. Здесь уже не обойтись без консультации специалистов, которые будут заниматься проектом, составления планов работы, вычисления нужного количества времени на каждый этап, оценки рисков и так далее.
3. Разработка. Это еще не написание кода в прямом смысле, а часть планирования, когда выбираются технологии для реализации функционала, определяется конфигурация проекта и прочие технические нюансы, которые не так важны заказчику, как результат, который уже утвердили на предыдущем этапе.
4. Реализация и тестирование. Вот тут уже «настоящая работа» — сначала делаем все, о чем договорились, потом проверяем, как работает. Если тесты показали, что что-то не так, — исправляем.
5. Мониторинг. Показываем клиенту, что получилось в итоге, и на этом заканчиваем работу. Или, если нужно, выясняем, что ему еще хочется, и начинаем все сначала.

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

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

Agile

Agile — семейство гибких итеративно-инкрементальных методов управления проектами. Все «модные» Scrum, Lean, Kanban — методы или фреймворки на основе принципов Аджайл.

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

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

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

Топ-3 Agile метода

Agile — метод управления проектами «в вакууме». Это не конкретная структура, как в ее классическом варианте, а набор принципов и ценностей гибкой разработки. В 2001 был опубликован Agile Manifesto, а дальше, на его основе, стали создаваться «реальные» методы управления, разные, но следующие общим принципам.

Scrum

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

Фишка Scrum — постоянно показывать заказчику результаты. Постоянно, в данном случае, означает, что раз в 1-4 недели в течение всей работы над проектом разработчики из каждой команды будут показывать вам полностью готовую функциональность или другую выполненную относительно небольшую задачу.

Сам проект сначала разбивается на функциональные части, product backlog — элементы, из которых потом будет собираться полноценная программа. Этим частям назначаются приоритеты и выделяются команды по 5 человек в среднем, которые будут заниматься разработкой. Все команды работают по спринтам.

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

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

• Backlog Grooming. Первая встреча в спринте для классического планирования. Участники, во главе с продукт оунером, смотрят, что уже сделано и что еще нужно сделать для проекта, а потом назначают задачи на этот спринт. Цель встречи — определить, что получит заказчик в конце спринта.
• Sprint Planning. Вторая часть первой встречи, где уже специалисты решают, как лучше достичь поставленной цели: кто, что, как и когда будет делать.
• Daily standup. Ежедневная короткая встреча, где в среднем за 15 минут участники команды рассказывают, что сделали за вчера или не сделали, потому что столкнулись с трудностями, и как собираются их решать.
• Подведение итогов. Митинг в конце спринта, когда команда, а чаще всего ее тимлид, показывает владельцу продукта результат.
• Ретроспектива. Последняя встреча, которую проводят сразу после подведения итогов, чтобы обсудить как в целом прошел спринт. Тут обсуждаются не только рабочие задачи, но и сложности во взаимодействии, если они были, чтобы к следующему спринту увеличить эффективность работы.

Плюсы и минусы Scrum:

1. Гибкость и видимые результаты. Регулярные отчеты не только помогают видеть вам, как заказчику, что работа движется в нужном направлении, но и хорошо сказывается на мотивации разработчиков. Кому не хочется поставить «галочку» напротив очередного пункта плана по работе над проектом? Тем же людям, что не хотят впустую делать сложную работу, если они уже сейчас видят, что как минимум ее, а может и многое другое, придется переделывать. А в классической модели им бы пришлось тратить на это время, а вам еще и деньги — ведь вы согласились вначале, что вам нужен именно такой результат. Scrum дает возможность быстро подстраиваться под новые требования.
2. Возможность обучения. Scrum идеален для подготовки специалистов. Когда 4 из 5 участников —  мастера в своем деле, а совещания, где делятся опытом, обязательно проводятся ежедневно, новичку всегда будет к кому обратиться за советом и, в целом, легче обучиться работе как непосредственной, так и в команде. К тому же, коллективная ответственность команды за каждый спринт, гарантирует, что никто не оставит новичка один на один со сложной задачей и не даст ему решить ее каким-нибудь изощренным способом, что может в итоге навредить проекту.
3. Отличное решение для развития продукта. Scrum хорош для разработки с нуля, но еще лучше для постоянного обновления. Спринты оптимально подходят для оценки состояния разных частей проекта, их доработки, тестирования новой функциональности и так далее. А если тестирование показало не такие результаты, как планировалось, все легко исправить, буквально в следующем спринте. Т.е. вместо глобального обновления, условно раз в год, вы сможете совершенствовать проект постепенно, хоть каждую неделю.
4. Высокие требования к команде. Да, Scrum хорош для обучения новичков, потому что от специалистов в таких проектах требуется больше, чем просто «делать свою работу». Часто нужно выполнить смежные задачи, чтобы уложиться в сроки и, как минимум, понимать, почему на конкретный таск нужно именно столько времени. Плюс нужно постоянно взаимодействовать с коллегами по команде и брать ответственность не только за себя, но и за них тоже. Самоорганизованность — сама по себе редкий скилл, а собрать 5 человек с такими навыками и добиться от них слаженной работы очень сложно.

Lean

Lean — одна из методологий Agile, которая тоже не предлагает вам четкой структуры «делай так». Она просто добавляет к концепции разделения проекта на небольшие подзадачи workflow — схему потока операций.

С Lean у каждой подзадачи будет свой порядок действий, от старта до результата. Проще говоря, пока в Scrum внутри спринта можно «развлекаться» как угодно, главное, чтобы к его концу было все готово, Lean не устанавливает четких временных рамок. Зато говорит в какой последовательности нужно выполнять этапы подзадач. И очень подробно.

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

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

Kanban

Kanban — Agile-методология от Toyota, которая превращает абстрактный Lean в систему с наглядным рабочим процессом (workflow). Ее одинаково просто применить как к производству деталей для машины, так и для разработки сайтов или ПО.

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

С Kanban вы будете видеть, как идет работа над всеми подзадачами на наглядной доске. Кто занимается конкретными задачами, какой у них приоритет, сколько времени уже потрачено и многое другое.

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

4 фишки Kanban:

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

Что еще?

К Agile методам относится также придуманный компанией Motorola Six Sigma. Это вариант Lean, где самым важным фактором становится измерение и контроль всех показателей проекта. Его выбирают, когда проект сложный и самая важная задача — максимально сэкономить ресурсы и собрать как можно больше информации для дальнейшего развития. Если вы не собираетесь безостановочно развивать проект до бесконечности и не готовы принять, что ваше мнение не будет решающим, от него лучше отказаться. Этот метод управления подходит стартапам со сложной бизнес-логикой и только усложнит разработку интернет-магазина.

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

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

Если собираетесь делать интернет-магазин сами, создайте себе канбан-доску в любом удобном приложении или даже в табличке Excel, чтобы ничего не упустить.

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

При этом помните, что все Agile-методологии можно использовать вместе, создавая идеальную систему для управления именно вашим проектом. К примеру, внутри скрам-спринта часто рисуют канбан-доски, чтобы было удобнее понимать, кто что делает, и отслеживать прогресс. Главное, обязательно обсудите с менеджером вашего процесса, как именно вы будете получать отчеты и насколько они будут подробными.