Когда пишете программу, всегда относитесь к ней как к тексту, который будет читать другой человек. Раньше, когда программу писал и поддерживал один человек, это было не так важно. Сейчас разработка ПО это командная работа, в которой должно быть гарантировано качество. Компьютеру все равно, как выглядит ваша программа стилистически, а людям нет. Те, кто будет работать с вашим кодом в дальнейшем проверять его, оптимизировать скорость работы, переносить на другую платформу, должны понимать его без лишних усилий. Если код вызывает вопросы, автора просят внести изменения так, чтобы текст стал читаемым и однозначным. Это одна из целей инспекции. Аналогичные стандарты работы действуют и в аналитике. Но есть несколько отличий от обычной разработки, расскажу о них далее.
В разработке используется система контроля версий, например Git. Через нее разработчики вносят изменения в аналитическую систему компании и проводят инспекцию. Я рекомендую весь код держать в системе контроля версий. Плюсы такого решения:
все изменения будут прозрачны;
в случае ухода разработчика/аналитика весь код останется у вас;
если возникнут проблемы легко откатить изменения, вернувшись к прошлой версии.
Инспекцию кода относительно легко сделать для всех артефактов аналитики, кроме инсайтов. C инсайтами не все так однозначно. Для их поиска и выкладок используются разные инструменты: Excel или его аналоги, графический интерфейс аналитической системы, SQL, блокноты Python или другого языка (например, Jupyter Notebooks). В таких задачах обычно присутствует несколько этапов:
получение данных;
их очистка;
анализ;
выводы.
На каждом из этапов желательно проводить отдельную проверку. Получение данных часто это код, например SQL, проверить относительно легко: посмотреть, нужные ли данные были использованы. Кстати, при планировании очень полезно обсуждать, каким образом будет решаться задача, на что обратить внимание и какие данные могут понадобиться. При этом взять за основу можно похожие задачи из прошлого опыта. В процессе проверки будет легче соотнести решение задачи с тем вариантом, о котором договорились на планировании. Советую ограничивать время на такие задачи, иначе можно искать инсайт до бесконечности. Очистку данных и анализ проверить сложнее, но если там есть код, это упрощает дело.
Есть одна проблема с блокнотами (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. Скорость работы такого продвинутого специалиста может быть на порядок больше, чем одностаночника. Знания дают свободу.