Журнал Wired недавно включил финтех-компанию ID Finance в топ-100 «самых горячих стартапов Европы». Продукты компании разрабатывают в Минске, в здешнем R&D — 200 человек. CTO Павел Шарейко рассказывает, чего ни в коем случае не надо делать.
О свободе микросервисной архитектуры, чрезмерной документации, любителях копаться в коде, «временных» костылях, отложенных «на потом» работах и языке, на котором cледует говорить с дизайнерами.
Вторая часть Вредных советов — тут.
1. Забивай на новые технологии
В рейтинге самых важных вещей для бизнеса и компании я бы поставил технологии на третье место. На первом всё-таки деньги.
Нет, все мы здесь не только из-за денег, но если компания не успешна, зачем тогда мы здесь собрались? На втором месте — качество основных процессов компании. Технологии — третье место, в том числе потому, что они прямо влияют на первые два.
Мне пришлось наблюдать однажды, как бизнес уже не в состоянии был сделать изменения ни логические, ни технические из-за того, что не развивали технологический стек. Помню, мы забирали один из модулей процессинга в московском банке. Работникам отдела было по 50-65 лет, проект написан на c+ (не C++, а ABCL/c+), и к нему не было вообще никакой документации. Проект превратился в чёрную коробку: как-то работает, лучше не трогай.
В старые проекты трудно вносить изменения не потому, что они плохие. Вполне возможно, что их писали отличные разработчики. Но рано или поздно эти разработчики учат новый стек, и переходят на другую работу или отправляются на пенсию. Новые разработчики на старый стек работать не пойдут, лучшие из «старой гвардии» уйдут — и в итоге поддерживать продукт останутся слабые девелоперы, которые не хотят или не способны переобучаться. Дальше — снежный ком: разработчики допускают больше ошибок, падает качество кода, усугубляется вымирание штата. А ведь штат — это самый ценный ресурс ИТ-компании.
Хотите терять хороших сотрудников, оставлять плохих, в конечном итоге не понимать, как работает ваш продукт, и убить бизнес — игнорируйте свежие технологии.
Мы в ID Finance, чтобы не оказаться в такой ситуации, переходим к микросервисной архитектуре: это даёт нам свободу пробовать разные технологии.
2. Тащи все новые технологии к себе — создай зоопарк
Это обратная сторона медали, другая крайность отношения к новым технологиям. Иногда разработчики экспериментируют, используют в задачах новые фреймворки или библиотеки, понимая, что на основной проект это никак не повлияет. Но когда эту функциональность позже дорабатывают другие люди, они сильно негодуют: приходится разбираться с незнакомыми технологиями, зачастую — забытыми или «невзлетевшими». Из-за этого дорожает время изменений.
Помню случай. Мы пробовали различные реактивные фреймворки, и так сложилось, что использование одного из них ограничилось двумя методами в коде. А сам компонент при этом содержал почти 60 классов не включая конфигурационные файлы. Когда позже этот код пришёл править другой разработчик, он вообще не понял, что там происходит: вроде нужно просто прочитать данные из базы и куда-то их отправить, а тут бац — 60 классов!
Вводить новые технологии и фреймворки нужно, и можно даже пробовать пилотные на рынке. Нужно, чтобы у людей оставалось место для творчества. Но у нас в компании такой шаблон: если вводим что-то новое, то смотрим, как оно работает. Работает хорошо — стараемся применить везде. Работает плохо — значит, в перспективе мы это из проекта уберём.
3. Не пиши документацию, а если уж пишешь — сложно всё запутай
Я видел много видов документации: от одного предложения до раздутых спецификаций, где функционал «добавить кнопочку на форме» описывался на трёх страницах А4. Оба варианта ужасны. Первый бесполезен, второй невозможно поддерживать в актуальном состоянии без негативного влияния на бизнес. Да и читать его не захочет ни один разработчик.
Детальность каждой конкретной спецификации должен определять домен, в котором вы работаете. Например, для финтех-компании самые проблемные вещи — калькуляции, связь с внешними интеграциями. Они должны очень хорошо документироваться. Остальные вещи у нас тоже описаны, но спецификации потихоньку устаревают, и их надо актуализировать. Мы просто устанавливаем триггеры: «этот документ должен быть обновлён через полгода».
Конечно, как ни старайся сделать код и спецификацию однообразными, всё равно найдутся мелкие несовпадения. Причина, как правило, человеческий фактор. Если у тебя хороший разработчик и хороший бизнес-аналитик, у них выйдет хорошая спецификация. Если в этой связке есть слабое звено — проблемы гарантированы.
Я скептически отношусь к различным BPMN (Business Process Model and Notation). Это дорого и сложно. Специфические визуализации не облегчают жизнь никому и требуют дополнительный софт и достаточно сильных технических специалистов на стороне бизнеса. Зато у нас хорошо работают собственные DSL (Domain specific language). Например, в кредитной политике основной алгоритм — это дерево принятия решений. Нам удалось описать это дерево на DSL по простым правилам, которые понимали и риск-аналитики, и бизнес-аналитики, и разработчики. Мы одним выстрелом получили и код, и спецификацию. Это лучший вариант из возможных.
4. Делай документацию для технических специалистов максимально абстрактной и неоднозначной
Мы работаем по agile scrum, но пришли к выводу, что абстрактные спецификации для технических инженеров — вредная практика. Да, для менеджмента они работают хорошо. Нужно увеличить approval rate (в финтехе и банках — «ожидаемая степень одобрения», один из факторов наряду с другими, по которым оценивают риск работы с клиентами, — прим. ред.) — выдаёшь менеджеру задачу «подключить больше кредитных бюро для анализа», без всяких деталей, и он идёт и решает её.
А вот разработчики — люди технические, и многие из них любят конкретику. В требованиях к задаче у них всё должно быть разложено по полочкам. И если какую-то деталь можно интерпретировать в нескольких вариантах, сразу возникают проблемы. Один разработчик быстро выберет лучший, по его мнению, вариант, и ни у кого не спросит. Другой захочет уточнить у своего лида, а если рядом никого нету, он будет смотреть, думать и ждать. А третий и вовсе проигнорирует эту деталь и сделает задачу в самом простом варианте. То есть первый вроде сделает хорошо, но не факт, что его решение подойдёт компании. Второй будет тормозить проект. А третий сделает, скорее всего, худший вариант из возможных. В любом из случаев времени придётся потратить больше, чем нужно. И всё это из-за абстрактной документации.
5. Подольше храни костыли в коде, оставляй в нём как можно больше «временных» TODO
Ты делаешь в коде какой-то костылёк и думаешь, что когда-нибудь потом его подправишь. Это «потом» никогда не настанет. Так в коде зависают «временные» костыли и отложенные «на потом» работы.
Как правило, чем дольше костыль остаётся в коде, тем сложнее его исправить. Зачастую приходится переписывать в продукте целый домен. Мы сражались с бизнесом за это время, пытались пояснить, что разрешение технического долга — это очень важно. В итоге мы добились того, что на technical debt наши разработчики тратят около 20% времени. Но и этого, увы, недостаточно. Если переписать целый домен — задача на месяц, то при тратах 20% рабочего времени команде для её решения нужно минимум пять месяцев. А с учётом срочных проблем с technical debt в других доменах — все семь.
Чтобы не растягивать время так сильно, мы выделили команду рефакторинга с отдельным бюджетом. Эта команда уделяет всё своё время разрешению технического долга и реализации пилотных проектов. Core-команда потом внедряет эти пилотные решения в конкретных проектах на конкретные страны. Шероховатости всё равно случаются, но без этого никак: чтобы довести всё до ума, нужно время. Главное, что мы последовательно снижаем technical debt: многолетних «временных» костылей и TODO в коде становится меньше. К слову, в основных командах 20% времени на technical debt мы оставили.
6. Не думай, как твой код будет работать в продакшне
Очень жизненная проблема. Есть разработчики, как правило, ребята помоложе, те, кто недавно пришёл к нам из аутсорс-компаний, которые совсем не думают о продакшне. Вот пришёл технически подкованный middle, даже middle+, сделал задачу, а на продакшне она не работает. Он заявляет: «А почему я должен об этом думать, если у меня есть лид? Я ему отдал задачу, он проревьювил. Всё, продакшн — это его проблема, не моя!» Конечно, это нерабочий вариант. Нужно думать о конечной цели. Если не думаешь — скорее всего, задачу ты сделаешь плохо.
7. Как можно детальнее разбирайся с кодом больших проектов, не ограничивая своё рабочее время
Есть люди, которым очень нравится разбираться, что и как работает. У них такая архитектурная жилка — так хочется разобраться, аж руки дрожат! Даёшь такому задачу на один день, он начинает разбираться с новым для себя функционалом. Задача затрагивает только 5% этого функционала, но ему хочется знать все 100%. В итоге разработчик вместо 8 часов тратит 40, а лида не предупреждает. А сказал бы сразу, и лид выделил бы для него время, даже в рамках той самой задачи. Конечно, не в пять раз больше.
8. Разработчик, отдавай на тестирование заведомо нерабочий код — потом закроешь багами
О таком паттерне поведения разработчиков в больших компаниях слухи ходят давно. При реализации задачи, чтобы успеть в эстимейт, разработчики заведомо недорабатывают какие-то вещи, которые потом прилетают к ним багами.
Говорят, случается даже так, что разработчик получает задачу — и сидит, пьёт чай, смотрит видео, а потом просто берёт и резолвит недописанный код. Начинается футбол: QA тратит время на создание дефекта, девелопер получает баг, наконец реализует задачу и закрывает дефект. Закрытие ведёт к созданию отдельной ветки, QA снова должен провалидировать эту задачу. Времени тратится уйма. Такие примеры у нас единичные и такое мы, конечно, не приветствуем.
9. Дизайнерам не нужны технические метрики — всё сделают сами
Основная задача, которую для нас исполняют дизайнеры, — создание макетов. Заказчиком может выступать кто-угодно: lead of marketing, front-end team lead. Он должен лично следить за процессом создания: как только появляются первые абстрактные концепции макета, стоит прийти к дизайнеру и выбрать одну из них, которая подходит лучше всего. Если сказать: «Ты мне всё нарисуй, а я через три недели приду посмотрю» — итоговый результат тебе наверняка не понравится.
Когда макет готов, есть два варианта работы с дизайнером: либо он отдаёт исходники разработчикам, и те всё нарезают и верстают, либо он всё нарезает сам. Небольшие компании часто работают с внешними дизайн-студиями и ради экономии времени выбирают второй вариант. Вот только сэкономить выходит не всегда. Бывает, фронтенд-команда получит «нарезку», посмотрит и не поймёт, что с ней делать: то ли менять размеры всех элементов, то ли вовсе проект перевёрстывать. Чтобы этого не случилось, дизайнерам нужно всегда выдавать точные технические метрики, которым должен соответствовать прототип.
10. Безопасник, пиши планы так, чтобы бизнес ничего не понял
Безопасность — вещь технически сложная, и бизнес зачастую в ней вообще ничего не понимает. Когда ты объясняешь, что отдел безопасности «сожрёт» ровно столько денег, сколько у тебя на него есть, топ-менеджмент идёт в отказ: «Так, может, она нам и совсем не нужна?».
Такие отделы, как безопасность, должны тщательно согласовывать с бизнесом свои стратегические планы. Если эти планы бизнесу непонятны, отдел долго не просуществует: его распустят, потому что он будет казаться бесполезным. И сами сотрудники в этом взаимном непонимании тоже будут ощущать себя демотивированными.
Понятные планы должен писать любой отдел, но к безопасности это относится особенно. Как только случится инцидент, например, уведут корпоративный почтовый ящик, — бизнес будет возмущён: «Мы платим за безопасность столько денег, а они даже не могут защитить наши ящики!». Возможно, security-инженеры за это время сделали защиту от ddos-атак, разобрались с фродом, сделали pen-тесты и защитили REST API. Но если бизнес не понимает, что это всё значит и зачем это нужно, один-единственный взломанный ящичек для них может показаться куда более важной проблемой.
11. Админ, не трать время на проверку результатов своей работы
Как правило, администраторы не любят проверять свою работу, часто звучит фраза: «Я 100 раз так делал». Просишь выдать человеку доступ на базу данных: «Ок, выдал». Через два дня приходит человек: «Не работает». Админ проверяет: «Ой, ну да, я забыл сделать flush privileges». Проверка результата работы — это 50% успеха работы.
Ещё один вредный совет для админов — не делать мониторинг. Zabbix у вас, Prometheus, ещё что-то — неважно, должен быть мониторинг всей инфраструктуры с настроенным СМС-оповещением о любых проблемах. И в идеале оповещения приходили автоматически. Когда у тебя всего один сервер, ты можешь просто туда периодически заходить и следить, всё ли в порядке, но если у тебя 200 серверов, без мониторинга ты физически не сможешь это сделать.
12. Аналитик, не разбирайся, как работает новая фича, когда пишешь спецификацию
Эта проблема до сих пор характерна и для нашей компании. Вот пример: от country-менеджера прилетает требование: «Хочу новую логику бонусов за привод в приложение друзей: если ты приводишь мальчика и девочку, бонус удваивается». Бизнес-аналитик просто берёт эти слова, записывает их в задачу как есть и отправляет в разработку. Не встраивает в существующую спецификацию, не адаптирует задачу для разработчика.
Программист открывает код и думает: «Какие ещё мальчики-девочки, у нас нет разделения по полу! И здесь древовидная логика, в какой ветке встроить новую часть?» В итоге он либо категорически отказывается это писать, либо пишет отсебятину. Пока бизнес-аналитик не разберётся, как работает существующий функционал, он не должен писать спецификации на новые фичи. Это очень разрушительная практика. Поэтому мы разбиваем приложения на домены и определяем минимального количества вопросов, на которые должен ответить бизнес-аналитик перед стартом.
Работа в ID Finance
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.