杂谈一下，我不是搞产品的也不是搞技术的，只是一个打杂的。随便扯谈一下。
作为一个产品，既然有这个名称，必定有其定位。在构思之前，就必须有明确的针对人群。比如是针对年轻人（80、90），抑或者上班族等等。模糊与笼统的定位，带来的只是无谓的“探索”。定位不是靠摸索出来的，也不是磨打出来的，是在你的脑海里，在你的产品里。即使现在模仿风气如此浓厚的时候，需要的也是定位。你的定位在哪儿，注定成就怎样的结果。
有了想法，下面就是一些调查和思考。你的这些针对人群在你的产品你会喜欢什么，会怎样的习惯？这个时候需要做的就是多和你的目标与非目标受众多去聊天，多去发觉他们的喜好与需求。或许你的改动只在某时一句话。所谓的走出去，这一步是必须的。闭门造车，最后可能出来就是一个自个儿意淫的杯具。
初期的实现与原型。很多时候喜欢在白板或者纸上写点什么，画点什么。记住！这一些都不能丢弃，或者擦掉。或许只是一些顺手涂鸦，或者解乏的简笔画。原型设计不需要一个完整的流程图，应该突出其顺序和关键点，以及部分UI的展示。这个过程中可以适当让受众面参与进来，设计出非自己主观的思路。
好吧，其实这些过程是可以修改和整合的。毕竟咱写的是互联网应用，不会给你完整的需求文档，完整的流程图，那样还叫互联网么？那是外包（无贬义，含笑）。
到现在为止应该糅合一些技术的关键字，比如哪些可以做到，哪些比较复杂。哪些技术可取，哪些可以折中。在考虑这个阶段的时候，技术人员需要的更多的是倾听，而不是纠结在某个环节，或者抵制某些习惯与思路。你可以说下自己的观点与想法，但是记住这些只是你自己的主观出发点，代表不了什么（如果正好受众面就是你，那恭喜了！）。需要做的就是记录下需求，转为脑海中虚拟的实现与流淌。一切心中有谱之后，可以适当“讨价还价”。毕竟每个人说出的都是自己的想法。
该画出流程图了。和上面原型一样，记住，别随意擦掉。用小人也可以，用箭头也可以，或者圆圈。你描述的只是过程，不是漫画和小说。当然加上这些元素会显得你的设计更加有爱。流程图的初衷在于走通整个流程，以及画出关键点。大致抽象出各个模型、结构和交互情况。适当写些文档把，这个总没有坏处的。或许这就是设计文档的初稿。
选型。有了需求，有了流程。下面当然是选择怎么去实现。说到用什么，仁者见仁，智者见智。啥好？啥不好？不是道听途说。关键在于自己。这些年来，喜欢的一句话就是：用自己熟悉的、用自己顺手的。看看外面的世界，好东西太多了，难不成有兴趣什么都来用一下？清醒吧哥们。你不是科学家，不是搞研究的。有这个时间，完全可以把你自己熟悉的搞的更透彻。这里并不是抵制新的或者好的工具，要明白一点，这些工具的作用域在哪儿，如果对自己实在可能起不到啥作用，或者只是存在你的假想中，放放把。未来再尝试也不迟。
关键点的实现与雏形。套句时髦的话，这个是不是应该算架构和设计？抽象出大致的模块，划分出结构。不必太在意其完整性和准确性，只要能走通就好。一次都给你写完了，其他人都去喝茶看报纸？雏形嘛，你懂得。当然，还得明确具体的工具，比如语言、数据库、系统等等。一个准则：用自己熟悉的，外加一条：简单就好。
是不是有了大体的架子了？可能下面就是大工作量的体力活啦。当然，分配体力活也是一个很体力的事情。没有一个好的管理者，这个产品就是大家拆东墙补西墙，互相推诿的产物。大致的职责有：传承需求和变化，分配与监察。消化和理解需求，确实是个跟天赋有关的事情，如果都是一个顺序跑下来的，那也不叫互联网了。需要很好的沟通能力，纸面或者口头的描述，随时可能千变万化，一成不变，继续去做外包把（囧）。分配这个环节就跟经验有关了，多去发觉你团队中的兴趣与擅长，用其长处，适当补短。合适的人干合适的事情，嘛效率？这就出来了。大家都在干活，进度就需要自己不断的监控与调整，适当多给自己宽裕的时间，哪怕只是那么一两小时。凡事没绝对，多想，多看，总是对的。
实现。设计数据库，写类库，写页面。详细罗列的话估计一长串。然后就是拆分逻辑，拆分页面，拆分功能点，然后就是与之对应的整合和补充。说到这边，可能就有人会说，用某某类库，或者某某框架，某某工具。这一切都建立在对其了解的基础上。不要太迷信，同样的刀在不同人手上是不一样的，用的好才是好刀，用不好连茅草都不如。折腾的滋味自己尝把。不是用了啥就牛逼，而是解决了啥，针对性的解决才是牛逼的关键。所有的一切，都只不过是实现的一种手段。条条大路，都可以。不要太迷信××，那只是一个传说。没有万能的实现，只有不断的解决与重新审视。实现细节滤过。。。
测试。不是写几个TestCase就是测试，那个只是证明你的代码看起来没啥问题，当然也不仅仅是用了啥测试框架，多专业。都只是辅助工具。除去功能性的测试，需要的是注意细节上。如果仅仅只是能用，没错没bug。这个不是产品，或许就是留言版。当然应该提供更多的可用性、流畅性以及体验。
唉，一不小心快十二点了，洗洗睡吧。未完再补充。
