对于数据产品经理而言，日常工作是聚焦于一个研究对象（一个产品/业务线/业务场景），通过生产、加工、应用数据去监控去运作情况，再通过数据分析方法暴露出长处和不足，从而反馈给研究对象，使其运作得更好。
那么一样的道理：对于一个人来说，他自身就是一个研究对象，他的工作生活，日常行为都是可以生产数据去记录追踪、整理分析，然后评价反馈的。
所以一个人想要自律，就得用数据化运营的方法来管理自己。
数据产品主要的工作流程如下图，此文将逐步讲解如何构建自己的数据产品，以实现对自己的数据化管理。
数据产品工作流
生产数据
要生产能够记录自己日常工作、生活情况的数据，得借助一款好用的时间、日程记录和管理工具。滴答清单是我在同类产品中用得最为舒适的，因为墙裂推荐。
容我先晒(zhuang)成(ge)就(xx)。
滴答清单成就
这款产品的优点有很多，不少文章都有详尽的分析。但我来说，它最能吸引我的点有以下之处：
-
科学全面的分类体系。清单体系、标签体系、时间体系、优先级体系，这些正交的划分体系基本能将日常大大小小的事情划分得很清晰，无论是记录，查找还是复盘，都十分高效，且一目了然
分类体系
-
系统、全面的日历视图，很方便进行每日记录和日程管理
日历视图
- 多平台同步，无论是网页端、win/mac的客户端、android/ios端，甚至是智能硬件，都能快速、准确同步，十分适合多场景、碎片化的记录和写作
- 简约、优美、无广告的UI设计风格
当然还有许多其他小的亮点，构成了这款产品尽管小众但用户忠诚度都比较高的特点。
如果你喜欢并习惯使用这个产品，并且深深地使用它对于日常事项的管理、记录和执行，那么它不仅仅是促进你自律的过程，还产生了自我管理的结果数据。
加工数据
有了数据之后，我们得采集到才能构建数据产品；何况自己生产的数据自己应当拥有，而不是只放在别人的服务器上。怎么采集，python爬虫啊！
稍微观测一下，就很容易发现，滴答清单上的数据都以json形式通过调API来获取；这样就十分容易去采集和解析。
json数据
怎么写爬虫代码，此文就不说了。值得一提的是，滴答清单还有一个优点就在于，它只需要登录一次，cookie寿命很长；这样我们的爬虫代码就只用一次登录过的cookie，都不用频繁换了，十分便于数据采集。
然后我们就是通过爬虫将自己源源不断产生的数据源源不断地取回来存储在自己的数据库里，这里我只爬取已完成的工作项；记录的表结构如下。
CREATE TABLE `dida_done_list` (
`id` BIGINT(20) NOT NULL AUTO_INCREMENT,
`title` VARCHAR(128) DEFAULT NULL,
`createdTime` VARCHAR(64) DEFAULT NULL,
`tags` VARCHAR(256) DEFAULT NULL,
`priority` TINYINT(4) DEFAULT NULL,
`task_status` TINYINT(4) DEFAULT NULL,
`completedTime` VARCHAR(64) DEFAULT NULL,
`content` LONGTEXT,
`scrapyed_time` VARCHAR(64) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `completedTime` (`completedTime` , `title`)
) ENGINE=INNODB AUTO_INCREMENT=31692 DEFAULT CHARSET=UTF8
分析数据
在有了全部的滴答清单历史数据之后，就可以很容易地查看自己在某个时间点做了什么事——当然我们做数据产品并不是为了缅怀过往，而是定期给自己复盘和总结。
所以从业务（自我管理）的角度来看，复盘时我主要关注以下几个问题：
- 这段时间的产出如何（任务完成量）
- 与过去比起来如何（跨时段对比）
- 哪些方面的产出较为突出，哪些不足（分标签对比）
- 这段时间所做事情的关键词有哪些（中文分词）
当然肯定还有更多的点可以挖掘，但你输入给数据产品的不能是过于主观、过于发散的问题，而是要具体、可量化、可复用、可程序化计算。
应用数据
对于数据分析师来说，业务周报是一项常见的工作。而我们的产品也可以采用周报的形式，只不过不是人来写，而是程序自动发。（数据分析师与数据产品经理的区别在于：数据分析师必须聚焦于具体的问题和场景，case by case去分析和输出建议；而数据产品经理则关注可复用的、扩展性和适用性强的、高效的场景和解决方案）
自动发邮件是一种常见的数据产品形式，也广泛应用于各公司的数据团队中。所以一个比较清晰的流程就是：
- 先爬虫并写入数据库
- 再从库里读取作数据分析，产生分析报告
- 最后把分析报告自动发送至邮箱
说起分析报告，就不得不提起数据可视化。很多业务人员觉得可视化只是一种形式，并不影响数据和业务的本质，所以没那么重要。我本来也是尊重这个观点的，可是在这个case中，也算是得到了一些教训。
因为我不会前端技术，也不会用Python作数据可视化（最主要的原因还是没啥动力学这些技术），所以最初发送至邮件的报告是很丑的，丑成这样：
一个很丑的报告-part1
一个很丑的报告-part2
没有画形，甚至表格都对不齐，这种报告可读性太差。因为可读性差，连我自己都逐渐懒得看；看都不看当然更不会去思考和总结。可是任务是我记录的，数据是我采集的，分析也是我做的，代码都是我自己写的，如果最后看都不看，那前面这些工作就没多大意义了。
于是转化一下思路：html是保持格式的一种良好的文件格式，也是python自动发邮件程序支持的形式，所以最好是能直接发html形式的邮件（就是把html当作正文，而不是附件）；自动发邮件程序里输入的是html源码，虽然不会写html，但是我们可以用更专业的写分析报告的工具r markdown去生成html文件，然后用python读取，传入发邮件的程序里，就可以直接发送html格式的邮件了！
写分析报告的rmarkdown程序
from send_email_html import *
import os
os.system("e: && cd E:\\R projects\\report_html_email && Rscript -e \"rmarkdown::render('E:/R projects/report_html_email/dida_weekly_report.Rmd',encoding='utf-8',output_dir='E:/Python-Projects/dida_lists')\"")
htmlf=open('dida_weekly_report.html','r',encoding="utf-8")
html=htmlf.read()
send_mail(html,'滴答清单从%s到%s的周报！'%(start_date,end_date),'滴答清单周报')
通过以上的代码，可以在python中调用shell语句，去运行rmd文件，生成html文件；然后读取html文件，将源码传入发邮件函数中，最后成功发送邮件。
最后再看看更新之后的邮件自动发送的周报效果！
优化后的报告-part1
优化后的报告-part2
优化后的报告-part3
优化后的报告-part4
优化后的报告-part5
优化后的报告-part6
现在效果好了很多了，就具备了阅读、分析、思考和总结的基础了！接下来只需要把爬虫、分析、发邮件代码整合在一起，然后上定时调度就行（linux上crontab，windows上schtasks），一般一周采集、分析、报告一次就行。
所以在这里，并没有借助多么高大上的软件产品，而是梳理、坚持一个清晰、简单、可执行、可复用的流程，并辅以少量的技术，就能构建一个属于自己，服务于自己日常工作生活，并有一定指导意义的数据产品了。
最后嘛，自律的人生是比较无趣且疲惫的，因为什么都要有预期规划，然后去努力执行；在这样的影响之下，相对地就会有些排斥变故、意外和风险。不过人生的大多数，本来就是无趣的；自律有助于自己更加明确、低方差地朝目标前进。然而，正如数据本身只能辅助乃至指导业务，它只是业务的反映，而不是业务的本质，业务发展得怎么样并不直接由数据决定。同样地，你是一个什么样的人（或是崇尚自由多变的，或是思维缜密执行力强的，或是对自己足够狠的，或是做什么都难以坚持的），也不由一个产品或一套流程决定的，得由你自己去认清并引导好自己的本质。
网友评论