众所周知，在开发一款ios产品的时候，总是伴随着硝烟弥漫的“战争”，不仅仅存在于产品经理与程序猿之间，还有设计师于程序猿之间，甚至产品经理与设计师也会有些多多少少的摩擦。在这三角关系下，完全独善其身不了，那就得思考好如何自我做主了。但是，这关系如何处理好，好像纪晓岚，和珅以及皇上，抑或是小哥，吴邪还是王胖子，关系铁不铁，牢不牢靠，那就得各凭本事，处理得好，万事皆幸。
只是有一点是共通的，产品是大家的，需要大家一起努力去灌溉。所以，所有的出发点都应该出于产品的有利方向考虑，在此，我有一些建议无私地奉献给大家，供大家参考。
1. 遵循产品开发流程
所谓无规矩，不成方圆，国有国法，家有家规。产品从无到有，都要经历一系列过程：调研 －> 产品设计 －> UI设计 －> 开发 －> 测试 －> 验收。
调研主要是市场部人员的工作，了解用户的关注点以及用户习性，提供给产品经理下一阶段的产品走势。产品设计是产品经理针对市场人员的报告有效地制定下一阶段的设计内容，给到设计师做UI，再让开发同学，也就是所谓的程序猿进行coding，然后相关测试人员进行多方面测试，最后一个产品才算成行。
一个好的ios产品，对于产品开发流程的把控要规则化，明确化，透明化。而产品经理便是这之中的主导因素，特别是从产品设计开始，渗透进各个阶段，掌握所有的情况。整个产品的迭代更新，可以如下所示。
特别的是，程序猿开发的coding阶段，最好要做二次确认，由产品经理和UI设计师协作，对程序猿的开发内容有无不明确的东东，避免无沟通带来的成本。折损必然是存在的，产品经理要求的完美极致的体验，UI设计师的炫酷流动画面，到了程序猿手里，可能，你懂的。。。（这个待会会讲的。）其次，测试的时候，产品可能会进行公测，内测，这个阶段调研又可以开始进行，整个流程就又可以跑起来了。
还有一点，如果在某个过程中发现问题，想把某一件紧急的事情首先纳入提案，插入某个流程的一个节点上，一定要告诉项目经理或者产品经理，然后通知相关人员，重新调整流程布局，避免"殃及池鱼"。
总之，遵循产品开发流程，让每个人都各司所职，每个人都知道自己该干嘛，什么时候完成自己的项目，对于进度的保障也是对产品的负责。有的时候，产品不能按时上线，原因也就在这流程中的某个环节，是调研不够，还是产品设计有问题，或是开发人员时间不够，这个都能追溯到源头，调整好这个环节的各种因素，你的产品何愁没有用户。对于像我们这种创业公司，虽然说一开始会碰到一系列的问题，但整个开发流程能够跑通，那是极好的了。
2. 要有自己的产品定位
这可能是产品经理需要对于产品一个最主要的认识，重要的在于两个方面，人以及使用。一个好的ios产品的核心竞争力也就在于此，才能在同款产品中脱颖而出。
对于产品经理，要明确是谁来用这款产品，用户群体到底哪些人。不同的人群都有不同的喜好，他们为何要用你的产品？你的产品的优势在于哪？反向地思考好这两个问题， 必然能让你区分出你的产品的目的服务人群是哪些，为了不让他们成为流失用户，你要持续地提供相应的内容来吸引他们。而要积累自己应用的用户群体，必然要比较同款产品，这就涉及你的应用是如何使用的了。你会从使用者的方向去考虑你的产品的使用逻辑，然后来不断地提高用户体验，让用户累计增长。
不一定内容要很多，逻辑要很繁琐。要求就是以清晰，简洁的使用规则让整个应用显得卓尔不凡，这都得制胜于产品经理对于自己产品的精准判断力。了解自己产品的优势对于相应人群的服务点，即可。定位能让一款产品突出它的价值。
产品经理要明确处理好人与使用的关系。了解用户的使用习惯，让产品更能生彩。
3. iOS重在显示效果吗？
这句话可能存在很大争议。对于产品经理来说，尽善尽美，追求极致才是王道。很多的产品经理喜欢产品做到别人相似的效果，而且认为还需有所超越，这本身并无可厚非。但到了程序员手里，模仿变成了雷同，淡然处之，淡然处之。
其实模仿并不可耻，雷同也不尴尬，适合自己产品的才是最好的。并不是所有的ios应用都是酷极炫丽屌炸天，有很多界面平凡无实的应用一样可登大雅之堂，主要的在于内容，内容，内容，重要的事说三遍。应用的内容才是提升产品的有效体验，其他的都是浮云，你要提供给别人重要的使用价值，而不是华丽的画面感，这是才是正真的产品所要具备的东西，还有就是人性化的细节。除非在你提供内容过少的情况下，你才用画面感去提升产品的格调，但这也是侧敲旁击。
这里我要举例一个反面教材，看官请看是这样的：有的产品经理要产品有一个效果，但无奈程序员做不出来，他找来一个别人的例子，”为什么别人做出来了，你做不出来？“，还有一则是：“这很简单的，为什么做不出来。”求此时程序猿的心理阴影面积。
不是所有的效果都是有意义的。第一，从程序猿的角度，这可能对于程序的结构会是一种灾难，不利于维护。第二，这个效果对于整个产品可能没有多大意义，只是为了好看。当然，也可能程序员确实做不出来，或者就是开发成本大。
这就引申到下一个问题了。
4 合理？ 可行？
产品经理在做产品的时候，必须要问一下自己，是否这个合理，那个可行。这需要大胆假设，小心求证。
对于ios产品开发，我要说的是，所有的合理都需要遵循开发的一些潜在规则。产品经理是面向产品的设计原则，而程序猿是面向代码语言的开发，这两者本身并没有什么不妥。但是设计是天马行空的，可能会违背开发的一些原则，是设计太先行，还是程序的规则太古板？在设计落成现实，总需要一些过程。产品经理其实要有10%的技术知识，才知道自己的设计是否合理，这样也可以理解程序猿的开发难度。有些产品经理还不知道push和present的过场动画在使用上有何不同，使整个产品云吐雾里的各种莫名跳转。
在能够确认合理性的时候，让程序猿把控程序的可行性。需要的时候，可给予充分的调查时间，让他把设计代码化，这个过程其实也是对于程序猿的一种考验，也不是所有的设计真的做不出来，可能只差一个方法就能改变所有，这需要程序猿也要不断提升自己的能力以及开拓相应的技术领域。
验证合理性以及可行性，能让产品的逻辑更加顺通，或者界面设计的效果更优，每个产品都需要大家的共同沟通以及能力的提高下变得茁壮。
5. 不要轻易说”不”， 但有的时候就要“不”
一个团队的文化，决定了这个团队的发展。可能，你的团队协作和交流都不错，然后产品也就能孕育而生得更加滋润。但是，撕逼的时候也是要存在，没有反面言论的产品不是一个好的产品，起码在团队开发阶段需要这种撕逼。
比方说产品经理要程序猿开发一种很难的技术效果，作为程序猿的你该如何回应？是答应还是拒绝？这个时候，你要理性地对此经过判断以后才做出选择，而不要吐口而出“不行”或者“好的”。也许你的一句“不行”就否决了一个好的创意，或者一个“好的”让你花费无数心血还一劳无获，这种理性的判断需要你的技术支持。有的时候，在撕逼的时候，其实大家都是为了产品，要学会保持沉默，冷静思考，不要因为一时而伤了和气。
比如，程序猿会被产品经理麻烦多次，然后要改很多代码。这种时候，沟通需要好的方式，产品经理可以把要改的所有都整理好，确定好工作周期的时间点后，以邮件的形式提醒程序猿过目，免得打乱了程序猿当前的工作进度。
这说明，良好的沟通其实是解决问题一种比较好的方式。但是，该说不的时候还是要说，表达自己的观点其实是沟通的必备要素。
6. 有效的工作才是真正的工作
说实在，会议开的很长是一种浪费时间的表现，只是在团建。我觉得，会议可以很开放，但要严肃到一个点上。
把主要问题阐明是最大的重点。有时候，会议中会存在俩倆讨论的情况，貌似进入菜市场一样的感觉，这就需要一个好的主持人，引导大家能统一战线到主要问题上来各抒己见。而且，会议前要准备好所有相关事宜的问题点，以及解决方案，让大家都有效提问，理性回答，节省会议时间也是增加工作的时间，这一点，作为管理层，可能更需要注意。
同时，有些加班并不可取，不是所有的加班都是荣誉。可能在领导而言，加班说明你对公司做出了贡献。但其实，加班填充的是你自己的业余时间，你完全可以用它来做自己的事，更多的加班是由于你工作没完成，不得已才进行的操作。应该把有效的时间作为工作的首要考查点，管理好加班的时间作为提升自己其他能力的一个方向。如果你加班多了，又影响了第二天的工作，这是恶性循环。纵然会有不得已的加班，也请你管理好自己的时间。
提高效率，是关键，所以要提高自己的专注度，也是工作积极性的提升。同时，有效地管理时间，不仅仅局限于工作中，花费业余时间提高和学习也是很重要的。
7. 所谓的其他：处理好团队关系
在团队中，每个人都是不同的个体。每人都有自己的特性，每人都有自己的职责，对于团队关系需要一种维系的方式，要有属于团队的文化。
一个团队要处于摩擦碰撞中，产生火花，或者说灵感，让产品更体现大家努力的成果，这是一种凝聚，体现了一个团队的文化。大家在互勉的关系中互进，在互相的反馈中成长。
在一个团队中，总有苦与乐的阶段，珍惜这样一种状态，也不失为一种人生的体验。希望，让ios产品开发的同仁有所启发，有所感慨。
网友评论