Иван Константинов
•Descargar como PPTX, PDF•
1 recomendación•359 vistas
Иван Константинов Mindbox Дешево прототипируем сложную систему с помощью Google
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Иван Константинов
Similar a Иван Константинов (20)
Más de CodeFest
Más de CodeFest (20)
Иван Константинов
- 1. Дешево прототипируем сложную систему с помощью Google 1 апреля 2017 Иван Константинов Scrum-master dev1 1
- 3. Mindbox — SaaS-решение Платите за подписку Платеж раз в месяц Мы сами посчитаем 3
- 4. Как это было Тариф зависит от размера БД Тарифы лежат в договоре Считаем руками 4
- 5. Растем Клиентов больше Много договоров и доп. соглашений Скидки, метрики, опции 5
- 6. Первого числа каждого месяца 6
- 7. П — П… Процесс ?! #@*! А откуда цифра? Менеджер Бухгалтерия Клиент 7
- 8. х20 — «бомбит до 20-ти раз чаще» — Забыл про скидку! — Не учли опцию! — Ошиблись в расчетах ( — А сколько мы получим в этом месяце? — А сколько мы заплатим? 8
- 10. Как жить 1 0
- 11. Конфетку? 11
- 13. Биллинг v1 А откуда цифра? Менеджер Бухгалтерия Клиент 1 3
- 14. Я тебя не съем Мне нужны ваши опции, комментарии и обновления тарифов! 1 4
- 15. 8 месяцев — полет нормальный Автоматические уведомления Фоновые задачи перерасчета 1 5
- 16. Допилить Убрать тормоза Получать опции автоматом Убрать программистов 1 6
- 18. Прокачали биллинг Continious Integration Авто-тесты + Деплой JavaScript → TypeScript 1 8
- 19. Биллинг v2 А откуда цифра? Менеджер Бухгалтерия Клиент 1 9
- 21. Все это круто, но что мешало — купить готовое — написать сразу нормально 2 1
- 25. Написать сразу нормально • Автоматический деплой — 2 дня • Форму добавления нового проекта с обработчиком – 2 дня • Структура документа — 3 дня • Перенести код на TypeScript, добавить новое — 4 дня • Сервисы отправки данных о метриках и опциях — 2 дня • Производственный календарь — 1 день Итого: 14 дней 2 5
- 26. Написать сразу нормально • БД, проект, деплой, настройка окружений — 1 день • Разработка всего UI без бэкэнда – 18 дней • БД, сущности, тестовая инфраструктура — 4 дня • Бэкэнд для расчетов и задачи пересчета — 10 дней • Сервисы отправки данных о метриках и опциях — 2 дня • Производственный календарь — 3 дня Итого: 38 дней 2 6
- 27. Написать сразу нормально — Это дорого. © Наш генеральный директор. 2 7
- 28. Плюсы полученного решения 2 8 • Не отнимают ресурсы • Excell умеют все • Прозрачные расчеты • Много функций из коробки
- 29. В итоге 1. Это инструмент, а не панацея 2. Мы инструмент попробовали — работает 2 9
- 30. Однажды 3 0
- 31. Бил-линг 3 1
- 33. Спасибо! 3 3
Notas del editor
- Добрый день. Меня зовут Иван, я работаю в компании mindbox и сегодня расскажу, как мы изменили один важный процесс у себя в организации.
- С технической точки зрения, чем мы занимаемся в mindbox? У нас свой продукт автоматизации маркетинга, с помощью которого мы строим с конечным потребителем персональную коммуникацию на основе действий потребителя. Это значит, что в базу данных конкретного проекта мы собираем информацию и о потребителе, и о том, что он делал на сайте или в мобильном приложении — где-то в сети, потом на основании автомагических расчетов засылаем потребителю коммуникацию, стимулируя к совершению целевых действий. Выручка нашего клиента растет.
- Мы предоставляем услуги по модели SaaS, т.е. можно оформить подписку и пользоваться сервисами, когда потребность отпадет - перестать пользоваться сервисами. Долгое время мы тихонечко продавали услуги небольшому количеству клиентов, в спокойном режиме появлялись новые клиенты. Вместе с этим медленно, но верно усложнялся интересующий нас сегодня процесс - ежемесячный процесс выставления платежей клиентам.
- Все это было к чему: Мы собираем кучу информации и с течением времени базы клиентов сильно растут. Так как мы предоставляем сервис – у нас есть периоды подписки, которые надо оплачивать. Договор заключаем на год, платят нам раз в месяц. Ответственность за расчеты с первыми клиентами полностью лежала на бухгалтерии, тариф был простейший, всей работы было раз в месяц отправить платежку на фиксированную сумму и работа сделана. Появились новые клиенты, с ними новые тарифы и в процессе появилась метрика "количество потребителей в базе данных" - старые клиенты росли, на поддержку уходило больше денег, мы перезаключали договоры с ними и заключали на этих условиях договор с новыми клиентами. Тут в процесс вступили менеджеры: менеджер смотрел количество потребителей в админке конкретного проекта и передавал в бухгалтерию по требованию.
- Клиенты становятся больше – их базы данных растут, что делает поддержку дороже. С увеличением числа клиентов становится больше тарифов. У некоторых старых клиентов оставались старые тарифы. Вся эта информация хранилась в клиентских договорах, чтобы отправить платежку - открой каждый договор и посмотри тарифы. И проверь дополнительные соглашения. Еще наши клиенты любят скидки - каждая скидка отдельно оговаривается сначала с менеджером в почте, потом в почте утверждается с гендиром, потом бухгалтерия про скидку должна помнить. Или менеджер. Или гендир. Продукт растет и развивается, у нас появляются различные опции, которые можно тарифицировать по отдельности. Добавляем это в новые тарифы. Базы данных некоторых клиентов растут очень быстро и становится понятно, что метрика "количество потребителей" необходима, но не достаточна, поэтому появляется вторая метрика в тарифах "количество действий потребителей". А потом наступает расчетный период.
- И у бухгалтерии припекает так, что можно согреться. К ноябрю 2015 года появилось осознание, что скоро проектов будет сильно больше - мы начали активно продаваться. Это означает, что скоро бухгалтерия будет очень долго в начале каждого месяца закрываться на «расчет». Ну и куча однообразного ручного труда никому не добавляла оптимизма.
- Все это, потому что процесс для расчета с одним клиентом выглядел так - бухгалтерия запрашивает данные по проекту у менеджера - менеджер проверяет почту — может договорился о скидке или особенных условиях; проверяет скайп и другие мессенджеры, может там договорился; вспоминает, может договорились устно на каком-то статусе; в админке проекта смотрит циферки про количества; выясняет у программистов, какие опции включены на проекте. - Менеджер передает все данные в бухгалтерию - бухгалтерия поднимает договор клиента, доп. соглашения, смотрит тарифы, учитывает количество дней для неполных месяцев подписки - считает ручками цифру и формирует платежку.
- -- (х20) И так по всем проектам, которых на тот момент было 20 штук. И, конечно же, на каждом шаге регулярно случались ошибки «забыли», «не учли», «ошиблись». А еще гендир не знает примерно до 10 числа каждого месяца, сколько получим денег. Или вот потребовалось срочно посмотреть, сколько клиент платит денег - страдай, иди в бухгалтерию, чтобы она тоже страдала и смотрела последние платежки. То же самое, если клиент заранее спрашивает "Сколько мы в этом месяце заплатим?". Хотя вопрос совершенно резонный.
- Этот Процесс был похож на монстра. Тяжелый, огромный, затратный, откровенно страшный и он точно не масштабировался на 50, 100 и более клиентов. Если оставить как есть, он бы начал сильно кушать ресурсы бухгалтерии и всех остальных.
- Встал вопрос «что с этим делать?» Болело уже у всех, кто был в курсе положения дел, и каким-то неведомым образом, честное слово - не помню, мы обсудили этот вопрос с генеральным директором. Разговор получился быстрый и адекватных вариантов-то было всего два
- либо мы берем готовое решение за много денег, интегрируем, настраиваем и вот это все, либо пилим что-то свое. Можно на коленке, пусть хотя бы сейчас отпустит и у нас появится время на обдуманный выбор готового решения. Время близилось к новому году, внедрять что-то большое под конец года точно не будем, да и денег на это никто не планировал в бюджет, значит готовое только в новом году – еще пару месяцев мучиться. А вот если у меня есть время и интерес — окау, можно попробовать что-то запилить, но только, если это дешево и быстро.
- Я на тот момент заканчивал обучение на первой ступени в школе стажеров Горбунова и на себе испытал силу гуглоформ - дешевое решение работало, как часы. Они использовали бесплатный механизм для тестирования студентов и делали это очень хорошо. Я вооружился гуглом, справочником функций по гугл-скрипту и в свободное от основных обязанностей время накидал в блокнотике код для первого прототипа системы биллинга: есть гуглоформа для заполнения первичных данных по проекту – там порядка 20 полей: название проекта, даты договора, тариф, скидки, и опции, которые точно будут включены в начале. Данные из формы попадали в таблицу, на событие отправки формы вешался обработчик, который проставлял нужные формулы в нужные ячейки. Чтобы снять с менеджеров обязанность смотреть цифры по количеству, в конечные проекты добавил сервис, который сам отправлял в гуглодок данные по метрикам. В итоге вуоля - все само считается!
- 15 декабря 2016 года совершенно внезапно оказалось, что первая версия биллинга получилась полезной и всем понравилась сильно больше, чем ручной ад. Да, версия была минимальной, а у бухгалтерии сразу появилась куча идей, чего туда добавить. Но уже стало сильно лучше: Скидки, суммы за месяц, тарифы, данные по количеству действий и потребителей - все само приезжало и считалось. Менеджерам осталось вовремя писать в биллинге про включение-отключение опций и изменения по условиям — на слайде письмо про изменения условий, а монитор – как раз про ручной труд для сбора опций. Бухгалтерии осталось контролировать актуальность данных и вручную рассчитывать неполные месяцы подписки – поэтому я оставил календарик под бухгалтерией. Гендир получил возможность открыть файлик и посмотреть, сколько денег получим за месяц и сколько получаем с каждого конкретного клиента. Процесс переродился и получил единую точку аккумуляции данных, необходимых для расчета платежей. На вопросы клиента по оплате стало отвечать сильно проще.
- Процесс переродился из жуткого монстра, пожирающего время и нервы, в нечто адекватное на полу ручном управлении при минимальной поддержке программиста. Стало очевидно, что с таким процессом мы сможем ехать ближайшие пол года, может, год. За это время, очевидно, мы успеем определиться с дальнейшим вариантом развития – покупать или пилить свое. Но пока «решение на коленке» оказалось достаточным.
- В итоге так мы ехали до сентября 2016. За это время мы научили биллинг слать оповещения в slack, добавили всякие удобняшки для бухгалтерии, чтобы автоматично выделялись цветом нужные им даты, цифры. Прикрутили несколько задач автоматического обновления данных. Все это средствами одного только гуглодока и богомерзкого js.
- В сентябре 2016 решили, что биллинг пора доработать - клиентов стало столько, что на открытие документа уходило 2-3 минуты. А клиентов все еще меньше сотни. А когда станет сто и больше, сколько минут будут тормоза? Причина такого поведения заключалась в моей ошибке при разработке первой версии – я руками написал на javaScript функцию расчета суммы и эту функцию использовал в UI гуглодока. Оказывается, так лучше не делать. На 20-30-40 проектах тормоза были незаметны, а потом стало резко плохо и начало болеть. Тем не менее, обращаю ваше внимание на то, как сместился фокус боли от процесса: был коммуникационный хаос при огромном влиянии человеческого фактора — сплошные нервы и факапы, а получили ряд формализованных технических проблем: ускорить загрузку документа; автоматически учитывать включенные опции - это последнее, что делал руками менеджер для сбора метрик; обеспечить добавление новых тарифов силами только бухгалтерии, без программиста.
- Еще одним важным обновлением при рефакторинге было обеспечить возможность работать с биллингом другим программистам, а не только мне. Это важно, тк биллинг v1 имел басфактор равный единице: случись что со мной и никто не сможет доработать или починить гуглодок. Поэтому одним из основных требований от руководства было поделиться знаниями с командой, желательно обеспечить возможность поддержки программистами из других команд.
- Распланировали работы и сделали все красиво. Из технических ноу-хау, не описанных нормально в интернете, можем похвастаться автоматическим деплоем кода в отдельную гугловую библиотеку. Естественно, переписали все с чистого js, который на самом деле не чистый, а с примесью гугловых функций, на type-script. Добавили тесты и на билд сервере устроили автоматическое тестирование. Обеспечили деплой одной кнопкой. В итоге получили нормальный проект на языке, который знают все программисты в конторе. Моя часть работы заключалась только в переносе старого кода на type-script и создании адекватной структуры классов, все остальное в рамках рефакторинга и все последующие доработки делали уже другие ребята из команды - так я расшарил знания и увеличил басфактор. Показательно, что программист из моей команды позднее взял задачу на доработку биллинга и ни слова не спросив у меня выполнил задачу полностью сам – код написали так, что в нем можно разобраться без подсказок. Кроме того навели порядок в тарифах – всех клиентов сгруппировали по версиям тарифов и оформили все это красиво и понятно. Стало видно, кто одинаковый и кого можно пытаться перетаскивать на новые тарифы, чтобы убирать хаос в этом месте.
- 1 ноября 2016 боевое крещение прошла версия 2 Считает все моментально. Опции учитываются автоматически — у менеджера осталась только работа с письмами: если что-то менялось в условиях, об этом текстом пишут в биллинге. Добавили кучу дополнительной информации по каждому проекту для удобства и бухгалтерии, и менеджеров — доступ к договорам теперь сразу отсюда, например. Расчет за неполный месяц тоже автоматизировали – бухгалтерия больше не парится с календариком. Добавили оповещение клиентов по email о том, что из-за роста БД увеличатся затраты в следующем месяце. Прошло уже 5 месяцев, соответственно, 5 периодов выставления счетов. Уровень боли уменьшился кратно, теперь основное общение менеджеров и бухгалтерии свелось к просьбе от бухов к менеджерам постимулировать клиентов, которые задерживают оплату. Иногда менеджеры по запросу клиента просят расшифровку платежки, для чего в биллинге тоже сделали отдельный интерфейс, откуда все это копируется достаточно легко.
- Ручной процесс преобразился в почти автоматизированную систему. Почти - потому что бухгалтерия все еще руками формирует и рассылает платежки. Расшифровку платежа клиенту тоже нужно высылать руками. Тем не менее, затраты по времени сократились значительно, количество ошибок уменьшилось, а крутым побочным эффектом стало оформление требований к системе биллинга. Мы теперь точно знаем, что нам нужно: наш биллинг — это и есть требования. Так монстр, пожирающий время и нервы, превратился в полезного робота, экономящего время и нервы.
- Я уверен, у многих возникли вот такие вопросы Почему не купить готовое? Почему не написать свое сразу нормально? Отвечаю по порядку
- Первый - почему не купить готовое? Частично уже ответил - когда все началось, никто в общем-то не отказывался покупать, но только после НГ, а до НГ инициатива попробовать своими силами привела к тому, что срочность покупки готовой системы отпала. Второй этап рефакторинга осенью 2016 — уже вопрос покупки готового не стоял, потому что затраты на доработку своего вот этого сильно меньше: готовую сначала надо выбрать, потом купить, потом интегрировать с нами и нашими внутренними сервисами для автоматического получения данных, а потом поддерживать. А если мы выберем SaaS решение для биллинга, то и платить каждый месяц.
- Ну и важное: системы биллинга на рынке - это звездолет, а нам нужен маленький робот. Может, нам он и нужен, но пока найдешь правильный звездолет и кастомизируешь под себя, опять пройдет время. В итоге решили, что на диапазоне в год, в течение которого мы планируем использовать наш новый биллинг, мы точно потратим меньше, если доделаем свое.
- Второй вопрос - почему сразу нельзя было написать «нормально на нормальном языке»? В случае с первой версией все понятно — я написал ее на коленке и как-то поехали. А почему не отрефакторили по-нормальному? Весь наш продукт написан на стеке microsoft: код на C#, базы на сиквеле, везде винды. Бери и делай сразу решение на шарпе, тем более все программисты его знают, а как там гуглодоки работают — разобраться еще надо. Логично звучит, но по факту, доработка прототипа на гуглодоках стоила дешевле нового продукта на C#, сейчас посмотрим на цифры с нашей грубой оценкой в днях.
- --- АКЦЕНТ на детали ГОЛОСОМ ДОБАВИТЬ --- Во второй версии биллинга мы сделали вот такие работы. Прочитайте, пожалуйста. Заняло все 14 дней. При этом стоит учитывать, что на начало работы над версией два я с TypeScript вообще не работал и переносил, обучаясь языку. Мой коллега, который помогал с дописыванием нового на TypeScript, тоже на нем почти не писал. Естественно, автоматически деплоить в гугл мы тоже не умели и самое страшное, в интернетах не было пошаговой инструкции, поэтому два дня угробили. При этом у нас есть и тесты на typescript-код, и некое подобие сенсоров на адекватность данных в самом гуглодоке, т.е. с точки зрения сохранности данных и работоспособности кода все написано на том же уровне, на котором мы пишем код на шарпе.
- --- АКЦЕНТ на детали ГОЛОСОМ ДОБАВИТЬ --- А вот что было бы, если бы мы писали все на C# - развернуть БД, создать новый проект, настроить деплой, автотесты и все такое - 1 день - написать код: -- форма добавления нового проекта с учетом тестов и верстки и того, что мы пишем все на Redux - 3-5 дней -- интерфейс отображения всех данных по всем проектам (таблица) - до 5 дней с версткой -- интерфейс комментирования проектов менеджерами - 2 дня -- интерфейс редактирования проектов бухгалтерий - 3 дня -- интерфейс добавления новых тарифов - 3 дня -- добавить в БД на вскидку 11 таблиц и написать для них сущности, тестовые классые, написать тесты на очевидные ограничения - 3-4 дня -- бэкэнд для правильных расчетов - до 5 дней вместе с тестами -- задачи для оповещения, пересчета и прочих фоновых работ - 5 дней -- доработка в конечные проекты - еще 2 дня -- производственный календарь и функции для работы с ним - до 3 дней -- обеспечить поддержку кастомизации расчета итоговой суммы - хз
- Получили разницу по скорости в 2.5 раза в пользу велосипеда на typeScript. По деньгам разница примерно такая. Разработку биллинга на нормальном языке предлагалось передать в нашу самую прокаченную технически команду, которая обещала за месяц выдать готовое. Мы насчитали с вами 38 дней. Для ровного счета возьмем два рабочих месяца. Я не знаю, сколько стоит месяц работы в той команде у ребят – пока что мы зарплаты не открыли, но в среднем по Москве специалисты такого уровня получают 170 тысяч. Итого за два месяца мы бы отдали 340 тысяч рублей. В моей команде на тот момент таких зарплат точно не было, я знаю, кто делал биллинг и сколько дней. За 14 дней разработки мы отдали порядка 90 тысяч рублей. Получается по деньгам разница почти в 4 раза в пользу велосипеда на TypeScript. Комментарий к этому слайду нашего генерального директора: «Мне кажется, на C# было бы намного дороже». Поверьте, он знает кое-что о разработке ПО.
- Очевидные для нас плюсы решения на гуглодоках. Они не едят наши ресурсы на веб-серверах и серверах БД. Ресурсы, конечно, не ахти какие, но тем не менее. Пользовательский опыт идет сразу из коробки очень понятный – вы знаете бухгалтера или кого-то, кто работает с вебом, и при этом не знает основ работы с электронными таблицами? Полагаю, таких нет. Все расчеты понятные – при желании любой может разобраться, откуда взялась та или иная цифра в отчете, потому что видно все ссылки. Большое количество функционала идет сразу вместе с гуглодоками: можно обмениваться ссылками, есть история редактирования, экспорт, комментирование. Масса функций приезжает из коробки. Я ни в коем разе не призываю вас начинать писать системы на JS, обосновывая это дешевизной разработки. Например, у нас скоро встанет вопрос поддержки нашего прототипа на гуглодоках, где все расчеты сделаны на формулах внутри таблицы. Формулы уже похожи на ад и еще пара усложенений тарифов и поддерживать будет очень тяжело - в формулах разбираться сложнее, чем в коде. Но пока все равно дешевле.
- Подводя итог. А в своем выступлении я хотел сказать две основные вещи. Первая - есть инструменты, которые позволяют дешево прототипировать сложную систему. Инструменты бесплатные, а возможности у них очень широкие. Например, в нашем случае огромное количество головняка с разработкой юзер-интерфейса отпадает - интерфейс идет из коробки, при этом кроссбраузерный и адаптивный. А функционал под капотом позволяет делать рассылки, использовать веб-сервисы и стенд-элон библиотеки. Примерно так же мы использовали в своем основном продукте силу Excell – основные отчеты из системы мы выгружаем в файлах для этого офисного пакета, внутри файла уже есть сводные таблицы, графики и все умеют этим пользоваться. По факту это некий паттерн – если вам нужен табличный UI, возьмите готовый так или иначе, не пишите свое. Вторая - С помощью такого инструмента мы смогли из адского процесса, завязанного на людей, получить добротный прототип автоматической системы биллинга. Мало того, что мы получили саму систему с весьма обширным функционалом. У нас теперь есть требования к такой системе, что дает нам возможность уже в спокойном режиме либо выбрать и купить готовое, либо написать свое нормальное.
- Когда-то у нас появится крутая система биллинга, которая будет летать и все делать сама, но она будет сделана не вопреки, а благодаря прототипу.
- А пока у нас есть вот это и оно работает. Дешево. И сердито.
- Спасибо за внимание. Если есть вопросы - с радостью на них отвечу.
- Спасибо за внимание. Если есть вопросы - с радостью на них отвечу.
- Спасибо за внимание. Если есть вопросы - с радостью на них отвечу.