Разработчиков сайтов легко делить по критерию «профессия руководителя-основателя».

Кто-то «бывший программист», и пишет «про код». Какие крутые штуки замутили, сколько полей, связей, какой там lazy load и удаленная синхронизация по SOAP’у с OAuth. Упоение новой технологией вместо смысла.

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

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

Мне кажется, что не решают.

Решает с одной стороны, глубокий профессиональный бэкграунд, а с другой, дозревание до бизнес-смыслов в своей работе.

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

Что для меня хороший технологический кейс?

Это три аспекта:

• Должно быть ясно «зачем вы это делали?».

• Должны быть собственно технологические детали, показывающие осмысленность и сложность решений;

• Кейс должен быть прилично оформлен.

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

Первичный отбор

Из 45 работ часть были совсем не про технологии. Часть были совершенно тривиальны, на уровне «среднего профессионального уровня».

Я провел грубое предварительное отсеивание по нескольким критериям.

0 баллов — «на отстань».

1 балл — что-то делали, но ниже среднего.

2 балла — «как надо», но без огня.

3 балла — выдающийся результат.

Итого = Интеграции + Хайлоад + Бекенд + Фронтенд + Оформление кейса.

На это ушло часа полтора, явно выделились потенциальные лидеры и аутсайдеры.

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

Так определились кандидаты в лидеры.

Потом я потратил на каждого претендента примерно минут по 40 и отобрал лучших. Лидер, кстати, сменился.

Итак, лучшие технологические кейсы месяца на мой взгляд:

Сервис сбора и анализа объявлений о продаже б/у автомобилей

Есть много демотиваторов про #матан.

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

Я думал, что видел все, пока не дочитал до заголовка «Лингвистический анализ. Применение алгоритма TF-IDF для оценки качества объявлений».

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

Пройдемся по деталям:

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

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

• Интерфейс (личный кабинет) ввода данных для операторов даже технологически — непростая штука. С содержательной точки зрения все еще серьезнее: статусы, роли, потоки данных, виджеты.
  
  Авторы проектировали и развивали этот интерфейс старательно и долго.
  Под этой фразой из кейса хочется подписаться:

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

  Не обошлось без странностей: роль «1» и «sms» явно не к месту. Или я не в теме.

   

  

• Триггерные sms-рассылки, автоматизация работы с авторами объявлений. Мало того, что все это продумано и сделано, оно еще и вынесено в настройки.

• Собственная система статистики поверх парсера и личного кабинета оператора.

• Автоматическая публикация вручную создаваемых объявлений на сайтах avito, drom, auto.ru

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

О недостатках

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

Богу богово, кесарю кесарево. IMNSHO нерентабельно работать с большими данными и сложными алгоритмами на веб-сервере.

Также портят общее впечатление картинки, сжатые по вертикали (или страннейшие шрифты). Так много труда — и такая негламурная графика в подаче.

Закончу описание этого кейса цитатой из него же:

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

Всем бы так.

Создание интернет-магазина по продаже сантехники

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

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

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

В-третьих, управление ставками в Яндекс.Маркете и возможность видеть цены конкурентов. Это тоже все хотят, но мало кто делает.

В-четвертых, личный кабинет водителя на доставке.

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

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

Система регистрации защиты проектов для Schneider Electric

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

Разработка автоматизирует внутренний процесс Заказчика — прием от внедренцев заявок на проекты и последующее управление этими заявками.

В кейсе описан уже привычный после первого набор технологических штуковин:

• Развитый личный кабинет партнера

• Статусы, учет, фильтрация, роли

• Уведомления, письма

• Экспорты в Excel и PDF, архивация документов в ZIP

• Самописная система отчетов

• Логирование действий в системе

МОЛОДЦЫ.

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

Не победители, но достойны упоминания

Перепахать трактором: «Битрикс24» для компании «Визарт Лаб»

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

Работа большая, видно.

Хотелось бы понять: стоимость коробки + стоимость владения подобным решением оказались лучше других вариантов? Клиент доволен и результатом, и стоимостью?

Федеральный адаптив: Создание федерального сайта доставки сети ресторанов «Перчини»

Примечательно несколько вещей.

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

Результат пристойный.

Хотя:

• другой домен и другая верстка — все же не адаптив. Это классическая «мобильная версия»

• я случайно нашел баг: если с мобильного зайти на /catalog/pizza/, а не на главную страницу, редиректа на поддомен не происходит и приходится смотреть, как расползается верстка десктопного сайта на телефоне.

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

Неужели у Заказчика нет системы учета, откуда эти данные стоило бы просто вытянуть?
Точка риска, точка потерь. Кроме того, если надо внезапно поменять ВСЕ цены, это упражнение на много часов. А в системе учета вполне могли бы быть автоматическая обработка и быстрый импорт.

Впрочем, одинокий «Новосибирск» в списке городов намекает, что сеть не очень федеральная.

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

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

Ну и на десерт: победа над HotSpot-устройством и загрузка туда дизайна «в стиле сайта и мобильной версии» — нечасто встречающаяся, хотя правильная задача.

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

Десерт: Сайт для врача уролога андролога

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

Контент тоже доставляет: пакет «Простатит» так и хочется приобрести, особенно при поминутной тарификации консультаций.

Пробовать не стал, не буду врать.

Выводы и пожелания

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

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

Думается, что умному клиенту важно то же самое.