hikaru.i.blog

is-ebiz o0a

Chapter 16 November 5, 2008

Filed under: Getting Real — hikaru011 @ 1:03 pm
Tags: ,

Conclusion


Chapter 16 is the conclusion chapter of getting real. Basically, this part summarizes all the chapters of the reading. It recalls on how to start your app, how to handle the people, how to multi task, etc. The first chapter tells that getting real starts on how to create a software backwards. Meaning creating first what will the end user will see or experience rather than starting with what the user will not be able to appreciate. The book also tackles on how to handle your people. Every people in the team should be working. Working in a way that a programmer should not always spend his time in front of the computer screen but he should also have knowledge on how to talk to clients. Every one on the team must multi task. It is also said in the book that a small company and small software has an advantage over big company and big software. There are a lot of insights we can get from this book. After reading and understanding all of the terms and insights in this book, you can now start your engines and build your own software.

Advertisements
 

Chapter 15 October 30, 2008

Filed under: Getting Real — hikaru011 @ 5:13 am
Tags: ,

To summarize it all up, this chapter talks about a few more steps before launching your
application. The first and second link talks about pre-launching the application. Getting Real
tells us readers that we should have a One-Month TuneUp before launching your application. You
have to test your application in order to tell whether the application is up and running.
With this kind of pre-launch, at least you still have time to may minor changes before the grand launch
starts.

The second link talks about not making “beta” an excuse. This link focuses on the word
imperfection. Getting Real tells us that we shouldn’t be wasting our time perfecting our application,
because it will never happen. There are no such thing as a perfect application. We cannot satisfy
every people. Some may think that this looks good with your application, others may say that it doesn’t.
Perfect Applications is a fantasy.

As I said in awhile ago, you cannot please everyone. There will come a time wherein
bad comments will arrive. You just have to “ride the storm”. Do not let them get to you. Do not ever
let them bring you down but use them as a motivation to keep you going. To help you make a better
application.

The next link talks about knowing who your competitors are. You have to know them too so that,
you too may get some tips which will help you with your application. I am not saying that you will
get his/her idea. I am just saying that you may learn from your competitors. To learn from them,
Getting Real suggests that you, as an application maker, should indulge yourself with other applications
which may help you track your competitors.

Lastly, keep an open mind!:) With this kind of mindset, you are not just focusing yourself to this kind
of system. At least, when new trends show up, you are aware of it.

 

Chapter 14 October 29, 2008

Filed under: Getting Real — hikaru011 @ 10:25 am
Tags: ,

This chapter basically tells us on what way we should build our product and how to control it after release. In the first part, feel the pain, it says there that when building something, you as a member of the team, should be aware on what is really happening around. When you are a programmer, it is also necessary that you have knowledge about the design of the product, who is your customers, what is the scope of your product, etc. As a programmer, your job does not end on coding alone. You should also know how to deal with the clients and other stuff that your group does. In dealing with your customers, you should be polite. Releasing the product is not the end of your project life cycle. You also need to support the users or your clients. You should guide them properly on the basics like how to use or run the system. Manuals are often comes hand in hand with any product that we purchase. It is where we can read on how to use what we bought. In this chapter, it is said that try building a zero manual product. It means that build a product that is so simple and user friendly so that customer can easily get used to it. But I think when you build a product that has no manual; you should open your lines for customers’ tons of questions. You don’t need to please them just be honest and just answer up straight. For example, you experiencing some technical problems, you should inform your customers right ahead before they start to panic and believe me it will cause your company a lot of troubles and worries. But when you think that it is more work loaded when you set up a huge technical support center, you can just open up a forum online. There a customer can post his own reaction over the product and can also advise other customer.

 

Chapter 13 October 19, 2008

Filed under: Getting Real — hikaru011 @ 10:14 am
Tags: ,

Basically, this chapter tells us application builders, to formally and beautifully, tell
the people about your application. In order to do so, Getting Real suggests that we should
go from a teaser, to a preview then launch. Hollywood style! With this kind of style, it
will attract people at the same time, you will know if your application clicked or not. At
least, you haven’t actually released your application yet. Instead of releasing it without
knowing if it will click or not. Like what Getting Real said: “If an app launches in a forest
and there’s no one there to use it, does it make a noise? The point here is that if you
launch your app without any pre-hype, people aren’t going to know about it.ut any pre-hype,
people aren’t going to know about it.”

You should also need a powerful promo site in order for the people to know what your application
can do. Based on Getting Real, you need the following in order to have a powerful promo site.
The following are:

*  Overview: Explain your app and its benefits.
* Tour: Guide people through various features.
* Screen captures and videos: Show people what the app actually looks like and how to use it.
* Manifesto: Explain the philosophy and ideas behind it.
* Case Studies: Provide real life examples that show what’s possible.
* Buzz: Testimonial quotes from customers, reviews, press, etc.
* Forum: Offer a place for members of the community to help one another.
* Pricing & Sign-up: Get people into your app as quickly as possible.
* Weblog: Blogs keep your site fresh with news, tips, etc.

After doing all that, you now need to put up a site wherein people can enter their email
addresses if they are interested with the application. With that kind of foundation, you can
go rolling anytime. You can also put up a site where people can learn on how you came up with
the application.

Last but not the least, give your application a name wherein it will forever be stuck on
people’s minds. It should be a catchy one and easy to remember. Getting Real suggests that
it should’nt be too descriptive. The shorter, the catchier, the more memorable, THE BETTER!:)

 

Chapter 12 October 13, 2008

Filed under: Getting Real — hikaru011 @ 11:36 am
Tags: ,

Free Sample

Basically in order to attract customers, you should entice them. An example given in the reading is apple itunes. Itunes is free software that you can download in the internet. In this strategy, Apple also commercializes or advertises their product, I pod.

Easy On, Easy Off

From signing in and signing out from a site, it should be easy. Most people prefer fast and the simplest app.

Exit with Ease

Don’t hold users against their will. If they want to leave, let them pick up with all of the content they created while they were on your site and leave…for free… You have to let the barn door open and focus on keeping your customers fed, so they want to come back, instead of coming back because they’re stuck

Silly Rabbits, Tricks are for kids

Avoid long-term contracts, sign-up fees, etc

Don’t try to find “tricky” ways to get more cash. Earn it.

A Softer Bullet

When you are about to deliver bad news, make it as painless as possible by making plenty of advance notices.

 

Chapter 11 October 8, 2008

Filed under: Getting Real — hikaru011 @ 12:33 pm
Tags: ,

There’s Nothing Functional about a Functional Spec

Spec documentation is a blueprint or outline. A functional spec is said that it usually wind up having nothing to do with the finish product. They are not the real thing that you’ll be working on. It is just a piece of paper so there’s no need to spend so much time and effort making this.

Don’t do Dead Documents

Build, don’t write. Do not waste time on making documents that are unnecessary. It is just a waste of time.

No One’s Going to Read It

I can’t even count how many multi-page product specifications or business requirement documents that have languished, unread, gathering dust nearby my dev team while we coded away, discussing problems, asking questions and user testing as we went. I’ve even worked with developers who’ve spent hours writing long, descriptive emails or coding standards documents that also went unread.

Webapps don’t move forward with copious documentation. Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper.

Don’t waste your time typing up that long visionary tome; no one’s going to read it. Take consolation in the fact that if you give your product enough room to grow itself, in the end it won’t resemble anything you wrote about anyway.

Tell me a quick story

Think strategy, not tactics. When you are about to write new features or concept of a product, it is better to write a brief story about it. Avoid using technical terms and making it as an outlined document. Use common terms that anyone can understand and appreciate.

Use Real Words

Lorem Ipsum Garbage

By not having the imagination to imagine what the content “might” be, a design consideration is lost. Meaning becomes obfuscated because “it’s just text”, understandability gets compromised because nobody realized that this text stuff was actually meant to be read. Opportunities get lost because the lorem ipsum garbage that you used instead of real content didn’t suggest opportunities. The text then gets made really small, because, it’s not meant to be used, we might as well create loads of that lovely white space.

Personify your product

Think of your product as a person. Keep these traits as the product is built.

 

Chapter 10

Filed under: Getting Real — hikaru011 @ 12:14 pm
Tags: ,

Less Software

“.. Keep your code as simple as possible.” When you keep on revising, the more complex and complicated your product will be. Remember that you have a scope and in that scope are the limitations and main purpose of your product.

  • Less software is easier to manage.
  • Less software reduces your codebase and that means
  • less maintenance busywork (and a happier staff).
  • Less software lowers your cost of change so you can adapt quickly. You can change your mind

without having to change boatloads of code.

  • Less software results in fewer bugs.
  • Less software means less support.

Optimize for happiness

It is important that when you work, people should be comfortable. When you use a language, you must think if your people can really work on it. If the workers are comfortable, they can write simply and readable codes. They can execute it properly and surely they can really do their job well.

Code Speaks

Listen up

“Don’t worry about design, if you listen to your code a good design will appear…Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.”

Open Doors

“Don’t try to lock-in your customers. Let them get their information when they want it and how they want it.: