Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет! Меня зовут Алексей Пьянков, я главный программист в компании Спортмастер. Скажу сразу, что «главный» не значит «самый главный из всех программистов», нет, это только название, такой очаровательный перевод для «Senior+"».
В компании Спортмастер я работаю с 2012 года, и за это время командой разработки было сделано много решений, интересных с технической стороны. Но сегодня я бы хотел рассказать о нашей работе с акцентом скорее на том, как мы рассуждали в определенных неоднозначных ситуациях.
В этой статье не будет конкретных технических решений (да и вообще чего-то технического), которые следует хватать и применять у себя в проекте. Скорее — это рефлексия по проделанной работе. Были такие особые моменты, которые повлияли на нас как на команду — сплотили, закалили и проверили на прочность. Об этих моментах, об атмосфере работы в команде, о наших граблях и ряде психологических ловушек, в которые мы сами себя иногда загоняем, я и попробую сегодня рассказать.
И начну именно с 2012 года.
Я пришёл в 2012 с главной целью на то время — работа над нашим флагманским сайтом. В то время это был «монстр Франкенштейна»: часть команды работала с нашей старой системой, которая не очень круто справлялась с нагрузками (Bitrix), в другой части команды (куда входил и я) пытались внедрить новую систему, которую выбрали по критерию «Раз это самая дорогая e-commerce в мире, берем ее». Именно «пытались внедрить» — потому что система отчаянно сопротивлялась, и на каждый момент, с которым получалось разобраться, обязательно возникал «сюрприз» в ответ. Работали много, но продвигались со скоростью улитки.
Лично для меня последней каплей стало знакомство с кодом одного метода в этой «самой дорогой e-commerce в мире», когда несколько часов сосредоточенной работы над запутанным багом привели к тому, что причина была найдена где-то в custom-tag, который отрабатывает при генерации html в jsp. Задача этого custom-tag — отобразить сумму каких-то величин. Это неплохо, для этого custom-tag и предназначены. Но неожиданность спряталась в том, что при этом изменяются некоторые данные в базе, на это завязано поведение на следующих страницах, и если нажать F5 — вызов повторялся, это нарушало консистентность данных. Причем нарушало таким образом, что проявлялось только через несколько шагов, на 3-й странице последовательности. Нет, я не против, чтоб такой «мастер-ниндзя» был в команде и своим кодом поддерживал внимание коллег в тонусе. Но чтоб вот так, в либе самой дорогущей системы!
Это было в пятницу. А субботу и воскресенье мы с коллегой провели в офисе с целью разобраться, какие задачи бизнес ставит перед системой прямо сегодня и какие задачи может придумать через год. Соответственно, как бы мы их решали, если бы не были загнаны в рамки использования этой самой дорогой и самой выбешивающей системы.
Сказано — сделано. Мы сделали пилот, в котором заложили фундамент для разработки нового сайта Спортмастер. Многие из этих идей прижились и прямо сейчас их продолжение активно крутится на сайте.
Этапы пилота и временные рамки
2 дня. Сделали микропрототип — за выходные перегоняем нашу базу в ElasticSearch, делаем фасетный поиск. Вуа-ля! В той самой покупной системе такая настройка «съела» 2 недели. А здесь — буквально за пару часов! Да еще и работает быстрее. Причем быстрее на порядок.
2 недели. «Пилим» прототип, добавляем функциональность для адекватной персонализированной выдачи.
Например, у пользователя есть несколько скидок и акций, которые актуальны именно для него — тогда в результатах поиска на товарах нужно отобразить именно ту цену, которую можно получить, применяя все доступные плюшки самым выгодным способом.
С акциями все не так просто. Например, купил лыжи, теперь на шапочку скидка 40%, но при этом отменяется welcome-скидка 10% на весь заказ. Да-да, это реальный кейс :) И чтоб настроить такую акцию в покупной системе, было оплачено 3 консультации с поставщиком, в результате которых получили много примеров, как сделать разные другие акции. Очень дипломатично и, учитывая стоимость консультаций — очень неплохо экономически.
Показали бизнесу подробную демку. Пообещали быстро собрать пилот и сразу приступили к делу.
2 месяца. Пилотный проект — делаем в виде живого сайта с поиском по каталогу. Поиск с фасетами, результаты поиска — с персональными скидками, выглядит пилот почти как сайт Спортмастера, да и товары мы залили те же самые. Конфетка!
Добавляем «Красноречие:100» нашего начальника отдела, и презентация бизнесу проходит на Ура! Нам дают карт-бланш на то, чтобы разработать eCommerce-платформу самим.
А это значит, держите, парни, команду, держите, парни, бюджет. Круто же!
2 года. Вывод сайта в продакшн. Да, долго. Все, что мы тогда умели, мы пробовали только в масштабе прототипа. Два человека легко образуют слаженную команду. Да и задачи, которые мы «отщелкивали» — по большому счету это были небольшие допилы «Hello World» в новых технологиях. Мы легко генерили новые гипотезы, быстро их проверяли, не успевали привязываться и поэтому без сожалений их «убивали». Когда нас стало 10 человек, мы по инерции экстраполировали нашу скорость работы на всех остальных. И пообещали такие сроки выполнения задачи, которые равны представлению о прекрасном помножить на наш энтузиазм.
Знакомая ситуация? :)
Тогда, вы уже знаете, что будет дальше?
Ловушка №1. «Экстраполятор-крутыш»
Понятно, что новые технологии выглядят очень круто в презентациях и отлично показывают себя в приложении разряда «Hello World». Но реальность обычно чуть дальше от этого.
Так вот. Берем библиотеку, пишем кучу прикладного кода. Юнит-тесты считаем обузой (мы же крутые и пашем на сверхзвуке тут, код современный и прочее). Постоянно меняем и дорабатываем API на ходу — ну какие тут тесты, серьезно. И все это под знаменем «круто оптимизировали процесс разработки» (да, сейчас это даже описывать страшно).
А дальше все довольно очевидно.
Выкатываем новый билд на uat. Ребята из бизнеса бодро идут все это дело тестировать и нажимать кнопочки. Нажимают иногда довольно творчески — что-то отваливается. Тут бы пойти и узнать, что для этого сделали. Но по ту сторону монитора не упоротый тестер, который выкатит тебе все характеристики среды с учетом погоды в регионе, но заказчик из бизнеса. У него просто «не работает». А значит, он недоволен. Спроси его — и он будет страшно недоволен!
Тогда, чтобы воспроизвести баг, надо идти и перебором во все перетыкать. Конечно, мы не оставили без внимания ни одну жалобу и все фиксили. Бросали запланированные задачи, но «тушили пожар».
Так мы вырыли себе следующую ямку.
Ловушка №2. «Стахановец»
Прилетел тебе не самый приятный баг. Начинаешь разбираться. Не получается — гнев — попытка разобраться ещё раз — очередной облом — уточняешь все что можно — опять не то — думаешь о том, что ты уже старый и у всех дети и ипотека — пробуешь снова — опять не то. Нескольких кружек кофе, и все повторяется. 12-14 часов работы подряд — почти как норма. И вот, когда уже все на пределе — бац, озарение!
Возможно, со стороны, оценка для эффективности такого дня видна хорошо и правильно. А вот изнутри — может быть по-разному.
В моем случае впечатление от такой работы содержало «Я молодец, я крутой, я разрулил». Не всегда сознательно, но бессознательно — всегда!
И на это подсаживаешься, без шуток. Получается, что внутренние метрики успешности движения смещаются с результата на количество приложенных усилий и уровень того, какие подвиги ты совершил, как сильно ты страдал, пытаясь решать задачу.
Наверное, это самая страшная ловушка.
Дальше будет легче и веселее :)
Ловушка №3. Сила Hello world
Наш стек технологий того периода: ElasticSearch, Hazelcast, Pentaho, freemarker (и проверенные Java, Spring, Tomcat, nginx). Freemarker не очень информативно выдавал сообщения об ошибках. А вот ElasticSearch, Hazelcast, Pentaho пришлось патчить по несколько раз — мы талантливо находили кейсы, в которых они работали не так, как задано документацией.
Легкий старт и быстрые пряники от использования новой технологии — это хорошо, но они вводят в эйфорию и снижают бдительность. Потому что новая технология содержит баги, обязательно содержит баги. И если про них еще не написали — радуйся, именно тебе и предстоит стать тем первопроходцем, который по-любому наковыряет что-то кривое и пойдет гуглить или на SO. Конечно, «кривое» можно найти в проверенных продуктах, но в новых — это намного проще.
Несмотря на все сложности, в продакшн мы вышли. Да, с лагами. Да, не очень стабильно. Но в общем и целом — без катастроф.
Итого ещё разок отмечу ловушки, в которых искажается здоровое восприятие рабочего процесса.
- «Экстраполятор-крутыш». Под впечатлением текущих успехов идем и радостно экстраполируем скорость разработки на предстоящие проекты.
- «Стахановец». Работаем на износ, довольны собой, но не замечаем, что проблемы, которые решаем — это следствие наших личных ошибок/недочетов/пренебрежений. Works not to be done.
- «Сила Hello world». Спешим внедрить в production все самое новое и интересное.
Почему всё получилось
Конечно, я перечислил не все ошибки, которые у нас были за это время, но самые общие, вероятные для проекта любой специфики. Такая фиксация ошибок помогает избегать их в дальнейшем.
Немного о том, как у нас вообще получилось создать такой мини-стартап внутри компании и убедить бизнес съехать с уже купленной системы на что-то своё самописное.
Условие №0. Здоровый климат в компании. Это не только «горящие глаза» сотрудников и коммуникабельность в стрессовых условиях добычи печенек, нет. Это про все взаимодействия.
Условие №1. Верить в то, что делаешь. Серьезно, я не думаю, что у нас был бы хоть какой-то шанс, займись мы пилотом, не разобрав покупную систему «до болтика» — то есть, отступив и подсознательно зная, что эта система круче и уделает нас.
Что мы сделали: 1) разобрались в покупной системе, с ее помощью решили основные запросы от бизнеса 2) составили список задач, которые не только есть сейчас, но и будут в обозримое время 3) подобрали решение, которое подходит лучше. И тогда, наша оценка решения — это была оценка экспертов.
Дали бы нам чего-нибудь, если бы мы просто пришли и сказали, мол, “ребята, всё фигня, не хотим мы с этим разбираться и решили своё с нуля сделать”? Вряд ли. Причем ответ получили бы в такой форме, что хорошо запомнилось :)
Условие №2. Первый шаг делаем небольшим. Генерим первую гипотезу и проверяем. Можно потратить на это и свое личное время. Если не хочется тратить свое время — значит, вообще не стоит браться за такое дело. А если не хочется проверять малую гипотезу, а хочется сразу сделать круто и с блеском — держитесь от таких людей подальше!
Нам повезло, и сработала самая первая гипотеза. Но так бывает не всегда. Например, в одном из следующих проектов, когда продвигали админку в рамках похожего пилота, у нас сработал только 18-й вариант. И 17 первых подходов к снаряду были впустую. Кстати, в истории с созданием админки сюжетные повороты были на уровне бразильских сериалов, потому что команду составили парни, к тому времени уже ветераны, настоящие «тёртые калачи».
Условие №3. Делаем MVP и ищем боли у лица, принимающего решения. Конечно, у него может отражаться ужас на лице уже от того факта, что вы в тридцатый раз приносите ему какую-то затею. Но все равно. И обязательно показываем, как именно мы решаем его проблемы своим продуктом.
Условие №4. На коленке быстро делаем пилот, который выглядит примерно как финальный результат. Сделать всё совсем круто — заманчиво, но можно упереться в перфекционизм, из-за которого получится, что вместе пилота вы хотите показать пилотную версию уже идеального продукта. А их не бывает. Поэтому просто сделайте хотя бы из палок.
Условие №5. Продукт. Проект растет, получает финансы, приходят специалисты с солидным опытом.
И если вы классический стартапер, то это тот самый момент, когда надо со свистом валить. Потому что легкие полеты по самым верхам и ощущение общей благостности происходящего оперативно рассеиваются.
Выход в прод — это столкновение с реальными нагрузками, интеграция с десятком систем, причем когда создаешь новый функционал, то одновременно, в рамках сопровождения дорабатываешь старые версии. Все это — вызовы намного более серьезные, чем придумать идею и решить пусть и хорошо, но всего одну проблему клиента.
Это вызовы, и рост скиллов — происходит именно на этом этапе.
Спасибо, что прочитали. Happy New Code!
