Есть одна проблема с блокнотами (jupyter notebooks) – скрытые ошибки. В блокнотах выполняются разовые задачи (ad-hoc), и поэтому аналитики пренебрегают стандартами разработки – инспекциями кода и тестами. Как с этим бороться? Есть несколько способов проверить код и выводы.
Во-первых, проверяющий может очень внимательно просмотреть все решение на предмет ошибок. Это трудоемко, ведь по сути ему придется построить решение чуть ли не с нуля в своей голове. Во-вторых, можно воспользоваться другими источниками данных, которые хотя бы косвенно могли бы подтвердить вывод. В-третьих, можно последовать совету Кэсси Козырьков, директора по принятию решений в Google, из ее статьи «Самая мощная идея в анализе данных» [26]: сделать случайное разделение данных на два датасета (набора данных). По первому набору аналитик будет искать причину, а по второму проверяющий проверит выводы аналитика. Такой подход всегда используется в машинном обучении и называется валидацией (validation).
Хочу сделать важное замечание относительно решений, которые не используют код. В чем сложность их проверки? Представьте, что вы работаете в Excel и уже получили данные в виде файла. Вы должны загрузить его в Excel, проверить, почистить, написать формулы, построить таблицу или сводную таблицу (что удобнее для проверки). Теперь поставьте себя на место проверяющего. Часть операций в Excel делается мышью, данные можно копировать и вставлять блоками, протокола всех действий нигде нет. Чтобы посмотреть формулу – нужно кликнуть, а если таких формул много? И вы их «протягивали», а если ошиблись, исправили и не обновили все формулы? Чуть лучше с интерфейсами, где блоки выстраиваются графически и соединяются стрелками. Приходится щелкать по каждому блоку, проверять, все ли корректно. С кодом проверить все намного проще – все операции с данными написаны текстом! Не нужно никуда щелкать, все видно сразу. Еще один плюс кода – можно очень быстро пересчитать задачу – просто запустить код. В безкодовых решениях аналитику придется писать протокол – что и как он делал по шагам. Это облегчит проверку и даст возможность безболезненно повторить задачу в будущем. Конечно, Excel и другие визуальные инструменты очень ускоряют работу, я сам пользуюсь ими и не отговариваю вас. Моя задача обозначить плюсы и минусы этих подходов – что вам ближе, решать только вам.
Эти нюансы я понял, только когда стал работать в Retail Rocket, так как требования к качеству были значительно выше, чем на моих предыдущих местах работы. Раньше я проверял только результат, а теперь – все решение целиком.
Как тестировать и выкладывать изменения в рабочую систему
Если задача вносит изменения в рабочую систему, то следующий шаг проверки – выкладка (deploy) изменений. Здесь все выглядит стандартно для разработки, и вы можете использовать практики, принятые у ваших разработчиков. В аналитике Retail Rocket мы использовали CI/CD на основе GitLab, когда все изменения выкладываются нажатием одной кнопки. Мы думали, кто это должен делать, и после различных экспериментов сошлись на том, что это должен делать исполнитель задачи. Как таковых инженеров тестирования у нас нет, поэтому исполнитель переводит задачу в статус тестирования (Testing). Далее делает выкладку, следит за тем, чтобы тесты были выполнены и изменения отразились на работе системы. Например, проверяет, что нужные отчеты работают и предоставляют информацию в требуемом виде. Цели выкладки: отразить изменения в рабочей системе, проверить, что все работает так, как этого требует задача.
Как защищать задачу перед инициатором
У задачи есть инициатор, который ее поставил, и только этот человек может дать разрешение перевести ее в статус выполненной. В статусе тестирования, после выполнения всех расчетов, исполнитель задачи обращается к инициатору с просьбой проверить результат. Это может быть инсайт, отчет или какое-то программное изменение системы. Тут инициатор должен либо согласиться с результатами задачи, либо нет. В случае отказа я рекомендую сравнить то, что требует инициатор по результатам проверки, с постановкой задачи. Разница между тем, чего хотят от вас сейчас, и тем, чего хотели на этапе планирования задачи, может быть большой. Встречается такая ситуация довольно часто. Как с этим бороться, особенно если инициатор находится выше исполнителя в иерархии? Во-первых, правила игры должны быть известны всем и быть явно обозначены. Во-вторых, как я уже писал, нужно вести аудиозапись на встречах планирования. В-третьих, если условия задачи изменились существенно, то нужно признать, что результаты ее оказались ненужными и время было потрачено зря. А затем завести новую задачу, трудоемкость которой будет оценена отдельно.
Отдельная проблема – инициатор не выходит на связь и ничего не делает с полученными результатами. Это может свидетельствовать о том, что задача «перегорела» и больше не интересна, если, конечно, не было каких-либо форс-мажоров. Неплохо было бы узнавать такие новости до того, как на задачу были потрачены ресурсы. Что делать? Я боролся с этим пессимизацией приоритета последующих задач от таких инициаторов, но, откровенно говоря, смог позволить себе это только заняв позицию сооснователя компании.
Нужно ли уметь программировать?
Да, нужно. В XXI веке понимать, как использовать программирование в своей работе, желательно каждому человеку. Раньше программирование было доступно только узкому кругу инженеров. Со временем прикладное программирование стало все более доступным, демократичным и удобным.
Я научился программировать самостоятельно в детстве. Отец купил компьютер «Партнер 01.01» в конце 80-х, когда мне было примерно одиннадцать лет, и я начал погружаться в программирование. Вначале освоил язык BASIC, потом уже добрался до ассемблера. Изучал все по книгам – спросить тогда было не у кого. Задел, который был сделан в детстве, мне очень пригодился в жизни. В то время моим главным инструментом был белый мигающий курсор на черном экране, программы приходилось записывать на магнитофон – все это не идет ни в какое сравнение с теми возможностями, которые есть сейчас. Азам программирования научиться не так сложно. Когда моей дочери было пять с половиной лет, я посадил ее за несложный курс по программированию на языке Scratch. С моими небольшими подсказками она прошла этот курс и даже получила сертификат MIT начального уровня.
Прикладное программирование – это то, что позволяет автоматизировать часть функций сотрудника. Первые кандидаты на автоматизацию – повторяющиеся действия.
В аналитике есть два пути. Первый – пользоваться готовыми инструментами (Excel, Tableau, SAS, SPSS и т. д.), где все действия совершаются мышкой, а максимум программирования – написать формулу. Второй – писать на Python, R или SQL. Это два фундаментально разных подхода, но хороший специалист должен владеть обоими. При работе с любой задачей нужно искать баланс между скоростью и качеством. Особенно это актуально для поиска инсайтов. Я встречал и ярых приверженцев программирования, и упрямцев, которые могли пользоваться только мышкой и от силы одной программой. Хороший специалист для каждой задачи подберет свой инструмент. В каком-то случае он напишет программу, в другом сделает все в Excel. А в третьем – совместит оба подхода: на SQL выгрузит данные, обработает датасет в Python, а анализ сделает в сводной (pivot) таблице Excel или Google Docs. Скорость работы такого продвинутого специалиста может быть на порядок больше, чем одностаночника. Знания дают свободу.
