What I Do Before a Data Science Project to Ensure Success

eugeneyan

eugeneyan

Start Here Writing Speaking Prototyping About

What I Do Before a Data Science Project to Ensure Success

Что я делаю перед проектом по data science, чтобы обеспечить его успех

[ mechanism datascience productivity ] · 12 min read

[ mechanism datascience productivity ] · 12 мин чтения

When someone comes to me with a data science problem, I’m always rushing to dive in. Let’s explore some data, build something cool, create positive impact! Yeah… I’m impatient like that, though I like to view it positively as bias for action.

Когда кто-то приходит ко мне с задачей по data science, мне всегда не терпится сразу нырнуть в неё. Давайте поизучаем данные, построим что-нибудь крутое, принесём пользу! Да… я нетерпелив в этом плане, хотя предпочитаю смотреть на это позитивно — как на склонность к действию.

After working on a couple of projects, I started to wonder: Is this really faster? Was there a better way? I reflected on my work and realised that I lost time on things like:

Поработав над несколькими проектами, я начал задумываться: а действительно ли это быстрее? Есть ли способ получше? Я проанализировал свою работу и понял, что терял время на таких вещах, как:

Восхождение не на тот холм Использование базуки там, где хватило бы мухобойки Уход в кроличьи норы и тупики

To fix this, I put in place three pre-project tasks for myself. Some team members also tried it and found it useful. Here, I’ll share about the one-pager, time-box, and breakdown.

Чтобы это исправить, я ввёл для себя три предпроектные задачи. Несколько коллег по команде тоже попробовали и нашли их полезными. Здесь я расскажу про one-pager, time-box и разбиение задачи.

This is part one (before) of a three-part series on data science project practices. Also see part 2 (during) and part 3 (after).

Это первая часть (до) трёхчастной серии о практиках работы над data science проектами. Смотрите также часть 2 (во время) и часть 3 (после).

First, Draw The Map To The Destination (One-Pager)

Сначала нарисуйте карту до пункта назначения (One-Pager)

The map covers the intent, desired outcome, deliverable, and constraints.

Карта охватывает намерение, желаемый результат, поставляемый продукт и ограничения.

Intent (Why?)

Намерение (зачем?)

What’s the problem we’re trying to solve, or the opportunity we want to gain from? How will customers benefit? Why are we doing this, and why is it important?

Какую проблему мы пытаемся решить или какую возможность хотим использовать? Какую выгоду получат клиенты? Зачем мы это делаем и почему это важно?

“Management is doing things right; leadership is doing the right things.” - Peter Drucker

«Менеджмент — это делать всё правильно; лидерство — это делать правильные вещи». — Peter Drucker

Often, we get so excited about building something—anything—that we don’t stop to ask “Why?”. We just assume that it’s a good idea to build it. But, by taking the time to think through the problem and intent, we might realise that, hey, maybe we don’t need to fix it after all. Perhaps it only affects very few customers who are likely to churn anyway. Or that opportunity for a virtual-reality shopping mall kinda stinks. Either way, we’ve nipped needless projects in the bud.

Зачастую мы так увлекаемся тем, чтобы построить хоть что-нибудь, что не останавливаемся, чтобы спросить «Зачем?». Мы просто предполагаем, что это хорошая идея. Но, потратив время на обдумывание проблемы и намерения, мы можем осознать, что, эй, может, и не надо это чинить. Возможно, это затрагивает лишь нескольких клиентов, которые, скорее всего, и так уйдут. Или что возможность с торговым центром в виртуальной реальности так себе. В любом случае, мы зарубили ненужные проекты на корню.

Amazon’s ”Working Backwards” is a great way to identify the intent, and understand “Why?”. It starts by working backwards from the customer, and how they will benefit. This is distilled in a (mock) press release for customers. If the benefits don’t come across as interesting or exciting, back to the drawing board.

Подход Amazon «Working Backwards» — отличный способ определить намерение и понять «Зачем?». Он начинается с движения в обратную сторону от клиента и того, какую пользу он получит. Это формулируется в виде (учебного) пресс-релиза для клиентов. Если выгоды не звучат интересно или захватывающе — обратно к чертёжной доске.

Working Backwards Press Release for AWS S3

Пресс-релиз Working Backwards для AWS S3

Contrast this with “Build it and they will come”. It makes for a good movie quote but is actually pretty bad advice for product and tech. I know I’m often guilty of starting with some sexy idea or shiny new tech, building it, then trying to bolt customers on it.

Сравните это с «Построй — и они придут». Это хорошая киноцитата, но довольно плохой совет для продукта и техники. Знаю, что сам часто виноват в том, что начинаю с какой-то сексуальной идеи или новой блестящей технологии, строю её, а потом пытаюсь прикрутить к ней клиентов.

What happens if customer’s don’t come? That’s a lot of effort down the drain. Start-ups with limited resources can’t afford this.

А что, если клиенты не придут? Это куча усилий впустую. Стартапы с ограниченными ресурсами не могут себе такого позволить.

An unclear problem and intent also leads to another difficulty: How do we decide which solution is better? How do we know if we’re successful? By writing it down, we now have a point of reference. This can be used to compare across problems when prioritising, as well as to compare across solutions when designing.

Неясная проблема и намерение порождают ещё одну сложность: как мы решаем, какое решение лучше? Как мы узнаем, что преуспели? Записав это, мы получаем точку отсчёта. Её можно использовать для сравнения проблем при приоритизации, а также для сравнения решений при проектировании.

Desired Outcome (What?)

Желаемый результат (что?)

Now that we have the intent, we can discuss how success looks like. How well should we solve this problem? How do we measure it? In data science, this is usually a business metric such as conversion, savings from fraud reduction, net promoter score, etc.

Теперь, когда у нас есть намерение, можно обсудить, как выглядит успех. Насколько хорошо мы должны решить эту проблему? Как мы это измерим? В data science это обычно бизнес-метрика: конверсия, экономия от снижения мошенничества, net promoter score и т.д.

“If you can’t measure it, you can’t change it.” - Peter Drucker

«Если ты не можешь это измерить, ты не можешь это изменить». — Peter Drucker

With unlimited resources, we can solve any problem completely. But, we don’t have unlimited resources. Specifying the desired outcome, in quantifiable terms, prevents us from falling into the trap of chasing a moving target. We know when we’re past the finish line.

При неограниченных ресурсах мы можем полностью решить любую проблему. Но ресурсов у нас не бесконечно. Уточнение желаемого результата в измеримых терминах не даёт нам попасть в ловушку погони за движущейся целью. Мы знаем, когда мы пересекли финишную черту.

It also helps us decide which projects to pursue. Solving a problem to 95% could take 3-4x the effort of solving to 90%; solving to 99% might take 10-100x more. Given our limited resources (let me know if you have unlimited resources), we’ll likely choose not to pursue a problem that requires 99% accuracy (e.g., clinical diagnosis)—this lets us invest in something else more worthwhile.

Это также помогает решить, какие проекты брать. Решить задачу на 95% может потребовать в 3–4 раза больше усилий, чем на 90%; решить на 99% — в 10–100 раз больше. Учитывая ограниченные ресурсы (дайте знать, если у вас неограниченные), мы, скорее всего, не возьмёмся за задачу, требующую 99%-й точности (например, клиническая диагностика) — это позволит нам вложиться во что-то более стоящее.

Deliverable (How?)

Поставляемый продукт (как?)

Now, we can design a deliverable that meets the intent and desired outcome. How should we solve this problem? The solution should be designed to meet the intent and desired outcome, keeping in mind the need to integrate with the existing system.

Теперь можно спроектировать решение, отвечающее намерению и желаемому результату. Как нам решить эту задачу? Решение должно быть спроектировано с учётом намерения и желаемого результата, а также необходимости интеграции с существующей системой.

For example, an e-commerce platform has the intent of improving how customers discover and purchase products. To achieve this, should we improve search? Or recommendations? Or email campaigns? If it’s a recommender, how will we deploy it? Will it be a cache that’s updated daily? Or a service that accepts customer and/or product as input and returns a set of recommendations?

Например, e-commerce платформа имеет намерение улучшить, как клиенты находят и покупают товары. Чтобы этого добиться, улучшать ли поиск? Или рекомендации? Или email-кампании? Если это рекомендатель, как мы его развернём? Это будет кеш, обновляемый ежедневно? Или сервис, принимающий клиента и/или товар на вход и возвращающий набор рекомендаций?

This doesn’t have to be especially detailed; for now, we don’t need the full architecture and specs. But it’s useful to have a rough sketch to get upfront buy-in from the business, product, and tech teams. We don’t need a deliverable, with all the bells and whistles, that doesn’t deliver results. We don’t want to build a real-time, multimodal, deep learning recommender that cannot be integrated. Be sure to get feedback on this.

Это не обязательно должно быть детально проработано; сейчас нам не нужна полная архитектура и спецификации. Но полезно иметь грубый эскиз, чтобы заранее получить одобрение бизнес-, продуктовой и технической команд. Нам не нужен поставляемый продукт со всеми наворотами, который не приносит результата. Мы не хотим строить real-time мультимодальный deep learning рекомендатель, который невозможно интегрировать. Обязательно соберите обратную связь.

Constraints (How not?)

Ограничения (как не?)

How not to solve a problem is often more important than how to solve it. Unfortunately, this doesn’t get addressed enough.

То, как не решать задачу, часто важнее, чем как её решать. К сожалению, этому уделяется недостаточно внимания.

Providing teams with boundaries and constraints counterintuitively leads to greater creativity and freedom. Without constraints, we don’t know what we cannot do. Thus, we thread gingerly with incremental improvements. In contrast, with clear constraints, we know that we can do anything except breach the constraints—this is liberating and can lead to disruptive innovation.

Предоставление командам границ и ограничений парадоксальным образом ведёт к большей креативности и свободе. Без ограничений мы не знаем, чего нельзя делать. Поэтому мы крадёмся осторожно, с инкрементальными улучшениями. Напротив, при чётких ограничениях мы знаем, что можем делать всё, кроме нарушения этих ограничений — это освобождает и может привести к подрывным инновациям.

What’s the difference between boundaries and constraints?

В чём разница между границами и ограничениями?

Keep within the boundaries; keep out of the constraints.

Оставайтесь внутри границ; держитесь подальше от ограничений.

Boundaries enclose or limit something, such as the scope of a solution. For example, we might decide that our recommender will not be real-time for the first iteration. This boundary makes clear what we should not consider and frees us to focus on a recommender with daily updates.

Границы охватывают или ограничивают что-то, например, область применения решения. Например, мы можем решить, что наш рекомендатель не будет real-time на первой итерации. Эта граница ясно показывает, что нам не следует рассматривать, и освобождает нас, чтобы сфокусироваться на рекомендателе с ежедневным обновлением.

Constraints restrict or limit something from changing, such as business metrics. For example, if we’re deliberately introducing new, cold-start products in search, the constraint could be “not reducing conversion by more than 5%”. This constraint frees us to consider ideas that could lead to a conversion drop of 0 - 5%.

Ограничения запрещают чему-то меняться, например, бизнес-метрикам. Например, если мы намеренно вводим новые товары с холодным стартом в поиск, ограничение может быть «не снижать конверсию более чем на 5%». Это ограничение освобождает нас рассматривать идеи, которые могут привести к падению конверсии на 0–5%.

While they’re technically different, I refer to them interchangeably.

Хотя технически они различаются, я использую эти термины взаимозаменяемо.

Here’s a short story to illustrate a business constraint. Previously, I was given the goal of introducing new products on our search and category pages. The intent was to increase their (i.e., new product) impressions, CTR, and conversion.

Вот короткая история, иллюстрирующая бизнес-ограничение. Раньше передо мной стояла цель ввести новые товары на страницах поиска и категорий. Намерение заключалось в увеличении их (то есть новых товаров) показов, CTR и конверсии.

The obvious way to do this is to spam search results with new products, without considering customer experience (like a search engine with only ads) and overall business metrics. The other extreme is to err on the side of caution with insignificant changes (e.g., one new product a day); this will have no practical impact on the business and the goal. Both approaches would have been suboptimal.

Очевидный способ — заспамить результаты поиска новыми товарами, не задумываясь о клиентском опыте (как поисковик с одной только рекламой) и об общих бизнес-метриках. Другая крайность — перестраховаться и вносить незначительные изменения (например, один новый товар в день); это не окажет практического влияния на бизнес и на саму цель. Оба подхода были бы неоптимальными.

Thankfully, I was given a single business constraint to work with: “Don’t reduce conversion by more than 5%”. This provided a “budget”, as well as freedom to experiment within the constraint. As a result, we were able to ship a working solution quickly. (Note: While we expected conversion to decrease, A/B testing showed that it actually increased, albeit non-significantly.)

К счастью, мне было дано одно бизнес-ограничение: «Не снижать конверсию более чем на 5%». Это дало «бюджет», а также свободу экспериментировать в рамках ограничения. В результате мы смогли быстро выпустить рабочее решение. (Примечание: хотя мы ожидали падения конверсии, A/B testing показал, что она фактически выросла, хотя и незначительно.)

Technical constraints are common when building machine learning systems for production. Front-end would likely have latency limits of under 50-100ms, as well as throughput requirements (e.g., x concurrent requests). We might have to adhere to a certain interface, schema, or format that consumers expect.

Технические ограничения распространены при построении machine learning систем для production. Front-end, скорее всего, имеет лимиты по latency в районе 50–100 мс, а также требования к пропускной способности (например, x одновременных запросов). Возможно, нам придётся соблюдать определённый интерфейс, схему или формат, ожидаемый потребителями.

We might also be faced with resource constraints. Data science and machine learning pipelines can be compute and memory intensive. Model retraining might be required to complete in x hours given a cluster of y machines. This sets boundaries on how resource-hungry our pipelines can be, helping us focus on building something that can be deployed in production.

Также мы можем столкнуться с ресурсными ограничениями. Пайплайны data science и machine learning могут быть требовательны к вычислениям и памяти. Переобучение модели может требоваться завершить за x часов на кластере из y машин. Это задаёт границы того, насколько ресурсоёмкими могут быть наши пайплайны, помогая нам сфокусироваться на построении чего-то, что можно развернуть в production.

“Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage.” - 37Signals (now Basecamp)

«Ограничения двигают инновации и заставляют фокусироваться. Вместо того чтобы пытаться их убрать, используйте их в свою пользу». — 37Signals (ныне Basecamp)

One-pager (Medium)

One-pager (среда)

We write the intent, desired outcome, deliverable, and constraints in simple language on a single-paged document. This can be shared to stakeholders for their review, feedback, and buy-in. Doing this goes a long way to making sure that what we build will be used and was worth the effort.

Мы записываем намерение, желаемый результат, поставляемый продукт и ограничения простым языком на одной странице. Это можно поделиться со стейкхолдерами для их ревью, обратной связи и одобрения. Это сильно помогает гарантировать, что то, что мы построим, будет использоваться и стоит затраченных усилий.

This requires a certain amount of discipline from stakeholders. After all, the work comes at no cost to them. There’s nothing stopping them from changing their minds halfway through the project. However, a compelling intent and clearly defined outcomes and deliverables mitigates this risk.

Это требует определённой дисциплины от стейкхолдеров. В конце концов, работа им ничего не стоит. Ничто не мешает им поменять мнение в середине проекта. Однако убедительное намерение и чётко определённые результаты и поставляемые продукты снижают этот риск.

Writing one-pagers is now a must-do for me (though I may not circulate them). I often get lost in the woods of research, experimentation, and development. It’s too easy to get distracted by shiny new research and tech, or forget how it’s supposed to benefit the customer. Revisiting the one-pager has always gotten me back on track.

Написание one-pager теперь для меня обязательная практика (хотя я могу и не рассылать их). Я часто теряюсь в дебрях исследований, экспериментов и разработки. Слишком легко отвлечься на новые блестящие исследования и технологии или забыть, как это должно помочь клиенту. Возвращение к one-pager всегда возвращало меня на правильный путь.

Then, Budget The Time and Effort (Time-Box)

Затем — определите бюджет времени и усилий (Time-Box)

Most projects start with a solution, then come up with estimates for each component and the overall design. I never understood this—it’s like writing a blank cheque.

Большинство проектов начинаются с решения, затем приходят оценки по каждому компоненту и по общему дизайну. Я никогда этого не понимал — это всё равно что выписывать чек без указания суммы.

I tend to do the opposite. Given a budget (read: time-box), how can we design a solution that fits? The intent and desired outcome determine the time-box, and the time-box determines the solution design. This is how Basecamp does it too—they have different appetite for various problems, and scope the solutions accordingly.

Я склонен делать наоборот. Учитывая бюджет (читай: time-box), как нам спроектировать решение, которое в него уместится? Намерение и желаемый результат определяют time-box, а time-box определяет дизайн решения. Так же это делает и Basecamp — у них разный аппетит к различным задачам, и они соответствующим образом ограничивают объём решений.

More important and difficult problems should have bigger time-boxes. Between a $10 million problem and a $100 million one, the latter should get more resources and a bigger time-box. Smaller time-boxes can do with solutions with simpler techniques (e.g., regression, decision trees), freeing up effort for bigger problems that require more sophisticated solutions (e.g., deep learning).

Более важные и сложные задачи должны иметь больший time-box. Между задачей на 10 миллионов долларов и задачей на 100 миллионов вторая должна получить больше ресурсов и больший time-box. Меньшие time-box могут обойтись более простыми техниками (например, регрессией, деревьями решений), высвобождая усилия на более крупные задачи, требующие более сложных решений (например, deep learning).

The time-box will vary across the project stages. At the start, when we’re still exploring and uncertainty is high, we’ll want tighter time-boxes to limit wild goose chases. Once there’s more certainty of going into production, we can allocate bigger time-boxes.

Time-box будет меняться по стадиям проекта. В начале, когда мы ещё исследуем и неопределённость высока, нужны более жёсткие time-box, чтобы ограничить погоню за призраками. Когда появляется больше уверенности в выходе в production, можно выделять большие time-box.

“Work expands to fill the time available for completion.” - Parkinson’s Law

«Работа заполняет всё время, отведённое на её выполнение». — Закон Паркинсона

Usually, we start with a feasibility assessment. With our existing data and technology, are we able to solve the problem? If so, to what extent? In this stage, we aim for a quick and dirty investigation. I usually time-box this at 1-2 weeks.

Обычно мы начинаем с оценки осуществимости. Можем ли мы решить эту задачу с имеющимися данными и технологиями? Если да, то в какой мере? На этой стадии мы стремимся к быстрому и грязному исследованию. Я обычно отвожу на это 1–2 недели.

After determining feasibility, we proceed with a proof of concept (POC). In this stage, we hack together a prototype to assess if our solution is technically achievable. Ideally, we also test the integration points with upstream data providers and downstream consumers. Can we meet the technical constraints (e.g., latency, throughput)? Is model performance satisfactory? This usually takes a month or two.

После определения осуществимости мы переходим к proof of concept (POC). На этой стадии мы сколачиваем прототип, чтобы оценить, технически ли достижимо наше решение. В идеале мы также тестируем точки интеграции с поставщиками данных вверху и потребителями внизу. Можем ли мы соблюсти технические ограничения (например, latency, пропускную способность)? Удовлетворительна ли производительность модели? Это обычно занимает месяц-два.

If all goes well, we then develop for production. We’ll want to time-box this too. An overly generous timeline can lead to non-essential features being squeezed in and never-ending development—without actually deploying it, no one benefits from it. This usually takes 3-6 months, including infra, job orchestration, testing, monitoring, documentation, etc.

Если всё идёт хорошо, мы затем разрабатываем для production. На это тоже стоит установить time-box. Чрезмерно щедрая шкала времени может привести к тому, что в проект будут впихиваться второстепенные фичи, и разработка станет бесконечной — без фактического развёртывания никому от неё пользы. Это обычно занимает 3–6 месяцев, включая инфраструктуру, оркестрацию задач, тестирование, мониторинг, документацию и т.д.

(Note: I’m hesitant to put numbers for each stage above as it really depends on the project and organization. Nonetheless, having them gives a sense of the relative effort I would invest in each.)

(Примечание: я не решаюсь приводить конкретные цифры для каждой стадии выше, так как это действительно зависит от проекта и организации. Тем не менее, они дают представление об относительных усилиях, которые я бы вложил в каждую.)

Here’s how the stages could look like (from a previous post).

Вот как могут выглядеть эти стадии (из предыдущего поста).

We gradually increase time-boxes as certainty increases.

Мы постепенно увеличиваем time-box по мере роста уверенности.

Break it Down to Spot Rabbit Holes and Dead-Ends

Разбейте на части, чтобы выявить кроличьи норы и тупики

Having the one-pager and time-box improves a project’s chances of success. Usually, it’s sufficient. Nonetheless, it can be helpful to break it down, especially if it involves unfamiliar data or technology. The aim is to identify possible rabbit holes and dead-ends early and reduce time wasted on them.

Наличие one-pager и time-box повышает шансы проекта на успех. Обычно этого достаточно. Тем не менее бывает полезно разбить задачу на части, особенно если она связана с незнакомыми данными или технологиями. Цель — заранее выявить возможные кроличьи норы и тупики и сократить время, потраченное на них.

Working with a new data source? Check-in with a DBA to understand the data integrity and how often it refreshes. No point retraining your model intraday if the data source only updates at midnight. Considering a new technology for big data processing? Consult senior data engineers on the potential challenges and blockers.

Работаете с новым источником данных? Свяжитесь с DBA, чтобы понять целостность данных и частоту их обновления. Нет смысла переобучать модель в течение дня, если источник данных обновляется только в полночь. Рассматриваете новую технологию для обработки больших данных? Проконсультируйтесь с senior data engineer о потенциальных трудностях и блокерах.

“Foresight is not about predicting the future, it’s about minimizing surprise.” - Karl Schroeder

«Предвидение — это не предсказание будущего, это минимизация неожиданностей». — Karl Schroeder

Ideally, the breakdown indicates which components are harder to implement or more at risk—these usually involve things we’ve not done before. We want to front-load the risk and start with these scary bits first. If a key component cannot be implemented, we should know sooner rather than later, before investing and completing the rest of the project.

В идеале разбиение покажет, какие компоненты сложнее реализовать или более рискованные — обычно это то, чего мы раньше не делали. Мы хотим front-load риск и начать с этих страшных кусочков первыми. Если ключевой компонент нельзя реализовать, нам лучше узнать об этом раньше, чем позже — до того, как мы вложимся и завершим остальную часть проекта.

When breaking it down, I often consult seniors with more expertise and experience. They usually have better intuition on potential gotchas and blockers that deserve more attention. If you’re the most senior, it’s still good to have a fresh pair of eyes look through the breakdown and identify things you might have missed. Knowing where the rabbit holes are and how to avoid them has saved me significant time in the execution phase.

Разбивая задачу, я часто советуюсь с более опытными коллегами. Обычно у них лучше интуиция о потенциальных подводных камнях и блокерах, заслуживающих большего внимания. Если вы сами самый старший — всё равно полезно, чтобы свежие глаза посмотрели на разбиение и заметили то, что вы могли упустить. Знание о том, где находятся кроличьи норы и как их избежать, экономило мне значительное время на стадии исполнения.

It’s Additional Thinking But It Saves Effort

Это дополнительные размышления, но они экономят усилия

This may seem like unnecessary, additional work. But it doesn’t take a lot of time, and I would argue that it reduces the total work done.

Может показаться, что это лишняя дополнительная работа. Но она не отнимает много времени, и я бы поспорил, что она снижает общий объём работы.

Hammering out a one-pager usually takes 1-2 days, a week at most. In fact, the more time you spend on the one-pager, the more time you save. Requiring more time indicates the problem and ideal solution is still unclear—starting to build now leads to wasted effort.

Накидать one-pager обычно занимает 1–2 дня, максимум неделю. На самом деле, чем больше времени вы тратите на one-pager, тем больше времени вы экономите. Если требуется больше времени — это значит, что проблема и идеальное решение всё ещё неясны; начинать строить сейчас — значит тратить усилия впустую.

Similarly, proper time-boxing ensures we invest prudently on a solution based on the size of a problem. Spotting rabbit holes and dead-ends early helps us avoid them and reduces effort wastage.

Аналогично, правильный time-boxing гарантирует, что мы разумно инвестируем в решение в соответствии с масштабом задачи. Раннее выявление кроличьих нор и тупиков помогает нам их избежать и сокращает напрасные усилия.

Haste makes waste. I trust you’ll find that these habits save time and increase the likelihood of success. Let me know how it goes below.

Поспешишь — людей насмешишь. Думаю, вы увидите, что эти привычки экономят время и увеличивают вероятность успеха. Дайте знать, как пошло, в комментариях ниже.

Thanks to Yang Xinyi for reading drafts of this.

Спасибо Yang Xinyi за чтение черновиков.

If you found this useful, please cite this write-up as:

Если это оказалось полезным, пожалуйста, цитируйте эту заметку как:

Yan, Ziyou. (Jun 2020). What I Do Before a Data Science Project to Ensure Success. eugeneyan.com. https://eugeneyan.com/writing/what-i-do-before-a-data-science-project-to-ensure-success/.

Yan, Ziyou. (Jun 2020). What I Do Before a Data Science Project to Ensure Success. eugeneyan.com. https://eugeneyan.com/writing/what-i-do-before-a-data-science-project-to-ensure-success/.

or

или

@article{yan2020planning, title = {What I Do Before a Data Science Project to Ensure Success}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Jun}, url = {https://eugeneyan.com/writing/what-i-do-before-a-data-science-project-to-ensure-success/} }

@article{yan2020planning, title = {What I Do Before a Data Science Project to Ensure Success}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Jun}, url = {https://eugeneyan.com/writing/what-i-do-before-a-data-science-project-to-ensure-success/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

К 11 800+ читателей присоединяйтесь — получайте обновления о machine learning, RecSys, LLM и инженерии.