艾伟也谈项目管理,创业公司技术选型参考

  java推荐框架
  web项目来说,spring、struts是必选,当然有更加好用的,推荐来自疱丁分词作者王志亮在人人网的rose框架,使用上手快,配置少,是创业公司java必备。

  php框架推荐
  zend framework,或者直接写个简单的框架,php的框架更加倾向去规范代码,让所有项目在新人加入时快速上手。

  代码版本控制
  subversion是必选工具,简单易学,git也开始流行,也是可选方案。

  jar包依赖管理
  这是针对java项目,还在使用ant的朋友,可以考虑换换了,特别的,如果你的公司在很快扩张的时候,这个选择能让未来避开依赖混乱,遇事集体更新困难的困境。

  公共代码建立
  长期可遇见的公共部分,比如用户信息获取,memcache管理,毋庸置疑地需要提供公共的方法,越早越好。

  代码可扩展
  这就考量上面选择框架的气候是不是合理了,这里可扩展是指,在负载越来越大的时候,要能很轻易配置读写分离,rose在这方面做得很优雅,只需要简单配置就梦把看的代码用上新的数据源。

  code review
  有许多好用的系统,比如Review Board等,让参与者都知道修改,并且在最早期发现问题。

  bug系统
  jira、Bugfree等等,用系统控制流程。

  培训体系
  技术需要交流才会有进步,团体的进步才是真的进步。所以尽早建立起内部的培训体系非常有必要,同时也是活跃团体气氛的很好方法,其频度控制在两周一次最好。

  项目管理
  从项目初期的demo设计>产品设计>技术架构>技术方案>技术实施>测试>理程碑>上线,每一环都需要详细控制,实施Scrum或者是Scrum变体,都是不错的方案。任由团队想到哪里做到哪里的结果是无法预估商业产品的出炉。

时间: 2024-08-01 04:30:06

艾伟也谈项目管理,创业公司技术选型参考的相关文章

艾伟也谈项目管理,技术管理中常见的几个问题

前几天跟朋友聊天时,朋友说他刚刚从一家知名软件公司面试出来,朋友去面试的是一家公司的技术管理岗位,所以在面试的时候被问及的问题也偏重于技术管理方面的问题,在与朋友的聊天中将这几个问题归纳了一下,大致归为如下几个问题. 在日常工作中你是如何行使管理职能的 这个问题以我的经验以及参考常见的一些开发方法,在实际中我都是早询问及晚反馈的方法.也就是早上上班后的半个小时内主动询问开发人员是否有不能及时解决的问题,如果有,组内组员讨论解决方法:下班的时候,组员可以以邮件或者其它方式汇报自己的进度,并评估当前

艾伟也谈项目管理,技术领导的疑难:如何掌控其他成员的开发

如何将项目的开发掌控好是技术领导(Team Leader)必须做好的.何为掌控项目的开发,即开发的进度和质量在计划内,不在期限快到时慌手慌脚,也不需交期到时天天加班,更不能删减测试时间.总而言之,就是开发工作有节奏,按部就班到达预期目标. 理想总是好的,可现实总是残酷的.你有过每个周六都加班,每晚都加班的经历没?你有项目完不成,接二连三申请延期发布的经历没?你有过遇见过你委以重任,但他却误了你事的同僚没?如果你工作了一段时间,又恰好又有带过小队伍的经历.我想你应该也遇到过这些问题中的一个或几个吧

艾伟也谈项目管理,产品版本改造中的项目管理

近段时间,一直在负责一个产品版本改造(C/S系统进行B/S改造)的研发项目管理,在任务紧.时间短.团队成员又没有相关技术(Silverlight)背景的恶劣情况下,我带领包含我在内只有6个人员(5个研发人员,1个产品经理,产品经理在系统版本改造中主要精力投入到辅助市场部进行产品推广去了)的超小型项目团队,终于在公司给定的时间范围内完成了整个产品的版本改造.这其中经历了需求变更.技术风险.人员变动等诸多问题,项目任然取得了成功,这种使用新技术的试验项目能够取得成功不得不说有几分侥幸,更多的还是团队

艾伟也谈项目管理,软件架构师之职责范围

由于国内外软件土壤差别巨大,适合国外的一些理论在国内不一定行的通,而国内的一些资料往往都是根据国外的资料直接搬过来用的,这也直接导致国外的软件架构师在国内变得水土不服.今天本篇随笔的内容则是在一些培训资料的基础上,加上自己的思考,总结出来的适合国情的软件架构师职责范围. 1,需求整理分析 有人认为架构师是在需求规格说明书完成后介入的,但我认为架构师要从项目最开始的阶段就参与进来.理由有很多:首先,第一手的信息损失最少,架构师能够更好的把握需求:其次,分析人员在与客户交流时,往往不会深入挖掘需求,

艾伟也谈项目管理,打造高效的技术团队,我会关注的7个点

1:使用分布式的版本管理系统 如果你觉得不需要使用版本管理系统,那我们沟通会有代沟,如果你是cvs.svn的粉丝,或者由于某种原因没有使用过分布式版本管理系统,比如git,那强烈建议你去看一下"why git is better than x". 2:一键式发布 这里发布的目标位置,既可以是开发机,做本地测试:也可以是测试机,为QA准备好捉虫游戏的森林:还可以是生产环境(或者beta环境),供用户直接访问. 如深度xp一键恢复系统一样,一键式发布需要自动完成很多工作:代码自动化测试(开

艾伟也谈项目管理,克服在企业中应用敏捷方法的技术挑战

在企业中应用敏捷方法是一项具有挑战性的任务.实现敏捷不像安装软件那样能在一天内完成.而是需要适应企业环境,其中包括:文化.技术和组织方面.本文将探讨面临的一些挑战,这些挑战与建立开发环境.自动化测试.持续集成相关,并且同在企业环境中明确完成的定义(DoD)相关. 建立开发环境 每位技术负责人和开发经理都想缩减团队成员建立开发环境的时间.然而,为了在项目中获得较高的产出,开发人员要持续投入许多精力,让事情变得有条不紊.缺乏文档,是建立开发环境时间过长的关键原因.第二个关键原因是建立过程中包含多少手

艾伟也谈项目管理,项目经理要如何看待技术?

当上项目经理后,技术人员往往对自己的定位失去了感觉.其中最令人困惑的就是自身原有的技术标签,撕了也不是,因为技术还不能丢,贴着也不是,因为个人的成败往往决定于自己对团队的管理,而不再是自己的技术. 想要从这种困惑中摆脱出来,首先就要搞清楚下面几个问题: Question 1--项目经理职位对技术到底有什么要求? Answer: 想把项目管理工作做到点子上,两个观点要明确: ①技术不是必须项.项目经理个人技术很重要,但这不属于必须项,属于有了更好的东西,当然越高越好.因此,在工作中,固然出任项目经

艾伟也谈项目管理,产品不要被技术绑架的十大注意事项

"不可能的:有难度的:你懂不懂技术的:这个功能要放在二期才能做:要做可以但需要时间:把那个项目停掉我就给你做--",如果经常听到技术这样说,那你的产品很有可能已经被技术绑架了,接下来你想再多的功能,只要技术说不可以那就没戏. 1.正确选人 --做网站的技术开发,必须是个技术牛人,要像科学怪人那样的人最好,为实现一个功能可以两天不睡觉的主.千万不要找一个所谓的高级架构师之类的高人,其实这种人连最简单的功能也不会开发了. 2.严禁不可能 --如果一个程序员说"不可能的"

艾伟也谈项目管理,和谐共进的项目组——产品经理提高技术理解力123

最近被同事问到产品经理怎样提高技术理解力,有哪些途径,这里结合之前做过的两个项目以及和这个项目组所有开发兄弟一起并肩战斗的半年感触来说说. 1. 产品经理与项目经理的互动 项目过程中,产品经理和项目经理之间多沟通,产品经理准确传达产品设计的思路,项目经理结合产品实现,给出技术实现的方案,然后一起共同评估选出最优的解决方案,这个过程中产品经理可以学习到自己所做的产品的技术实现方法.在beta1项目中我们在手机QQ.QQ浏览器结合中采用了不同于其他平台的纵向整合方案,从而大大提高了项目的实现周期.