Skip to content

fami2u/ipp

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

11 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

独立项目计划

2016/11/9

在许多的项目参与过程中,我们会是使用各种开发流程去管理,包括瀑布流式、敏捷式、螺旋式等等,有时会进行一些改良来适应不同的项目。总体上,虽然我们采用了最快的开发语言并且研发了很多进一步提高效率的工具同时为项目配备最顶级的开发者,但这些并没有真正帮到项目参与者。项目方(大多数是创业者)并没有因为新技术的引入和更强的人才参与而降低项目的周期、风险,产品的质量却没有提升。

我们与项目的关系如果只是雇佣和工作的关系,这一点可能永远也解决不了。因为中间缺少一个环节:对于项目的描述。我们也试图在项目前增加产品和设计的工作比重,这种情况下项目的成本回升到了非常高的水平,早期的创业者无法负担的起这个费用。也违背了独立开发者最基本设想:足够的个人能力获取足够的回报。

回想项目启动最早期的时候(大概是两年半以前),我们与大多数创业者接触的时候,提出过一个叫做“原型生态”的理论。大致的概念每个项目的设计都是为其所依附的一个原型建立,专注于各自的职能,形成小范围的系统。通过这个系统的进一步成长扩张,提告竞争能力和生存能力并最终融入更大的系统中占据一部分。这个原型就是几千万开发者群体,所以在早期我们通过技术投资的形式参与了很多健康医疗资源、开发者文化、消费升级、生活服务类与开发者群体有联系的项目。

这些项目合作达成也多数是基于此。然而再后来的项目,过于重视技术本身的问题,结果远没有达到像前期一样的发展速度和效果。归根结底,对于技术生产能力的提高并没有解决任何问题并且拉长了可能出现问题的时间阶段。变成了一种自助式的开发体验,这对于创业者和开发者都是严重的伤害。说实话,在这一段时期我们的独立开发者们过得非常痛苦,项目方有时也是充满了愤怒。

最近,我们观察了非常多的其它项目尤其是企业服务类对比了其中一些状况不是很好与优秀的。真正解决问题的企业会做大做好,纯粹靠推广营销都是暂时的。创意,创意的人和引导人释放创意的规则是这些企业核心竞争力,尤其是后者,有这样的规则存在才有自由发挥的空间,优秀的人才会聚集。

“在这个时代总能找到更高性价比的生产力方式”,我们在反思“独立开发者”这命题。首先要认清自己才能再说方向。之前,一直在对外宣传“独立开发者”是“非常强”的开发者,那么怎么解释“非常强”?其实是项目经验与编码能力在这两方面的能力。需要将它们分开对待,“独立开发者”最重要的就是丰富的项目经验,也是最有价值的。

这种项目经验是否能和创意划等号?答案不确定,依人而易。这是价值体现的不确定或可以说对不同水平开发者的分级和认证、晋升机制。在一定程度上也可以说,经验和创意是类似的:知道哪些做法是不对的,知道怎样去开始一件事情,过程是怎样的(来源于曾经经历过的项目),另一方面开发者最强的能力是抽象,在项目真正去编写时必须对要写的项目建立大概的概念模型,这也算是一种长期训练,所以在项目整体设计摆在面前时,一定能够分辨出哪些是核心功能,在什么阶段处理它,其它模块如何与它对接等等。

之前也曾说过,建立“独立开发者”这个项目时伴生的“原型生态”理论,这个想法目前看来不成体系或很早期,但是我们在实验各种开发流程管理时发现了另外一种解决方式:快速原型模型。


快速原型模型

快速原型模型需要迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。 快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义,快速设计开发出软件系统的原型,该原型向用户展示待开发软件的全部或部分功能和性能;用户对该原型进行测试评定,给出具体改进意见以丰富细化软件需求;开发人员据此对软件进行修改完善,直至用户满意认可之后,进行软件的完整实现及测试、维护。


经过几个项目的实际操作来看,这种模式的应用有两个非常难的点:原型建立的周期需要尽量快投入市场进行验证;对于开发人员整体素质的要求非常高。拿到测试项目数据时,我们简直泪牛满面。一方面原来并不是我们想出了什么新东西,另一方面原来已经有非常成熟的理论支撑。而之前一直的研究方向也并没有浪费。

相比于其他的几种开发模型,“原型”这种模式很大的一点不同就是需要研发人员参与到产品设计流程,参与的能力可以是帮助项目整理出原型或叫做“核心业务”,也可以是更深度为创业者提出意见。

FAMI在建立这个体系的过程中,获得很多人的帮助,尤其是那些从事开发者这个职业并且想为这个职业做些事情的朋友。来自于 METEOR 社区的 @romejiang 在早些时候也参与到项目中来,并以独立开发者的身份进行不少项目。在这之前,@romejiang 也有非常多的项目经验和成功案例,提出了 “MVP” 的概念,对于“独立开发者”体系提供了很重要的补充。


MVP (最简化可实行产品)

MVP是一种产品理论,这个概念听起来复杂,不过你可以把它想像成是一部电影的剧情大纲,或是一部漫画的角色介绍。

Minimum Viable Product –最简化可实行产品。

MVP是一种产品理论,这个概念听起来复杂,不过你可以把它想像成是一部电影的剧情大纲,或是一部漫画的角色介绍。它的重点就是制作的成本要极低,但是却能展示最终产品的主要特色。

MVP 的功用就是让你拿来接触客户,从很早就根据客户的回馈来改进你的产品。典型的错误就是窝在家里做没人要的产品 ,却自以为很有进度。大家的经验是,使用者要的东西往往是非常容易做的,但是也是最容易被你忽略的,如果你不一开始就跟用户接触,就很难知道这些内幕。


现在,所有的项目都在贯彻这些理念,已经收到了不错反馈。下一步,我们将基于目前上百个项目的真实数据建立数据模型,为项目提供辅助决策能力和数据指标,为那些真正好的想法提供早期的ITVC服务并对接投资机构。另一方面,也在建立机制使这些从项目获取来的利益可以与为他们贡献智慧的独立开发者们共享。

当然,解决技术与商业链接的方式会有很多种,我们仅是在其中一种方法上进行深入挖掘。希望能让与我们类似经历的开发者能有更好的价值实现, 真正帮助那些真正有梦想创业者和有社会责任的企业,如果对“独立开发者”项目有兴趣可以联系我们。

2016/11/4

IPP本身也是一个项目,同样遵循原型原则。首先的计划是搭建基础的架构。

语言&框架:METEOR

项目方向:适合独立开发者这件事情的流程管理等功能

开发规范:参考 @romejiang 提供的METEOR最佳实践文档,也是目前FAMI主要采用的开发方式。

http://forums.fami2u.com/t/meteor/39

================================ 最初的目的是建立一种商业组织的形式聚集起一批有能力的开发者,链接起企业和开发者,推动开发者的价值实现:商业价值和社会价值。

独立开发者的项目大概已经进行了2年多了,期间尝试了很多种方式去转化开发者能力,基本上算是一步一个坑...

目前,经过最近几个项目的实际合作渐渐有了一些雏行。希望能有更多人参与到这个项目,FAMI是属于所有开发者,服务所有开发者的一个平台。

项目原则上以实际的业务需求为出发点遵循原型模式,进行最小产品实践后再进行相关功能的迭代。任何提交也会经过项目方、开发者和平台的实际验证。

曾经或现在为这个项目努力的开发者:@qintengfei/@romejiang/@lzl/@devphc/@fanjingyuan/@lirubing

有兴趣的朋友可以与我联系:sunhannan@fami2u.com

非常需要大家来帮我们出谋划策。

暂时会在这里做一些总结工作,把之前实施独立开发者计划的经验分享给大家。

FAMI其他的一些项目也都是以提高能力和效率为主:

AICS 辅助服用代码的项目 现在由 @qintengfei 在负责 https://github.com/fami2u/aics

METEORUP meteor的自动化部署服务项目 现在由 @romejiang 在负责 https://github.com/meteorup/meteorup

FAMI是比较松散架构的一个组织,欢迎大家提供一些小工具来帮助所有独立开发者提高他们的效率。

About

Independent Project Plan

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published