Мы знакомимся со сферой деятельности клиента, спрашиваем, советуемся с Заказчиком, рассуждаем. В это же время мы собираем и структурируем полученную информацию.
В итоге, мы показываем и согласовываем с первого раза прототип и визуальную концепцию нового сервиса. Получилось так:
В целом, концепция всех устроила, но по ходу существования проекта дорабатывалась неоднократно. Хотя, визуально разница между изначально предложенным вариантом и текущей реализацией - минимальна.
Методы и приемы, используемые в согласованном варианте дизайн-макетов:
По составленному на проектирования списку необходимых макетов начали появляться в 4 разрешениях:
Общее количество дизайн-макетов - около 40 шт.
4 основных разрешения:
Далее - приступаем к верстке. Получаем функциональный прототип, все ссылки на месте, контент - статика, системы управления пока нет, но уже сейчас можно увидеть полноценный функциональный ресурс. Понятно, что и где располагается. Более наглядно, чем на блок-схемах.
CMS Битрикс для продажной части. Разработка выполнялась на тестовом внутреннем сервере компании Исполнителя. По результатам тестирования был составлен список недоработок и корректировок. После их исправления ресурс был выложен на продакшен и поставлен на поддержку и продвижение.
Yii для сервиса и проценки. Модульность, параллельная проценка по разным поставщикам, клиентская сортировка и группировка позиций, интеграция с Техдок, формирвоание пула гарантированных аналогов через Техдок и многое другое.
Помимо этого на базе сервиса запущены дополнительные инструменты:
Жаль, что некоторые разработки в рамках проекта, так и не удалось запустить, как это было с мобильным приложением под iOS:
Модерация Apple дала отказ в публикации мобильного приложения ввиду того, что приложение внутри частично дублирует содержание сайта. Хотя, изначально, в требованиях и было указано, что для каталогов это допустимо. Но нет...
Работая над проектом мы старались сделать так, чтобы система сама себя оптимизировала. В теории решения изобретательских задач есть подход, который называется «идеальный конечный результат» (ИКР). Он предлагает при решении задачи представить себе идеальный образ решения, когда нужное действие совершается без каких-либо затрат, усложнений и нежелательных эффектов.
В разработке часто случается так, что мы требуем от разработчика чего-то, пытаемся это контролировать, окружаем себя всё большим и большим количеством показателей, чтобы получить уверенность в том, что всё идёт по плану. Но чем больше людей, чем больше задач, чем больше показателей, тем этим становится всё сложнее и сложнее управлять. В результате можно прийти к ситуации, когда времени нет ни на что, кроме таблиц с показателями и бесед, а дела всё равно идут не очень.
К тому же имеется масса факторов, влияющих на мотивацию разработчика, на стимуляцию его понимания и принятия целей бизнеса: перспективы бизнеса, понимание важности проекта для компании, стремление к беспроблемному внедрению и эксплуатации, субъективная удовлетворённость и т. д. Но многое из этого трудно формализовать и измерить. А тем более сложно порой донести ценность до конкретного исполнителя. Часто даже очень хороший разработчик не улавливает изменение направления «продуктового ветра», и ему требуется какой-то понятный и простой механизм, указывающий верное направление.
В рамках данного проекты, установленные сроки рассматривались как один из основных инструментов стимулирования ИКР разработчиков на всех этапах. Этот срок проходит через весь процесс и заставляет изобретать решения, позволяющие избежать массу проблем в будущем. Он позволяет делегировать ответственность, не прибегая к многочисленным KPI. Он понятен и доступен практически всем. И он ведёт нас всех к главной цели бизнеса: сделать как можно быстрее как можно больше. А будет ли это ещё и дёшево, зависит от тех решений, которые мы будем использовать, а следовательно, от нас всех.
В рамках именно этого проекта нам удалось поработать большой командой над одним решением. Всего в проекте приняло участие более 12 человек и проект удалось завершить и запустить точно и в срок.