Haberler forum başlığına Getting Real - Kitap Notları konusunun bir özeti Dediğim gibi bugün Getting Real' ı bitirdim ( son bir kaç bölüm essay kaldı ). Son zamanlarda bir çok konuda kısa notlar tutuyorum, bu notlar da Gettin Real' dan:
Less ...
Dediğim gibi bugün Getting Real' ı bitirdim (son bir kaç bölüm essay kaldı). Son zamanlarda bir çok konuda kısa notlar tutuyorum, bu notlar da Gettin Real' dan: Less Features
Only explicitly required features for that moment, If it’s not reuqired right now by you do not do it now.
Less interface.
Focus on something, solve it
Do not try to beat competitors use a new way, put something new into the market,
Know your enemy, Choose and focus a point.
Money
Use less money, small team, less features,
First version of the app should be able to developed by only 3 people.
Embrace Constraints
Use Deadlines,
Lower the scope to meet deadlines.
Business
Do not try to act big, show personality, show that you are small and take advantage of it.
Priorities
What’s your big idea?
Work small, ignore details in the beginning, you can work on them later. Try to have fun with what you do.
Don’t fix a problem before it’s a problem.
Find your audience and market, focus on their expectations,
Take a side
Application should take a side strictly, this might piss off some clients but who gives a shit. They can choose another solution.
Features
make application as small as possible, Feature wise, Code wise etc.
Instead of having lots of features which don’t work, have a few which work great,
Build features and cut it half, that's what you need,
Focus on only essential features and rest will come after essentials are good,
Remove features which “Just doesn’t matter”. If a feature not changing outcome remove / don’t develop it.
Do not try to please everyone, focus on the essentials and the target market.
Do not accept features by default, A feature should be accepted after a long battle.
Solve the root problem, and let people to solve the rest of the problem in your framework.
Add a New Feature Routine
Say no.
Force the feature to prove its value.
If “no” again, end here. If “yes,” continue…
Sketch the screen(s)/ui.
Design the screen(s)/ui.
Code it.
Process
Do it instead of spending ages on planning it, do it as a early, shortcut dirty version if it’s required.
Build, Revise, Repeat…
Avoid Prefences, Put your professional expertise, make a default setting stick with it. Just ignore little details focus on the essentials.
Do the decision, make your call, get it done, unless you got it working your idea is pointless.
It doesn’t matter it’s beta or not, get it released. It may not be perfect but release it, then you might fix it.
Unity
Have alone working time, “Set up a rule at work: Make half the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first or the last half of the day the alone time period. Just make sure this period is contiguous in order to avoid productivity-killing interruptions.”
Release often to keep yourself motivated, Add new small features and have small releases to keep yourself motivated.
Design
Prioritise the design, most important element to less important one.
Use a simple and good language in the UI.
Coding
Code less, and code only required functionality,
Do trade-offs between more feature and less code,
Think 10 times before add a new feature, think 100 times before add a BIG feature.
If you hacked the to code to get it work, go back and fix it before it bites you later.
Words
Don’t document stuff, build a mockup instead.
To explain and document features use a real-worl alike story. Don’t go into technical details do it in a human way.
Personify the application, decide a personality for your application and use it consistently in every single section. Design, interface, messages, features.
Pricing
Give something for free. Lite version, sample etc.
Make sign-up and cancellation easy, allow your users to export their data whenever day want in a acceptable format such as XML.
Don’t do stupid trick for contract, make it obvious and easy such as pay monthly and cancel whenever you want style.
Promotion
 
Write education materials, books, videos, tips and tricks about the product,
Add small features and promote them in specific groups,
Try to sell more to your current users, (such as upgrade plans)
Choose a simple, short and catchy name instead of something long and too descriptive,
Support
Do not use external support team, let developer to do the support
Use inline help (such as a note for a known problem) in the application and Keep stuff simple so anyone can use it without training,
Have a quick turnaround time in support requests (no more than an hour),
Customer is not always right,
Use forums to help customers to themselves,
Publicise Bad News
Post Launch
Keep a development blog,
Keep releasing often, show people that you are alive,
Don’t do public beta, if it’s not good enough to be public don’t make it public,
04-12-2008, 00:55
Getting Real - Kitap Notları 
Benzer Konuları Oku 
