韩军星的博客 » 流程

结婚领证的流程

hanjunxing — Sat, 21 May 2011 08:51:51 +0000

上上个月也就是3月22日结婚时，发了篇最重要的决定—我们结婚了！，最后提到会补上结婚领证详细流程攻略，谁知道这一忙2个多月又过去了，断断续续在写，今天交下作业。

想知道领结婚证详细步骤的同学，都是没结过婚的吧？所以我尽可能介绍详细些。

1.结婚领证前的准备

首先，当然是了解怎么结婚领证！这非常重要，找个有经验的朋友聊聊，或者查阅网上资料，都是很好的学习方式。如果你父母不是民政局的，还是不要学习二三十年前的结婚经验了。

向有经验的朋友取经是最好的方式，大多数人都很乐于分享自己人生中最重要的事情。如果网上查阅资料的话，很有可能被误导，因为信息本身是有时效性的，虽然婚姻法10年前修正过就一直很稳定，但各地民政部门会在大框框下有很多本地化的规定，所以找个近期结婚的朋友了解下情况是非常明智的选择。

当然，网上查结婚领证攻略一类的文章是最方便快捷的，类似的综合性网站也有很多，不过很多广告搀杂其中，需要筛选过滤，也很费劲。网友的博客通常比较靠谱，唯一的问题是很多朋友结婚后沉浸在喜悦当中，忽略了分享。本文当然是纯公益性的，如果你觉得有帮助，欢迎转发推荐，让更多有需要的朋友了解目前领结婚证的步骤和流程。

2.领结婚证的详细流程

做了个简单的流程图，每一步我会细说：

2.1.准备领证必备材料

a.结婚双方的户口本，共2本；

b.结婚双方的身份证，共2张；

c.双方的户口本复印件，共2份（本人页要与户主复印在一张纸上）；

d.双方的身份证复印件，共2张（正反面）；

e.结婚双方的双人大2寸彩色照片，共3张；

f.女方的单人1寸彩色免冠照片，共1张；（计划生育险建卡准备）

j.钱若干（9元领证可能是传说，各地可能出现不同杂费）

以上资料为办理结婚登记手续时所必须的，需要强调一下，所有资料最好在去办理手续前全部准备好，特别是“双人照”，找个老字号的照相馆，花个百八十元好好照一下结婚证照片，现场照相的同学99%会遗憾终生。

婚姻状况证明以及婚检报告神马的，是若干年前的事情了，现在不需要哪些东西。

还有两点需要强调的：

h.选个黄道吉日吧！实在不好选的，选个名人结婚的日子即可。比如我选的大S结婚同一天；

g.出发前打电话跟户口所在地民政部门确认好时间（是否办公），地点（是否是你搜的地址），所需材料（各地可能会稍有区别）。最后的确认，让你心里有谱，把一切不稳定因素消灭在摇篮里。

2.2.去户口所在地民政部门

咆哮体一下：一定要早点去啊！黄道吉日很多人啊！！民政部门是很忙的啊！！！一天就放120个号的啊！！！！偷懒的人结不了婚的啊！！！！！准备好结婚没结成的人你伤不起啊你伤不起！！！！！！

如果双方户口不一样，选择对以后发展最有利，相对也最方便的一方办证。这一点下面会说原因。另外，有些地方的民政局可能不叫“民政局”，比如我去天津办证，办理结婚登记手续的地方叫做“天津市河东区行政许可服务中心”，google地图查的那个民政局已经不再办公了，所以一定要打电话问清楚地址。

2.3.办理结婚登记手续

a.领号排队；

b.审核条件及资料；

c.缴费；

d.验血

e.领证；

每个节点，都有工作人员具体告知，不同地区可能会出现细节的不一致，也有一些需要注意的地方。

比如排队领号，我们10点到，领到了110号，工作人员说下午3点再来，我们等不及了，2点就来了，照样可以上去办理。审核资料时，一旦上面提到的资料出现了缺失，需要再办理会比较耽误时间，因为每个办理点都在排队。另外，缴费的单子要看清楚，除了9元国家规定的结婚证件照会给票以外，其他的收费都是无发票无收据的（唯一的一个收费单，领证时也被要过去了。我一共交了七十多，照了个单人照、印了几张复印件、还抽了血，还有些婚育培训资料）。

需要注意的是，有些收费项目个人觉得真没什么必要。比如有个结婚现场纪念照的环节，工作人员直接叫我们去，进去后直接问照那种（一种40多，一种70多），我问“能不拍不？”，那大姐愣了一下说“可以”，于是我们就出去了。当然，不排除有人喜欢照这个的，但我猜80%都是进去叫照就照了，因为很少有人分得清楚，那些是结婚领证的必须流程，那些是增值服务。

验血这事情，让我很纠结。因为至今我还不知道这个验血是干嘛的。当时工作人员说是现在取消了婚检，政府为年轻人负责，免费对结婚登记的新人进行血液检查，一旦有问题会打电话通知。回来专门研究了一下，这个主要是验血液病和血液叶酸含量。虽然可以不验（看网上有吵架拒绝的案例），但工作人员会反复强调验血的重要性。还是那句话，大喜的日子，没几个想跟自己心情过不去的，所以这事儿也就算了。对政府部门来说，做到公开透明，一向是很艰难的事情。

验血出来，一手压着，一手领证。跟我们一起的朋友已经等的快睡着了。有朋友帮忙看包，的确省下了不少麻烦。至此，结婚领证流程已经顺利搞定了。

3.后续事宜

关于领证时给的一堆表，至今我仍处于混沌状态。以前觉得，结婚就是你情我愿，领证完事儿，没想到还有什么这个检查那么检查，还要有个计划生育指标，有孩子时还要弄个准生证之类的。在中国结婚生孩子真TMD是个很蛋痛的事情。还有户口问题，孩子上学问题……不想了，太累。好好工作，快乐生活，比什么都重要。对我们来说，这只是一个开始。婚纱照和酒席还没搞，搞了的时候有经验再分享吧。

继续浏览相关文章

软件/互联网产品设计流程

hanjunxing — Mon, 18 Jan 2010 09:29:31 +0000

近期站在产品部门的视角整理了公司产品设计流程，一来完成任务，二来对自己一年多项目管理和产品开发经验进行下梳理：

1.产品调研

产品的调研属于市场范畴，由市场部门负责。产品调研是为了提高产品决策质量，解决存在于产品设计及产品上线后销售中的问题而系统、客观的收集、分析市场综合情况的行为。所以与内部产品不同的是，外部产品调研需要撰写市场需求文档即MRD，只有符合公司战略和市场需求的产品，方可进入产品立项阶段。而内部产品调研由于不涉及市场环境，为了产品设计流程的敏捷和高效，不需要提交调研产出物。经过确认必要且可行的产品，可直接进入产品立项阶段。

2.产品立项与评审

产品立项是产品设计项目流程的起点，产出物主要为《产品立项说明书》。产品经理负责产品立项时的文档撰写以及项目时间和人力计划安排。产品立项后，直接进入立项评审流程。立项评审是对产品立项说明书和项目计划的综合评审。立项评审各节点的负责人需要填写《产品立项评审表》，评审通过时评审自动流入下一节点直至归档。立项评审通过后直接进入产品详细需求及设计阶段。

3.产品需求与DEMO设计

产品需求是项目流程的重要组成部分。主要由产品经理负责，对内部业务需求进行详细的调研分析。根据需求，产品经理需要设计业务流程以及构建产品框架，使产品能够满足业务方需求；同时与技术部门协同确保产品方案能够顺利实现。当产品需求明确后，需要设计产品线框图即DEMO展示，确保良好的可用性和用户体验。详细交互情况需要在产品需求说明书中注明。本阶段主要产出物为《产品需求说明书》，以及产品DEMO。应用工具主要为Visio、Axure等。当需求阶段结束后，进入需求评审流程。另外，需求变更一般是在设计阶段，用户的需求发生变化时进行的，当需求评审结束后进入开发阶段时的需求变更应该尽力避免。

4.需求评审

需求评审需要业务需求、产品、技术共同参与，由该项目产品经理对产品的需求说明书以及DEMO做详细汇报，并解答各方面疑问。参与的评审人员需要填写《产品需求评审表》，评审通过后项目自动流入UI设计流程。需求评审的结束是项目的里程碑。

5.UI设计与美术评审

UI设计主要是针对产品表现层的设计，包括框架、元素、界面、文字等等的标准化设计。与DEMO的线框图不同，经过UI设计后，经过确认产出物产品原型需要直接作为前端开发的标准。因此UI设计结束后，需要进行美术评审，征求公司领导和相关产品负责人对产品原型直观印象，直到最终原型确定进入前端开发流程。部分内部产品不涉及UI设计的，可直接进入技术开发。

6.技术开发及前端开发

通常情况下，技术开发在需求评审结束后即可开始介入。即根据产品需求文档和DEMO原型，开始架构产品底层，由架构师负责。随后展开源码撰写的技术段工作，主要由技术部门负责。当产品UI标准及美术交互原型完成后，根据底层开发情况，可以开展产品前端开发。部分网站产品如板块变更，不涉及底层开发部分的，可直接进行前端开发。

7.测试及上线

当开发完成时，由测试部门（测试部门在需求阶段即可参与项目）撰写用例并测试。新产品需要首先发布到测试平台使用测试，网站产品进行大范围改变时，需要上线测试版经过客户熟悉和认可后方可正式上线。

8.产品跟踪

产品上线结项后，产品经理开始对产品持续关注和跟踪。了解业务使用情况，同时针对产品使用过程中出现的问题进行修复；当业务需求变化时，及时对产品进行升级或进行二次开发。产品经理需要在产品的生命周期中持续跟进产品。

继续浏览相关文章

需求变更-要效率还是要规矩？

hanjunxing — Fri, 16 Jan 2009 15:02:29 +0000

需求变更在项目管理中是经常遇到的问题，特别是当项目进展到尾声时，一个需求变更对成本产生的影相往往比项目初期成几何级放大。虽然我们在需求阶段细致入微，在开发阶段滴水不漏，在流程管理上规规矩矩，但无奈的是，我们的客户总是希望拿到更完美的产品。于是乎，变更就成了结项后的潮水，一波一波，无休无止。不是你的产品坏，是这个世道变化快……

如何对需求变更做科学的规划和控制？在做好需求变更管理的前提下，分级管理客户需求不失为一种很好的方法。但是如果客户的需求变确实需要在将要结项得产品中尽快体现时，应该如何处理呢？特别是一些在需求中非常重要，但从技术上很好实现的需求变更时，是否还要走正规的需求变更流程？要效率还是要规矩，就成了许多产品经理心头的疑问。

首先，需要确定：是否真的需要走需求变更流程？灵活点说，需求是变了，但走不走这个流程是另一码事。如果项目几乎结项了，这时的需求变更就像百米赛跑后，裁判说这个跑道不标准，少跑了一米要重新跑一样；一鼓作气后，项目团队都疲惫不堪时，再次击鼓的效果可想而知。其实针对这时需求的变化，特别是技术上很好处理的问题，直接在结项后作为升级内容即可；毕竟版本得改动可小可大，小的版本变更从流程上讲要比需求变更简单的多；

其次，还有一个偏方，是我最近经历的项目变更得解决方案，即将这个需求分解放在其他相关项目中完成。在项目日程已经排满，并且项目间有一定相关性时，这不失为一种好办法。如果项目是迭代设计的，那么采用这种办法再合适不过了；

最后，当非变更不可时，如果没有针对不同变更得不同流程得话，唯一要做得就是做好前后沟通了。在有正规流程时，走正规流程是必须的，也只有这样，项目才能真正可以控制。如果对流程不满，除非能够很快吧流程修改或完善了，否则一步一步做吧。所谓得追求效率而抛弃规矩，是对项目不负责任的原则性问题。

需求变更就像误差，可以控制，但又无可避免；但是因为前期工作没有到位而引起了需求变更，就太不应该了，错误是不应该出现的。出现需求变更时，先不忙着救火，而是冷静下来先考虑问题产生得原因，比做救火员要有意义的多。后面会详细讨论这个问题。