"Куда податься веб-разработчику с технологическим профилем?" Ищем ответ в ноябрьских кейсах CMS Magazine26.12.2016 11:36

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

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

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

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

Что вообще происходит со сложной веб-разработкой? Простые сайты делать просто. Да и конструкторов много. Порог вхождения низкий.

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

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

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

Что кодить, братцы? Из условно-массовых типов проектов пока остаются:

1. огромные интернет-магазины, которые «на тиражке не сделаешь»;

2. биржи, аукционы и uber-проекты, большая часть которых находится на стадии стартапа;

3. и «личные кабинеты оптовых интернет-магазинов» — специфические веб-интерфейсы для постоянных (часто профессиональных) клиентов.

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

Таких проектов все больше. ИНТЕРВОЛГА сделала три таких в 16 году, еще парочка на подходе и еще 2 мы запускаем в производство сейчас.

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

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

Сегодня на каждом из трех мест располагается по 2 работы.

1

В изумительном кейсе разработчики из AniArt рассказывают о создании интернет-магазина обувной сети INTERTOP.

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

Цитируя классика, могу сказать: «верю!». Это очень честный, глубокий и профессиональный кейс.

Важен очень высокий уровень организованности работы: отдельные KPI Заказчика и Исполнителя, много аналитических вставок в стиле «это было важно потому-то, мы сделали так-то, что привело к такому-то результату».

Процитирую:

…нашей первой задачей стал поиск консенсуса с заказчиком по двум вопросам:

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

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

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

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

Всем бы крупным интернет-проектам такого процесса и результата.

Это кейс-образец.

Замечание одно — при копировании текста на CMSMagazine довольно много мест, где потерялось оформление и заголовки слились с абзацами до и после, приходится иногда продираться сквозь путаницу. На сайте разработчика в полной версии все отлично.

У этого кейса есть некоторые особенности.

Во-первых, это кейс компании ИНТЕРВОЛГА, которой я руковожу. Его автор — мой коллега Антон Колодницкий на протяжении уже 1.5 лет работает с ЕВРАЗом и глубоко владеет темой.

Работу я рассматривал объективно в сравнении с прочими, но тем не менее не предупредить читателей о том, что это наш кейс — я не могу.

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

Так же, как в кейсе AniArt про INTERTOP, очевидна глубокая вовлеченность автора в предмет.

В-третьих, есть много уникальных функций. Кейс примечателен:

• Созданием развитого табличного интерфейса (намного функциональнее того, что предлагается стандартными «гридами» Битрикса, многого нет, например, и в Google Sheets)

  

  За основу брались «тяжелые» десктопные системы для управления и анализа данных.

• Интеграцией с несколькими внешними CRM-системами (через MS SQL-коннектор)

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

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

  

• Специфическим предоставлением доступа к файлами из внешнего по отношению к веб-интерфейсу хранилища.

Оцените, например, цитату:

…заранее неизвестно, существуют ли документы (!), есть только их название. Пользователь может запросить архив из 100 документов и только постфактум узнать, что документов-то в его архиве всего 10.

Получение документов происходит по следующей схеме:

• сайт передает в CRM описания документов, в ответ получает их ID;

• сайт передает ID, в ответ получает ссылки;

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

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

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

Работа необычная, яркая, хорошо поданная.

На втором месте сегодня две работы студии ФАКТ. Они похожи между собой, но каждая примечательна в отдельности.

2

Под невыразительным названием «обновление 2016» кроется большая работа над сайтом компании СлавДом.

Приведу одну цитату:

Мы реализовали обмен в режиме real-time с учетной системой 1С: Предприятие в 60 городах России. Интеграция с 1С обеспечила возможность: Разработать гео-зависимый каталог; Реализовать многоскладовость, отображение актуальных цен для всех групп пользователей; Обеспечить отображение остатков как для розничного покупателя, так и для дилера — в личном кабинете.

Этот короткий абзац скрывает большую боль внешней интеграции сайтов с 1С. Ключевые слова: 60 городов, realtime, личный кабинет.

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

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

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

Кроме базы, сделаны вещи, которые не так часто встречаются в интернет-магазинах:

• Калькулятор доставки с автовыбором подходящего транспорта и построением маршрутов для онлайн и оффлайн-заказов;

• Личный кабинет дилера, позволяющий не просто отслеживать историю и статусы заказов (это как раз несложно) и делать заказы по «своим ценам»(при наличии информации из 1С — это просто), но и получать бухгалтерские документы через веб-интерфейс (по offline и online заказам).

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

Работа большая, серьезная, глубокая.

В кейсе описан серьезный интернет-магазин, перенесенный на Битрикс с «другого движка».

Этот проект со многими складами и учетом местонахождения пользователя (например, как вам «геозависимые статусы товара»?).

Из интересного: поисковый механизм Elasticsearсh, кластерная архитектура на Percona XtraDB Cluster и много других необычных технических приемов.

Объявленная скорость работы «все страницы отдаются менее чем за секунду» не подтверждается: 1.6 с попадается на сайте сразу же.

Тем не менее для тяжелого сайта на Битриксе это неплохо.

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

3

И снова личный кабинет.

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

Кейс начинается как типичный «рассказ про дизайн и проектирование интерфейсов».

Но продолжается явно «программистскими шуточками про код», а в завершение приведен краткий, но красочный абзац:

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

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

Отмечу еще 1 интересный и показательный кейс от автора одного из лучших ноябрьских кейсов — AniArt.

Начну с придирок в стиле grammar-nazi. В отличие от кейса про INTERTOP, этот текст подготовлен и опубликован весьма неаккуратно, очень много ошибок, опечаток, рассогласования родов и чисел.

Это в первых четырех предложениях. Дальше — лучше, число несуразиц идет на убыль. То ли автор вступления другой, то ли редактор был в отпуске. Сам сайт (по крайней мере то, что видно без авторизации) пребывает в легком запустении. Смотрите:

Это не влияет на смысл, но это ОЧЕНЬ портит впечатление,»…ведь, совершенство в деталях» © сайт autoboss.

По сути — в кейсе реализован b2b-кабинет для закупки автостекол профессионалами.

Много специальных инструментов, описаны особенности b2b-площадок и профессиональных покупателей.

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

Кроме чисел и текста с сокращениями, на карточке товара ничего нет. Для полноценного продвижения не годится.

Процитирую вывод из кейса:

Широкий ассортимент, система скидок, умная автоматизация — все это помогает Autoboss оставаться конкурентноспособной компанией в современных бизнес-реалиях. От того, как быстро украинские компании поймут удобство B2B системы, зависит развитие всех видов бизнеса.

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

Работа большая, но в отличие от кейса INTERTOP, не производит такого wow-эффекта. Тем не менее — молодцы.

Вместо выводов

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

Итак, чеклист хорошего технологического кейса:

1. Сформулирована бизнес-задача.

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

   Важно: бизнес-задача это про деньги, сроки, счастье клиента, новые услуги и рынки. Это почти всегда не «про технологии».

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

2. Описано технологическое окружение будущей разработки.

   Например:

   1. Какие технологии уже применяются, какие смежные системы внедрены? Какие будут интеграции?

   2. Бородатые ИТ-директора любят говорить «наш стек технологий предусматривает…»

   3. Вот про это.

   4. Какие нагрузки будут в будущем?

   5. Как будет развиваться функциональность?

   6. Кто и как будет поддерживать решение?

3. Рассказано как вы принимали решение о способе решения задачи.

   Это стиль первокурсника — сказать: «мне нужна была программа и я ее написал. Теперь похвалите меня.»

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

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

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

   Единственное исключение — технологию прямо указал заказчик и вы описали ее в «окружении» как бизнес-требование «от коммерсов» или как ограничение «ИТ-департамента».

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

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

4. Представлено само решение.

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

   Без этого трудно судить о вашем профессионализме. И эксперту, и клиенту.

Заключение

Зачем писать технокейсы?

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

А расширение кругозора в духе «а как это еще могло быть сделано? Мы точно правы что сделали именно так?» — еще и необходимы.

Если вы профессионалы.

Полный текст статьи читайте на CMS Magazine