Не так давно мы запустили новый интернет-магазин для любителей онлайн-игр.
Наш сотрудник valvet написал статью о процессе разработки — приводим его рассказ ниже.
Привет!
Хочу представить вашему вниманию проект Handytime — интернет‑магазин игровых таймкодов. Буду рад, если вы, прочитав пост, посетите сайт и выскажете свое мнение.
Текста получилось много: хотелось поподробнее рассказать о процессе разработки, чтобы было интересно и коллегам.
На данный момент Handytime позволяет приобретать таймкоды и ключи на игровую валюту.
Отличий от других игровых интернет-магазинов на данный момент не так много:
Магазин был запущен недавно, и мы пока не можем похвастаться широким ассортиментом и длинным списком платежных систем, но все еще впереди.
Работа над проектом началась еще до сбора команды: так получилось, что ее будущие члены начали интересоваться интернет-торговлей. Так как работаем мы все в игровой индустрии, естественно, основное внимание было обращено на главных представителей игрового рынка.
Каждый из нас составил свое мнение о положении дел, после чего мы, собственно, и собрались в команду. Мы — это:
Для начала мы решили составить «глобальный» план действий. Забегая вперед, скажу, что с «глобальностью» мы погорячились.
В плане мы определили следующие основные пункты:
Это не весь перечень, я выделил только наиболее стандартные темы. И каждый пункт описывался в документе очень подробно. Составление подобного плана — действительно хорошая идея для людей, впервые занимающихся созданием нового продукта, но подходить к этому надо аккуратно. Мы столкнулись со следующими проблемами:
Где-то спустя месяц было решено перестать страдать бумагомаранием и перейти к действию. Мы зафиксировали документ в текущем состоянии, взяли за основу его ключевые элементы и перешли к созданию прототипа.
Но сначала — еще одни грабли.
Хочу рассказать о нашем выборе движка магазина. Не нашел статью, в которой видел пример ситуации, на 100% применимой к нам, поэтому вкратце опишу сам.
Так сложились обстоятельства, что у нас не было выбора между написанием магазина «с нуля» и готовой cms — нужна была последняя. И мы совершили основную ошибку в этом деле: просто сравнили функциональности cms, основываясь на словах разработчиков. Мы не подумали о том, что из вообще имеющегося в cms функционала нам пригодится, не стали искать отзывы.
В результате была выбран действительно неплохой движок Shop-Script от компании WebAsyst.
Проблема состоит в том, что, как и подавляющее большинство движков, Shop-Script ориентирован на полноценный интернет-магазин с ритейл-доставкой и не является таким уж «расширяемым», из-за чего мы имеем:
Вещи, казалось бы, очевидные, но на деле редко кто об этом задумывается.
В работе над прототипом мы использовали популярную сейчас методологию Scrum, в чем нам помогал руководитель основного направления компании. Несмотря на известную неприязнь большинства программистов к этой методологии (по крайней мере, по опыту нашей компании), Scrum принес свои плоды: прототип был закончен за месяц с небольшим и удовлетворил желаниям руководства.
На этом этапе сложно выделить какие-то особенности или ошибки, за исключением двух:
Собственно, началась основная работа. К ней мы подошли с потерями: отвалился один из программистов, перешедший на другое направление.
Установленный руководством срок работы составлял месяц с небольшим.
По факту получилось четыре.
На «военном совете» мы решили, что программисту не стоит отходить от хорошо показавшего себя Scrum. Я же работал по принципу «нужно было вчера».
Не буду описывать многочисленные ошибки, возникшие на этом этапе — слишком их много. Хочу рассказать только о двух основных, которые и повлияли на время разработки:
Со сроками все прозаично: при разработке общего плана работы была поставлена задача вписаться в месяц, поэтому мы отбросили мелкие задачи, наивно полагая, что они решатся по ходу работы.
Плюс к этому аукнулось наше с программистом недопонимание: я не до конца детализировал требования к задачам, а программист эти пробелы реализовывал на свое усмотрение. В результате приходилось тратить время на дообсуждение и переделывание уже, казалось бы, готовых фич.
С дизайн-студией же получилась очень поучительная лично для меня ситуация. Они уже делали для нашей компании несколько заказов, поэтому я заранее считал их добрыми знакомыми и общался с ними соответственно. Работа пошла продуктивно только после смены стиля работы с дружеского на формальный.
Хочу сразу сказать, что конечный результат их работы нам понравился и нравится сейчас. Просто теперь я понимаю, что в бизнесе полагаться на дружбу стоит не в первую очередь.
Собственно, в результате мы получили работающий магазин в своем нынешнем виде (в конце статьи расположены скриншоты, на которых я постарался продемонстрировать текущий функционал).
Не успели мы порадоваться запуску магазина, как суровая действительность поставила нас на место — мы поняли, что работа только начинается. От Scrum мы ушли: дело в том, что текущий стиль работы не требует такого четкого планирования, как при первоначальной разработке, поэтому мы пришли к Канбану.
Из ближайших задач у нас:
Спасибо за то, что дочитали.
Напоследок — обещанные скриншоты (кликабельны).
Наш сотрудник valvet написал статью о процессе разработки — приводим его рассказ ниже.
Привет!
Хочу представить вашему вниманию проект Handytime — интернет‑магазин игровых таймкодов. Буду рад, если вы, прочитав пост, посетите сайт и выскажете свое мнение.
Текста получилось много: хотелось поподробнее рассказать о процессе разработки, чтобы было интересно и коллегам.
Вкратце о магазине
На данный момент Handytime позволяет приобретать таймкоды и ключи на игровую валюту.
Отличий от других игровых интернет-магазинов на данный момент не так много:
- быстрая покупка (оформление заказа происходит в рамках одной страницы);
- для заказа не требуется регистрация (она будет реализована позднее).
Магазин был запущен недавно, и мы пока не можем похвастаться широким ассортиментом и длинным списком платежных систем, но все еще впереди.
Начало работы aka планирование
Работа над проектом началась еще до сбора команды: так получилось, что ее будущие члены начали интересоваться интернет-торговлей. Так как работаем мы все в игровой индустрии, естественно, основное внимание было обращено на главных представителей игрового рынка.
Каждый из нас составил свое мнение о положении дел, после чего мы, собственно, и собрались в команду. Мы — это:
- я как руководитель проекта (договоры, бумажная волокита и прочая бюрократия, а также пинание кодеров);
- два web-программиста.
Для начала мы решили составить «глобальный» план действий. Забегая вперед, скажу, что с «глобальностью» мы погорячились.
В плане мы определили следующие основные пункты:
- цель проекта;
- целевая аудитория;
- USP и основные фичи;
- основной функционал;
- планируемые системы оплаты;
- планируемая реклама;
- этапы развития.
Это не весь перечень, я выделил только наиболее стандартные темы. И каждый пункт описывался в документе очень подробно. Составление подобного плана — действительно хорошая идея для людей, впервые занимающихся созданием нового продукта, но подходить к этому надо аккуратно. Мы столкнулись со следующими проблемами:
- непонимание того, что делать «магазин мечты» — глупо (хотя мы должны были это понимать, т.к. аналогичных игровых примеров — масса);
- работа с планом превратилась в бесконечное обсуждение.
Где-то спустя месяц было решено перестать страдать бумагомаранием и перейти к действию. Мы зафиксировали документ в текущем состоянии, взяли за основу его ключевые элементы и перешли к созданию прототипа.
Но сначала — еще одни грабли.
CMS
Хочу рассказать о нашем выборе движка магазина. Не нашел статью, в которой видел пример ситуации, на 100% применимой к нам, поэтому вкратце опишу сам.
Так сложились обстоятельства, что у нас не было выбора между написанием магазина «с нуля» и готовой cms — нужна была последняя. И мы совершили основную ошибку в этом деле: просто сравнили функциональности cms, основываясь на словах разработчиков. Мы не подумали о том, что из вообще имеющегося в cms функционала нам пригодится, не стали искать отзывы.
В результате была выбран действительно неплохой движок Shop-Script от компании WebAsyst.
Проблема состоит в том, что, как и подавляющее большинство движков, Shop-Script ориентирован на полноценный интернет-магазин с ритейл-доставкой и не является таким уж «расширяемым», из-за чего мы имеем:
- избыточность функционала и, как следствие, лишний код;
- увеличение временных затрат на добавление нового функционала.
Вещи, казалось бы, очевидные, но на деле редко кто об этом задумывается.
Прототип
В работе над прототипом мы использовали популярную сейчас методологию Scrum, в чем нам помогал руководитель основного направления компании. Несмотря на известную неприязнь большинства программистов к этой методологии (по крайней мере, по опыту нашей компании), Scrum принес свои плоды: прототип был закончен за месяц с небольшим и удовлетворил желаниям руководства.
На этом этапе сложно выделить какие-то особенности или ошибки, за исключением двух:
- хотя видение продукта у меня и команды в общем и целом совпадало, реализацию конкретных фич мы видели по-разному, из-за чего в будущем получили много проблем;
- недостаток у меня опыта руководства, что также сказалось в дальнейшем.
Разработка
Собственно, началась основная работа. К ней мы подошли с потерями: отвалился один из программистов, перешедший на другое направление.
Установленный руководством срок работы составлял месяц с небольшим.
По факту получилось четыре.
На «военном совете» мы решили, что программисту не стоит отходить от хорошо показавшего себя Scrum. Я же работал по принципу «нужно было вчера».
Не буду описывать многочисленные ошибки, возникшие на этом этапе — слишком их много. Хочу рассказать только о двух основных, которые и повлияли на время разработки:
- неправильно выставленные сроки;
- ошибка при работе с дизайн-студией.
Со сроками все прозаично: при разработке общего плана работы была поставлена задача вписаться в месяц, поэтому мы отбросили мелкие задачи, наивно полагая, что они решатся по ходу работы.
Плюс к этому аукнулось наше с программистом недопонимание: я не до конца детализировал требования к задачам, а программист эти пробелы реализовывал на свое усмотрение. В результате приходилось тратить время на дообсуждение и переделывание уже, казалось бы, готовых фич.
С дизайн-студией же получилась очень поучительная лично для меня ситуация. Они уже делали для нашей компании несколько заказов, поэтому я заранее считал их добрыми знакомыми и общался с ними соответственно. Работа пошла продуктивно только после смены стиля работы с дружеского на формальный.
Хочу сразу сказать, что конечный результат их работы нам понравился и нравится сейчас. Просто теперь я понимаю, что в бизнесе полагаться на дружбу стоит не в первую очередь.
Итого
Собственно, в результате мы получили работающий магазин в своем нынешнем виде (в конце статьи расположены скриншоты, на которых я постарался продемонстрировать текущий функционал).
Не успели мы порадоваться запуску магазина, как суровая действительность поставила нас на место — мы поняли, что работа только начинается. От Scrum мы ушли: дело в том, что текущий стиль работы не требует такого четкого планирования, как при первоначальной разработке, поэтому мы пришли к Канбану.
Из ближайших задач у нас:
- реализация ключевых фич;
- привлечение пользователей;
- получение отзывов от покупателей и улучшение магазина в соответствии с ними;
- увеличение каталога и количества платежных систем.
Спасибо за то, что дочитали.
Напоследок — обещанные скриншоты (кликабельны).
Главная страница
Главная страница с выбранным товаром
Страница новостей
Контакты
FAQ / Обратная связь
Пользовательское соглашение
