Блог

Записи

Миссия
Evercode Lab

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

Изучаем и используем современные технологии, чтобы наши продукты отвечали высоким требованиям качества. Стремимся узнавать новое и делиться этими знаниями.

Еще...

Проекты: Система тестирования знаний «Балл»

Mar 29, 2016, Николай Неустроев

«Балл» — онлайн-система для проведения тестирования в школах.

История и цель проекта

Арвидас Жилинскас еще будучи студентом занимался репетиторством — помогал школьникам готовиться к ЕГЭ по математике. Не оставил он это занятие и после того, как получил диплом физика и устроился на работу в банк. Предпринимательские способности дали о себе знать, поэтому вскоре он открыл образовательный центр ARNA

Спустя некоторое время Арвидас понял, что пора подняться на новый уровень в деле школьного образования. Тут и начинается история его стартапа под названием Система Независимой Оценки Качества Общего Образования «Балл». Сокращенно — СНОКОО «Балл» или просто «Балл».

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

Для этого система должна предоставлять следующие возможности:

  1. Администраторы вносят в систему задачи для проверки знаний;
  2. Учителя назначают учеников на тестирование;
  3. Ученики проходят тестирование;
  4. Результаты проверяются: одна часть автоматически, другая — специальными людьми.

Арвид знал нашего директора Романа, потому что учился с ним на одном курсе, и поэтому он предложил нам взяться за разработку этого проекта. Мы начали в августе 2014 и уже через 2 месяца, к концу сентября, мы успешно проверили систему на настоящем тестировании.

Первая серьезная сессия была в феврале 2015, следующая — осенью, и затем декабре. В январе 2016 на системе “Балл.орг” была проведена олимпиада школьников по финскому языку.

Функции проекта

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

Возможности преподавателя

Учителю доступны 5 разделов:

  1. Доступные тестирования
  2. Активные тесты
  3. Завершенные тесты
  4. Статистика
  5. Обратная связь

Сценарий преподавателя для запуска теста

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

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

Сценарий ученика

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

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

По нажатию на “Начать тестирование” ученик переходит на страницу теста, где он сразу видит первый вопрос.

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

  • зеленый (ответ дан)
  • красный (просмотрено, но ответ не дан)
  • голубой (не просмотрено)

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

После завершения тестирования ученик переходит на страницу со списком вопросов пройденного теста и своими ответами на них, но уже не может их изменить.

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

Стоит заметить, что аккаунты полностью анонимизированы, и в системе не происходит хранение персональной информации и личных данных.

Сценарий преподавателя для завершенного теста

С завершенными тестами преподаватель может совершить следующие действия:

  1. Посмотреть или распечатать вопросы завершенных тестов
  2. Загрузить разом сканы или фотографии всех письменных ответов учеников (но обычно это должны делать сами учащиеся)
  3. Посмотреть результаты любого ученика — там показываются вопросы и ответы учащегося и правильные ответы системы.

Сценарий проверяющего

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

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

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

Также есть возможность загрузить все ответы через заполненный определенным образом табличный файл.

Возможности администратора

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

Тесты и вопросы

Страница списка тестов позволяет создавать новые тесты и редактировать имеющиеся. Работа с тестом заключается в создании вопросов для него.

Тестирования

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

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

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

Статистика

Статистику может смотреть как преподаватель, так и администратор системы, однако они имеют разные права доступа. Доступен десяток графиков:

  • Уровень достижений по предметам
  • Рейтинг школ
  • Успеваемость учеников
  • Аналитика по выбору предмета
  • Статистика посещаемости
  • Время выполнения
  • Результаты анкетирования
  • Статистика по преподавателям
  • Медиана
  • Динамика среднего балла
  • Динамика учеников (у преподавателей)
  • Динамика результатов в таблицах

Рабочие процессы на проекте

Проектирование

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

Итерационный подход

Итерации это периоды времени постоянной длительности, на которые делится все время работы. На этом проекте итерации были по неделям.

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

Инструменты обсуждения и учета задач

Система Балл стала первым проектом, на котором мы решили внедрить YouTrack для ведения задач по разработке.

Основная работа велась в модуле Agile Boards, основанном на принципе Канбан-досок. В таком случае экран делится на несколько столбцов, каждый из которых соответствует определенному возможному статусу задачи:

  • Open — задача готова к работе, но не начата
  • In Progress — задача в работе
  • Code check — проверка кода другим разработчиком
  • Fixed — готова и загружена на тестовый сервер
  • Verified — проверена менеджером

Дополнительные статусы

  • To be discussed — возник вопрос, требущий уточнения у менеджера или клиента
  • Reopened — открыта заново (если что-то нужно исправить)

Таким образом, задача по мере работы над ней перемещается из крайнего левого столбца в крайний правый.

С сентября 2015 года мы перешли в другой сервис — Trello, сохранив те же принципы работы. Его преимущество в том, что он удобен как для разработчиков, так и для клиентов. А раньше нам приходилось вести общение с заказчиком в Basecamp и потом дублировать информацию в Youtrack.

Технологии

Проект работает на Symfony2. Разработка проекта была начата на версии 2.3, сейчас используется 2.7. Кроме стандартных компонентов мы задействовали следующие сторонние библиотеки:

  • doctrine/doctrine-fixtures-bundle — для организации загрузки тестовых данных,
  • doctrine/doctrine-migrations-bundle — для управления изменениями структуры базы (используем по-умолчанию во всех наших проектах),
  • evercodelab/hipchat-monolog-bundle — наш бандл для отправки уведомлений об ошибках, возникающих в ходе работы проекта, в наш рабочий чат,
  • pugx/multi-user-bundle — чтобы обеспечить разные типы пользователей,
  • phpoffice/phpexcel — для работы с excel-файлами.

Для визуального оформления системы мы взяли Bootstrap, позволяющий быстро и без помощи дизайнера создавать нормальный интерфейс. Для графиков использовали highcharts.js. В моменты нагрузок состояние сервера отслеживалось через New Relic.

Команда

  • Арвидас Жилинскас — заказчик
  • Дмитрий Константинов — основной разработчик
  • Никита Мовшин — менеджер
  • Сергей Лунев — разработчик
  • Роман Лапин — присматривал и помогал

Заключение

С момента запуска системы в работу осенью 2014 по начало 2016 года было проведено 4 сессии тестирования по 10 предметам и еще 3 сессии по двум основным предметам — русскому языку и математике, в которых принимало участие 84 школы и более 5,5 тысяч учеников.

Реализован полный цикл работы по контролю качества знаний: написание тестов специалистами, прием ответов от ученика, ручная и автоматическая обработка ответов, разные формы статистики и отчетов.

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

Не будем скрывать, что проект Балл.орг — один из наших самых любых.

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

Отзыв заказчика

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

Кто такие программисты, и почему важно иметь в офисе вкусные пряники

«Кто такие программисты? Что это за люди? Каких принципов в работе они придерживаются?» Эти вопросы задавал я себе, анализируя предложения по выполнению услуг в сфере программирования. Я всегда, выбирая подрядчика для выполнения своих проектов, пытаюсь понять, как же на самом деле построена работа и устроена система ценностей в компании, которая будет выполнять для меня задачи.

Все исполнители кричат: «качество, сроки, цена!» Но что на самом деле они думают? Можно ли им доверять? Читатель, согласись — важна искренность. И только она одна.

Искренность в диалоге с клиентом (то есть со мной), появляется, когда мне действительно хотят помочь. Когда люди живут своей работой, знают ее и умеют ее хорошо выполнять и организовывать. А все остальное — это маркетинг, который для нас (клиентов) не влияет на добавленную стоимость программного продукта. Поэтому в первую очередь я благодарен ребятам из Everсode Lab за искренность в работе на 95 %, и за маркетинг на 5%, а не наоборот, как у многих других. (Конечно же маркетинг тоже должен быть : -) )

Основываясь на том, что Everсode Lab создали для меня сложнейшую систему тестирования, как часть системы независимой оценки качества общего образования, которой на данный момент пользуется около 4000 школьников на постоянной основе, сотрудникам этой организации точно можно доверить выполнение сложной и ответственной задачи. Поверьте, то что сделали для меня ребята, гораздо сложнее, чем вам может показаться на первый взгляд. Спасибо им за это. Спасибо!

P.S. Пряники в офисе отменные.

«C благодарностью в душе к терпеливому ежедневному профессиональному труду сотрудников компании Everсode Lab» Жилинскас А.А.

Оставить комментарий

Проекты: CRM-система для CADFEM CIS

Mar 21, 2016, Николай Неустроев

SamovarCRM — система управления продажами и проектами, которую мы разрабатываем для компании CADFEM CIS.

Предыстория

О заказчике

CADFEM CIS занимается дистрибуцией ПО для инженерного анализа, а также обучением и консалтингом компаний в этой сфере. Основу продуктовой линейки составляет ПО компании ANSYS. В фирме работает более 60 сотрудников в 6 филиалах в разных частях России.

Предпосылки

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

4 года осуществлялись попытки внедрить в компании различные CRM системы: Мегаплан, MS Dynamics и другие, но они не подходили. Какие-то были слишком простыми, а какие-то чересчур сложными. И в любом случае пришлось бы дописывать систему под себя.

Прототип системы

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

Спустя год успешного использования руководство убедилось в целесообразности вложений в настоящую CRM.

Решение о полноценной системе

Перед заказчиками стояло 3 варианта:

  • найм собственных программистов,
  • обращение в студию разработки,
  • покупка готовой CRM с последующей доработкой.

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

В том, что в итоге Кадфем остановили свой выбор на нас, важную роль сыграл и наш опыт в разработке систем автоматизации. К тому времени это — RedReport для Kelnik Studios, веб-версия системы контроля для АЭС Esсar и система тестирования школьников Балл.орг.

Задачи проекта

На первый год разработки CRM-системы для CADFEM CIS мы поставили перед собой цель перевести в цифровую среду следующие бизнес-процессы компании:

  1. Ведение базы данных по клиентам
    • Компании
    • Люди
  2. Продажи
    • Лиды
    • Возможности
    • Сделки
  3. Коммуникации
    • Обсуждение компаний и сделок
  4. Менеджмент
    • Задачи
    • Календарное планирование
    • Учет загрузки
  5. Топ-менеджмент
    • Обзор процессов
    • Статистика
    • Отчетность
  6. Документооборот
    • Учет документов
    • Генерация коммерческих предложений
    • Генерация писем

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

1 этап (Весна)

Компании и Контакты

Первыми пользовательскими фунциями стали страницы Компаний и Контактов. Сначала для согласования внешнего вида страниц мы использовали мокапы — контурные наброски страниц.

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

При сравнении с мокапом заметно, что общие идеи дизайна сохранены:

  • меню слева,
  • рабочие элементы — в шапке,
  • информационная часть страницы делится на несколько вкладок.

Единственное отличие — добавился блок комментариев справа.

Задачи

Далее мы сделали основные функции для работы с задачами.

Отношение пользователя к задаче выражается его ролью в ней. В задаче задействованы:

  • исполнитель,
  • автор задачи,
  • руководитель исполнителя.

От последнего требуется подтверждать назначение задачи, если она приходит из другого отдела.

Уведомления

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

Дизайн

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

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

Но мы и сами не лишены чувства прекрасного. Поскольку корпоративный цвет компании Кадфем — синий, мы использовали в дизайне системы соответствующие оттенки. Среди многих идей Дмитрия, директора филиала, было предложение назвать систему SamovarCRM и использовать в оформлении фона тему гжели. Так система получила собственный колоритный образ.

2 этап (Лето)

Поиск по системе

Модуль поиска выводит список объектов, в названии которых есть ключевое слово и которые соответствуют настройкам фильтра (блок справа).

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

Система генерации документов

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

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

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

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

Другие примечательные задачи второго этапа, это:

  • Управление лицензиями и услугами,
  • Загрузка прайс-листов,
  • Новые типы задач и разные формы для каждого из этих типов.

3 этап (Осень)

Модуль обсуждений

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

Перенос данных из прототипа, запуск системы

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

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

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

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

Импорт контактов из Microsoft Outlook

Эта функция позволяет перенести нужные контакты из Outlook в систему.

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

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

Календарь

До календаря для работы с задачами использовался временный вариант: все задачи можно было видеть только общими списками, например «Мои задачи в работе», «Просроченные», «Завершенные».

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

Также на данном этапе было сделано много разных улучшений системы — как это всегда происходит в первое время после запуска проекта.

Этап 4 (Зима)

Группировка задач по Этапам, Проектам и Потокам

К этому моменту у нас уже были модули, которые так или иначе работают с возможностями (потенциальным сделками): это сама сущность «Возможность», компании, задачи, документы. Однако еще нужно было объединить все разрозненные функции в цельную систему. Нам нужен был модуль для структурирования задач и связывания их с возможностями.

Процесс продаж в CADFEM CIS регламентирован: это четкая последовательность шагов, каждый из которых состоит из нескольких задач и имеет конкретную цель. Мы назвали эти шаги Этапами и создали для них сущность, к которой можно закреплять задачи. Потом мы пришли к выводу, что одного уровня будет недостаточно и добавили еще два: Проекты и Потоки.

Получилась следующая структура:

Работает это так:

  1. Для каждой потенциальной сделки (Возможности) создается Поток «Продажа».
  2. Внутри потока создаются проекты, которые означают промежуточные точки по пути от добавления компании в базу до подписания договора, например:
    • Исследование компании
    • Пресейлз
    • Закрытие сделки    
  3. В каждом проекте создаются нужные этапы — это шаги по достижению цели проекта, например:
    • Позвонить
    • Договориться о презентации
    • Выслать КП
  4. А уже внутри этапов создаются конкретные задачи для отдельных сотрудников.
  5. После заключения сделки создается другой поток — «Выполнение обязательств» с одним или несколькими проектами в нем, который будет декомпозирован на задачи по той же логике.

Описанные выше функции открыли дорогу к сбору и предоставлению любой статистики в реальном времени.

Отчетность

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

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

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

Другие задачи

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

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

Процессы

Итерационный подход

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

В конце каждой итерации мы собираемся всей командой вместе с заказчиком для того, чтобы:

  • Показать и сдать выполненные с момента прошлой встречи задачи,
  • Совместно сформировать список задач, которые будут нашим планом на следующую неделю.

При этом в любое время заказчик может отслеживать прогресс через общую систему учета задач (см. ниже).

Учет и обсуждение задач

Первое время мы использовали уже привычные нам инструменты общения и управления задачами:

  • YouTrack как наша личная среда, в первую очередь для программистов,
  • Google Drive для хранения файлов,
  • Trello и Basecamp для общения с заказчиками по задачам.

Но со временем стало понятно, что единая среда общения будет намного удобней, поэтому вскоре мы перешли на Trello и расширение для Chrome Plus for Trello.

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

Сейчас учет задач на проекте ведется в Trello на четырех «досках» — обособленных страницах с задачами.

1. Бэклог — тут вносятся будущие задачи-карточки по хронологическим или тематическим группам-столбцам, например:

  • Следующая неделя
  • Следующий месяц
  • До конца этапа
  • Рефакторинг
  • Гарантийные задачи
  • Следующий этап
  • Когда-нибудь

2. Текущее — тут находятся задачи текущей рабочей недели. Столбцы на этой доске соответствуют статусам задач:

  • Открыта
  • На сегодня
  • В работе
  • Проверка кода
  • На тестовом сервере
  • Проверено менеджером
  • Проверено заказчиком
  • На рабочем сервере

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

3. Архив — все завершенные рабочие Недели. Здесь пустынно не бывает никогда, но заходить сюда приходится нечасто.

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

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

Инстурменты проектирования и описания задач

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

На разных этапах проекта и для разных случаев мы использовали следующие инструменты для этого, а именно:

  • Диаграммы связей
  • Технические задания
  • Таблицы
  • Мокапы (см. описание первого этапа)
  • Макеты
  • Пользовательские сценарии

Диаграммы связей

Изначально для описания структуры проекта мы использовали диаграммы связей.

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

Технические задания

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

Обсуждение таких документов можно вести в них самих за счет удобной системы комментирования, встроенной в Google Docs.

Таблицы

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

Технические особенности проекта

Проект написан на Symfony. В декабре мы обновили версию фреймворка до 2.8, по пути починив поломку обратной совместимости в коде компонента Form. Структура проекта обновлена под версию 3.0, но переезд пока не планируется.

В проекте задействованы популярные бандлы:

  • doctrine/doctrine-migrations-bundle
  • doctrine/doctrine-fixtures-bundle
  • ornicar/apc-bundle
  • knplabs/knp-paginator-bundle
  • friendsofsymfony/user-bundle
  • liip/imagine-bundle

Мы применяем wkhtmltopdf для генерации pdf-версий документов. Полнотекстовой поиск работает с помощью ElasticSearch через friendsofsymfony/elastica-bundle.

Для тестирования используются phpunit и liip/functional-test-bundle. Сообщения об ошибках на сервере отправляются в наш HipChat через evercodelab/hipchat-monolog-bundle.

Команда

Менеджмент и проектирование

  • Михаил Борисов — начальник отдела автоматизации бизнес-процессов
  • Николай Неустроев — менеджер проектов Evercode Lab

Разработчики

  • Артемий Анцев
  • Миша Голодяев
  • Дмитрий Константинов
  • Сергей Лунев

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

Вдохновение, советы и чуткий надзор

  • Роман Лапин — управляющий Evercode Lab
  • Валерий Локтев — директор компании CADFEM CIS
  • Дмитрий Михалюк — директор петербургского филиала CADFEM CIS

Результаты

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

Впереди у нас еще много дел для того, чтобы перенести в «облако» все бизнес-процессы компании и подключить к полноценной работе все филиалы CADFEM CIS.

Отзыв от заказчика

На вопросы отвечали:

  • Дмитрий Михалюк (ДМ) — руководитель филиала компании в Северо-Западном федеральном округе
  • Михаил Борисов (МБ) — начальник отдела автоматизации бизнес-процессов

Введение

— В каком качестве вы участвовали в работе над проектом?

МБ: — Я был координатором между CADFEM CIS и Evercode Lab, собирал требования к системе и вместе с менеджером описывал задачи, а затем их принимал.

ДМ: — Я не участвовал напрямую в работе над проектом. Михаил и Evercode Lab периодически отчитывались о ходе процесса передо мной, но в большей степени я выступал как один из первых активных пользователей системы, давал обратную связь, делился советами и идеями.

1. Выбор

— По каким критериям вы выбирали подрядчика?

МБ: — Надежность, цена, процессы разработки, опыт в подобных проектах

— Почему вы остановили свой выбор на Evercode Lab?

МБ: — Рекомендация знакомого, занимающего программированием. Описание процесса разработки на сайте. Личное знакомство с членами команды и с руководителем компании на базе бизнес-инкубатора QD. Хороший подготовительный процесс по нашему запросу. Соответствие методов работы и процессов нашим ожиданиям. Выгодное предложение по цене.

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

— Были ли какие-то опасения? Если были, то они подтвердились?

ДМ: — На обучении MBA у меня был курс по Value Added IT management, на котором преподаватель рассказал нам, что порядка 60% проектов в области IT выходят за рамки бюджета и времени. Я не знал, попадем ли мы в эту статистику. На мой взгляд, опасения не подтвердились. Хотя были моменты, когда желаемых задач было больше того, что можно было сделать, возможно из-за того, что сильного много запланировали. Но в итоге мы получили работающий продукт, есть внутреннее удовлетворение от результата. Может, не на 100%, но точно на 80%. И мы не превысили бюджет: нам не пришлось перед руководством в середине проекта обосновывать увеличение расходов. Это возможно стоило каких-то усилий как Михаилу, менеджеру проекта с нашей стороны, так и команде Evercode Lab, но все с честью и достоинством вышли из сложившейся ситуации.

2. Процесс

— Что вам понравилось в работе с Evercode Lab?

ДМ: — Я наблюдал за этим проектом с частотой примерно раз в месяц на личных встречах. Мне понравилось, что все мои замечания и пожелания фиксировались, и по этим вопросам потом была реакция, обратная связь.

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

Если в двух словах, то понравился профессионализм, готовность отвечать за свои слова и за свои обязательства. Стоит отметить и коммуникации — они идут на хорошем человеческом и профессиональном уровне.

МБ: — Безусловно нравится простая коммуникация и гибкость, совместная проработка ТЗ — это самые приятные воспоминания

— А что не понравилось?

МБ: — Каких-то проблем общего уровня не было.

— Вспомните случаи, которые характеризуют Evercode Lab с разных сторон (с хорошей и с плохой).

МБ: — Из отрицательных примеров: когда не успели вовремя подготовить акт выполненных работ по одному из этапов. А позитивных случаев очень много, поэтому нет смысла перечислять или выделять какие-то отдельные.

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

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

— Что в процессе создания проекта оказалось не таким, каким вы представляли до этого? Что вас удивило? Что вы почерпнули для себя?

ДМ: — Мне очень понравилась система, когда общение между нами и исполнителями построено через руководителя проекта, т.е. минимизировано прямое общение закакзчика с программистами. У нас же инженеры всегда общаются с заказчиком. Поэтому это было ново и интересно для меня. Теперь я попробую применить так же подход и у нас.

— Как происходило ваше общение с менеджером проекта и командой?

МБ: — Обсуждение шло непрерывно по всем каналам связи: телефон, социальные сети, Trello и т.д. И с точки зрения удобства и скорости, я думаю, общение происходило идеально.

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

— Вы бы уделяли проекту больше времени, если бы была возможность?

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

МБ: — С радостью уделял бы больше времени.

3. Результат

3.1. В целом

— Вы довольны результатом?

ДМ: — Да

МБ: — Да, безусловно

— Что говорят пользователи?

ДМ: — Я не слышал негативных отзывов, для меня это уже говорит о многом. Пользователи с интересом воспринимают новую систему, смотрят на нее как некую загадочную игрушку, но у них есть и желание начать активно ее использовать. Конечно, всегда есть опасение, все ли смогут, все ли станут, но общий фон восприятия положительный.

(отзывы пользователей можно почитать после интервью)

— Что говорит руководство компании?

ДМ: — Руководство компании декларирует, что внедрение CRM-системы является ключевой задачей нашей компании на 2016 год.

МБ: — Руководство удовлетворено результатом, однако системе требуется развитие и более плотное внедрение в наши процессы.

— Как повлиял на ваш бизнес этот проект? По каким объективным критериям это видно?

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

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

— Соответствует ли результат вашему изначальному представлению? Если нет, то почему?

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

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

МБ: — Не во всем соответствует изначальному. Однако текущий результат позволяет нам работать в системе и решать текущие задачи. Так как ТЗ менялось очень часто, то многое не сделано или сделано упрощенно, но это скорее к нам вопрос.

3.2. Оценка

Оцените эти качества проекта по 10-балльной шкале и прокомментируйте при желании:

— Скорость работы системы

МБ: — 10, тут вообще вопросов нет, работает очень быстро.

ДМ: — 9.

— Отсутствие ошибок и зависаний

МБ: — 9, есть ряд багов, но я думаю они будут поправлены.    

ДМ: — 8, периодически возникают ошибки, но справедливости ради нужно сказать, что сразу же на это идет мгновенная реакция.

— Удобство

МБ: — 6, есть масса функций, которые требуют доработок.

ДМ: — 7, потому что есть ряд очевидных недостатков в интерфейсе, устранение которых привело бы к лучшем баллу.

— Дизайн (внешний вид, красота, эстетичность)

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

ДМ: — 8. Я сторонник минималистичного дизайна, и на мой взгляд, этот подход здесь соблюден.

— Итоговая оценка проекту

МБ: — 7,5.

ДМ: — 8.

4. Прогноз

— Как вы планируете дальше развивать проект?

МБ: — Планируем продолжать работу в 2016 году по новому ТЗ, которое мы сейчас формируем.

ДМ: — Планов очень много. В первую очередь, хочется устранить те мелкие недочеты в интерфейсе и в функциональности, которые лежат на поверхности. Нужно идти по принципу Парето — устранить 20% недочетов, которые приведут к 80% улучшения восприятия системы.

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

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

— Будете ли вы работать с Evercode Lab в дальнейшем?

МБ: — Обязательно.

ДМ: — Да. Я даю положительную оценку руководству компании и выступаю за продолжение сотрудничества.

— Стали бы рекомендовать Evercode Lab своим друзьям или коллегам по бизнесу?

МБ: — Обязательно.

ДМ: — Да.

Комментарии пользователей о системе

— В лучшую или худшую сторону изменилась ваша работа после перехода с прототипа на новую CRM осенью 2015?

— Скорее в лучшую. Новая CRM более «доброжелательна» к пользователю, а также имеет бОльший набор функций. Под «доброжелательностью» я понимаю доступность и комфорт в использовании.

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

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

— Что вы думаете про дизайн интерфейса системы? (что нравится и что не нравится в нем)

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

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

Оставить комментарий

Проекты: программирование сайта для Eventica

Feb 28, 2016, Николай Неустроев

В этом кейсе мы расскажем о том, как занимались программированием нового сайта компании «Eventica».

О заказчике

«Eventica» — международное коммуникационное агентство с российскими корнями. Оно занимается организацией мероприятий высокого уровня и сопутствующими PR-активностями.

В числе их недавних заслуг — участие в организации конференции World Football Forum, выставки ЭКСПО-2015 и премии МедиаТЭК-2015.

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

Когда наши друзья из студии «Cloudmill» предложили нам выполнить программирование нового сайта Eventica, нас подкупил помимо прочего как раз интересный современный дизайн.

Результат

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

Главная страница

Главная страница устроена по обычному принципу: шапка, краткая информация об агентстве, затем избранные кейсы и список новостей.

Портфолио

Агентство занимается двумя направлениями: Мероприятия и PR, каждое из которых включает несколько направлений. По такой схеме делятся и кейсы в портфолио.

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

Но самое интересное начинается на внутренней странице кейса.

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

  • обычный текст,
  • цитата,
  • сноска,
  • изображение,
  • парное изображение,
  • слайдер,
  • цитата с фото.

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

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

Другие разделы и страницы

Остальные стандартные для корпоративного сайта разделы и страницы тоже присутствуют:

1. Новости

2. Клиенты

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

Под списком клиентов находится слайдер с отзывами.

3. Контентные страницы «О нас» и «Благотворительность».

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

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

4. Контакты

5. Поиск

Адаптивность

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

Система администрирования сайта

Так сложилось, что на системе администрирования принято экономить, особенно на корпоративных сайтах: считается, что раз она находится «за ширмой», и пользоваться ею будет пара человек раз в неделю, то нет смысла делать ее красивой и удобной — лучше потратить этот время на сам сайт.

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

Админка — работа с контентом

Как уже было сказано, и страницы кейсов, и обычные страницы с контентом составляются из разных типов блоков

Особенно удобно, что эти страницы можно видеть в админке в таком же виде, в каком они будут на сайте:

При наведении на блок показываются кнопки управления им: доступно редактирование, удаление и перемещение блока вверх или вниз по списку

Админка — приятные мелочи

На этих скринах можно можно посмотреть некоторые интересные детали интерфейса административной части сайта.

Процесс

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

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

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

На этом проекте мы решили попробовать максимально детально описать проект с трех сторон:

  • страницы,
  • элементы страниц,
  • сущности.

1. Описание страниц

Это самое простое. Имеется ввиду описание свойств страниц как цельных объектов. По каждой из 12 страниц сайта заполнялись следующие поля:

1. Тип

  • Список объектов («С»)
  • Страница объекта («В» — «внутренняя»)
  • Контент («К»)

2. Рабочее название

3. Статус готовности

  • 0 — не сделано
  • 1 — сделано, но не залито, нужны правки
  • 2 — залито, на проверке
  • 3 — залито, проверено, на доработке
  • 4 — залито, в финальном состоянии

4. Ссылка на страницу на тестовом сервере

5. Заголовок меню

6. Title (заголовок) страницы по-умолчанию или шаблон для заголовка

7. URL

В результате получилась такая таблица

2. Описание элементов страниц

Для всех страниц мы перечислили составные блоки и элементы. Для вложенных элементов показали иерархию.

Каждый элемент описывался по следующим свойствам:

1. Тип источника

  • Объект
  • Список объектов
  • Контент
  • Виджет

2. Источник — конкретная сущность или справочник. (сущность это кейс, новость, вакансия, клиент и т.д.)

3. Возможность редактирования

  • да
  • нет

4. Выводимые поля объекта

5. Формат вывода

  • Для списков
    • Количество объектов
    • Фильтрация
    • Сортировка
    • Группировка
    • Формат поля (важно, например, для дат)
  • Для объектов
    • Критерий (например, «последний», «случайный», «относящийся к странице»)
    • Формат поля
  • Для виджета
    • Описание работы (если необходимо)

6. Действие по клику

Ниже снимки нескольких частей полученной таблицы

3. Описание сущностей

Аналогичный подход мы использовали и для описания полей сущностей.

Заполнялись следующие характеристики:

  1. Сущность
  2. Поле
  3. Количество
  4. Тип
  5. Обязательность
  6. Значение по-умолчанию
  7. Поле выводится в список объектов в админке
  8. Поле используется для сортировки в админке
    • да/нет
    • приоритет
    • направление (убывание или возрастание)
  9. Доступен поиск/фильтрация по этому полю
  10. Страница админке для редактирования поля
  11. Виджет для редактирования

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

Несмотря на «технический» характер используемых тут терминов «сущность», «поля», «тип поля», их стоит понимать только как «гуманитарное» описание проекта.

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

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

4. Впечатление от использования таблиц для описания проекта

Плюсы

Детальное описание каждого элемента и каждой сущности послужило отличным дополнением к обычному ТЗ и дизайну. С таким подходом разработчик получает полное описание каждой мелочи проекта, ему не нужно додумывать упущенные при проектировании вопросы, отвлекать менеджера и заказчика. Если все эти детали фиксировать в обычном текстовом техническом задании, то оно станет громоздким и сложным.

Минусы

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

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

Итог эксперимента

Тем не менее, в результате плюсы перевешивают, и мы будем развивать этот подход, делая его более удобным и автоматизированным.

5. Оптимизация изображений

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

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

С разрешением все немного сложнее, поэтому остановимся на этом подробней.

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

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

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

Зеленым цветом написаны обычные размеры, а черным — ретина.

Мы исходили из самых больших экранов — для ПК взяли за основу разрешение 1920х1080 и умножали его на коэффициент 1,5 для ретины. Для мобильных взяли 1280х720 за основу и для ретины умножали на те же 1,5 (получается 1080х1920, что и соответствует максимальному разрешению современных мобильных телефонов).

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

Хотя даже такой безусловно правильный подход встретишь нечасто, это все равно не идеальное решение. Еще лучше было бы дополнительно учитывать небольшие экраны, вроде 1366 на 768 (это обычное разрешение ноутбука 15 дюймов). Итого было бы по 6 размеров для каждого из изображений.

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

6. Коммуникации и управление задачами

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

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

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

Описывать рабочие процессы в неактуальном для нас Youtrack не имеет смысла, тем более в Trello мы сохранили тот же подход. Поэтому скоро мы отдельно расскажем о том, как мы сейчас ведем свои проекты.

Технические особенности

Проект сделан на Symfony 2.6. Задействованы известные бандлы, в том числе:

  • liip/imagine-bundle
  • vich/uploader-bundle
  • knplabs/knp-paginator-bundle
  • knplabs/knp-menu-bundle

Административная часть построена на sonata-project/admin-bundle с нашими модификациями.

Команда

Со стороны Evercode Lab в проекте участвовали:

  • Неустроев Николай — менеджмент
  • Голодяев Михаил — главный разработчик
  • Зубарев Егор — разработчик

Заключение

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

Оставить комментарий

Проекты: новый сайт судоходного агентства «Адмирал»

Feb 11, 2016, Николай Неустроев

Летом 2015 года мы закончили разработку нового сайта для столичной компании «Адмирал», которая занимается арендой теплоходов для праздников, а также организацией самих мероприятий.

Цели

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

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

Учитывая, что предшественник создавался достаточно давно, то оптимально было сделать все с нуля на современной технической платформе. Особых требований перед нами не стояло, поэтому мы работали на привычном для нас фреймворке Symfony2.

Подрядчик по дизайну

Проектированием и дизайном занялся наш друг Денис Фостер, для нас это уже не первое сотрудничество: мы вместе делали спортивный проект “Fitbooster”.

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

Результат

Главная страница

Главная страница встречает привлекательным встроенным видео.

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

На главной мы предлагаем пользователю 2 сценария:

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

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

Подбор теплохода

При подборе пользователю тоже предлагаются 2 сценария:

  1. Простой — получить одним кликом список теплоходов указанного типа;
  2. Продвинутый — самому настроить 5 параметров выборки: особенности теплохода, вместимость, форма мероприятия, стоимость аренды и день недели.

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

Страница теплохода

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

Дальше идут разные необязательные информационные блоки:

  • Описание особенностей теплохода
  • Акции
  • Доступные меню
  • Связанные кейсы портфолио
  • 3D-панорама

Портфолио

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

Второстепенные страницы

Другие страницы сайта, это:

  • Мероприятия и услуги
  • Причалы и стоянки
  • Акции
  • Ведущие
  • Контакты

Про внимание к деталям

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

Вот некоторые примечательные детали сайта «Адмирал»:

  • Меню сайта закреплено в верхней части страницы, однако “прячется” за экран, когда пользователь листает вниз, и появляется при прокрутке вверх. Таким образом, оно всегда доступно, но не отнимает пространство, которое может быть очень ценным на небольших мониторах ноутбуков
  • На главной странице в верхней части видео используется градиент, чтобы с одной стороны сделать четко видимыми логотип и телефоны, а с другой — чтобы оставить для фонового видео максимальную площадь экрана
  • И в других местах, где используются подписи к фото, мы позаботились, чтобы они хорошо читались
  • Кнопка “Заказать теплоход” в меню заметно выделяется, но не бросается в глаза
  • На странице подбора показывается число соответствующих условиям фильтра теплоходов и это число сразу обновляется при изменении параметров
  • Любые перелистываемые на сайте элементы, в частности фотографии на странице теплохода и отзывы на главной странице, можно листать как по нажатию на стрелки с боков, так и перетаскиванием — это удобно при большом количестве объектов и при просмотре сайта с мобильных устройств.
  • На всех страницах доступен быстрый поиск по названию теплохода, который работает без задержки
  • Обновление списка найденных теплоходов происходит быстро и плавно
  • В форме Заказа теплохода (которая доступна из любого места сайта) название теплохода подставляется само, если пользователь открыл форму со страницы теплохода или кейса
  • На всех изображениях сайта используется водяной знак для защиты, при этом он сделан небольшим, одиночным и полупрозрачным — это оптимальный баланс между надежностью и удобством для пользователя
  • В разделе портфолио для каждого из кейсов сразу указано, на каком теплоходе проводилось мероприятие.
  • Мы отказались от уже ставшего классическим, но теряющего популярность метода подчеркивания всех ссылок на сайте. Вопреки заблуждениям, это не влияет на правильное восприятие сайта, но при этом улучшает его внешний вид

Факторы успеха

Можно выделить следующие факторы, которые помогли нам сделать хороший проект:

  • Работа с настоящим действующим бизнесом, приносящим людям пользу
  • Четкое представление у заказчика о желаемой цели
  • Искренняя заинтересованность заказчика и активное его участие в процессе, при полном доверии к нам
  • Наработанное партнерство с компетентными подрядчиками (дизайнером и верстальщиком)
  • Каждый из членов команды привносил и воплощал на проекте свои собственные идеи
  • Обдумывание многих мелочей и реализация только устраивающего всех варианта
  • Много интересного фото-контента, большая работа с ним со стороны заказчика

Что можно было сделать лучше

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

Как шел процесс

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

На тот момент мы использовали “Basecamp” для учета договоренностей и задач по дизайну и верстке. А все, что связано с программированием, велось в сервисе “Youtrack”. Это было не во всем удобно, поэтому про организацию нашей работы в то время нет смысла рассказывать подробно — позже мы полностью перешли на “Trello” и “Google Docs”, сохранив те же принципы и даже их улучшив. О том, как именно мы ведем проекты сейчас, мы скоро напишем отдельно.

Технические особенности

Проект написан на Symfony 2.6 и использует ряд популярных бандлов, например:

  • liip/imagine-bundle
  • vich/uploader-bundle
  • knplabs/knp-paginator-bundle
  • knplabs/knp-menu-bundle

Административная часть сделана с помощью sonata-project/admin-bundle, который мы существенно изменили для большего удобства. Например, написали инструмент для управления галереями фотографий.

Команда

Над проектом работали:

Заказчик:

  • Наталья Грушина — директор ООО «Адмирал»

Менеджмент:

  • Неустроев Николай

Программирование (Evercode Lab)

  • Голодяев Михаил
  • Цициновский Михаил

Другие участники (не сотрудники Evercode Lab)

  • Фостер Денис (дизайн)
  • Ожерельева Ирина (верстка)

Заключение

Сайт «Адмирал» оказался приятным проектом, с удобным современным дизайном и интересными задачами по программированию как клиентской, так и серверной части.

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

Оставить комментарий

Выступление на WebConf Riga 2015

Jan 29, 2016, Roma Lapin

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

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

В этот раз я выступил с докладом “Building REST API with Symfony: experience, errors and recipes”. С большой помощью Оли и Сергея я резюмировал наш опыт создания RESTful API для мобильных приложений и Single Page Applications с помощью Symfony. Ниже вы можете посмотреть слайды и видеозапись выступления (на английском).

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

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

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

Отдельное спасибо главному организатору конференции Арвиду за приглашение, достойный уровень организации и компанию!

Оставить комментарий