1) Don’t respond to job postings unless you want your resume to end up in a pile.

2) Get your foot in the door: Instead, if you find a job in a company X that you want to apply for, use social networking sites such as LinkedIn (this is the only one I use) to see if you are connected to someone who works there or if one of your connections knows someone who works there – then get recommended. You are looking to get a foot in the door and get the first phone call. Candidates who have been recommended by internal sources will at least get the first phone call – it is up to you to take it from there. If you know someone at the company, it will also give you an inside scoop – what is the real story, how is it to work there, anything about your future boss you need to know about – his/her management style etc.

3) Call the hiring manager: If you are not connected to anyone, again use LinkedIn to see who the hiring manager could be – I look for titles such as VP of Product Strategy, VP of Marketing, VP of Product Management etc. If LinkedIn does not have it, look at the company’s website under the Team/Management section. Then call the company and ask for that person – if you do get the person on the line (tough because people are travelling or are in meetings), tell them who you are and why you are calling. If you get the standard response of apply for the job and send it to HR, be frank and tell them that you are trying to get your resume visible and ask if you can send the resume to him/her so that he/she can send it to the hiring manager. There is nothing wrong in asking, worst response you can get is a No. A lot of times this will work and it also shows your initiative and strong interest. Then email your resume within a day so that your name is still fresh in the other person’s mind. Followup with the person via email (no phone calls) after a week if you have not heard anything.

4) Email the hiring manager (long shot): If you do not get hold of the hiring manager over the phone, then try the long shot – you need to figure out if you can get his/her email address. How do you know if it is roberts@xyz.com or robert.smith@xyz.com or smithr@xyz.com – look at the bottom of the press releases at the company X’s website. The company’s contact for the press release typically puts his/her email address at the bottom – this will get you the syntax. Again, sending a cold email is a very long shot and may get you a response only if you are a very strong candidate. I will not follow up on such an email because you don’t want to spam the person.

5) Work your network - there is a great book of “Dig the well before you are thirsty” that is worth reading – basically don’t try to create the network just when you need it – keep your network alive, help others when they are in need and they will help you when you have a need.

6) Get involved in local product management associations – present at conferences on product management topics – you want to be seen as a subject matter expert – you need to do things (good things !) that will let you stand out in the crowd.

7) Always keep looking for a job – you never know what opportunities come along your way – but you don’t want to be switching too often either – pick a job that broadens your experience, stay there for a while, succeed and then think about making a career move.

8. Research, research, research - Get to know about company X as much as you can – as if your life depended on it – you need to comb through its website and know everything about them – where have they been (look at company history, look at old press releases), where are they going (job postings may give you an idea about their future direction), read about the company in the news – what else are others saying about the company (don’t just believe what the company says about itself). Last thing you want to be is a candidate who is not prepared.

9) Company cheat sheet – Prepare on companies you have applied to as if the phone could ring at the very next second for an interview. I created a 1-2 page cheat sheet on each company I applied for so that I can have this information at my finger tips (in case the phone rang).

10) Company’s customers - Can you find a way to talk to some of the company’s customers? If the company has a discussion forum, you may be able to find customers there – what do they think about the company? How are the company’s products perceived? What is the future of the company in the eyes of the customer? If you do talk to their customers, mention this during your interview – it shows how well you research something, how comfortable you are talking to customers etc. – good companies value this and if they don’t, it may not be the right place to work after all.

What about recruiters? I did not have good luck with recruiters – not that they are bad – but they are hired by companies when their own recruiting efforts have failed and hence recruiters only look for a round peg in a round hole – their clients give them specific requirements and recruiters cannot flex them too much to accomodate a candidate’s qualifications.

Original

1. A Delivery Focus
Being delivery focused begins with releasing software the moment it is written (almost). Releasing means to get the software into the hands of real, live users. Nothing else counts - developer-done doesn’t count, deploying on QA environments doesn’t count, staging doesn’t count.

2. Clear Priorities
Without a source for rock-solid priorities, a development team will flounder. Rock-solid means that at any given time, anyone on the team can say what the next few most important things are. It also means that it is rock-solid until it is changed (which can happen at any time, based on changing reality and discovery).

3. Stakeholder Involvement
The one thing you can’t outsource is your product-owner function.

4. Business Analysis
. To help with analyzing requirements down into suitable chunks of work, they should be created with the INVEST principles in mind. On teams delving with sufficiently complex domains, having business analysts that both understand the domain and are able to create such stories is a must. Again, the important thing here is the role - and that someone needs to do it. Having a team of poly-skilled people that include this skill-set is enough as well.

5. Team Size and Structure
There is plenty of research and literature out there that speaks to the negative impact of having too many people on a team. Even empirical observation allows one to reach the same conclusion - after all, how many smooth and successful large projects have you seen?

you can’t always scale up the rock-star developers that are required for a project to be successful.

In other words, it’s probably Ok to hire less of those awesome developers you know if you paid them twice as much as your finance department thinks they’re worth.

6. Planning and Tracking

7. Technical Architecture

8. Testing, QA practices
Automated tests are the most important part of a code-base. Period.

9. Understanding software development
This one is actually the simplest to state, but I’ve noticed that a lot of people have trouble accepting it. Here it is - people who run software projects should know what software development is all about.
If your project is being run by someone who doesn’t really understand the nuances of software development, and heaven forbid thinks he/she does, then you’re in trouble.

Original

Always fix error handling before fixing errors.

Fix a chain of bugs backwards, from last observed problem back to the original cause

Original

Kiváló könyv arról, hogyan is kellene a pénzről gondolkodnunk. Azoknak, akik nem bánnak jól a pénzzel, roppant fájdalmas olvasmány. De ez már csak ilyen. A tapasztalatom az, ha valami olvasmány fáj, akkor abban erősen megfontolandó dolgok vannak.

I have read this book long time ago. I have planned that I make an extract from the book whihc contains the most valueable advices for me. Unfortunatelly I had forgotten this goal. I need to re-read it. But I am 100% sure that it is a great book.

Homepage

Productivity is Defined by Time Spent Not Working

original

Motivate Yourself

1. Find your mission

2. Replace negative self-talk with positive one

3. Have fun

4. Change your work environment

 

Prepare Yourself

1. Find your strengths

2. Find your role models

3. Find partners

4. Prevent problems through planning

5. Be informed

6. Keep your mind clear of stuff

7. Calm your mind

Equip Yourself

1. Build your personal knowledge base

2. Master Google-fu

3. Master your tools

Manage Your Energy

1. Exercise

2. Find your peak time

Manage Your Workflow

1. Determine never to be idle

2. Focus on actionable ideas

3. Eliminate

4. Delegate

5. Batch similar tasks

6. Apply 80/20 principle

7. Set a deadline

8. Befriend “good enough”

9. Measure how you do things

10. Optimize your routines

11. Automate your routines

Optimize Your Working Session

1. Do ultradian sprint

2. Set a minimum time to start on a task and don’t stop before time is up

3. Think like a lazy person

4. Break a task into small steps and do them one at a time

5. Reward yourself often

6. Do unpleasant tasks first

7. Get the first draft out as soon as possible

8. Befriend checklists

9. Backup your work

 

Original

Mit jelent ez konkrétan az Ön számára – gondolkozzon el:

• Ön hosszú-hosszú munka után végre 67-évesen elmegy nyugdíjba. Csönget a postás és átadja az első nyugdíját, 32 ezer forintot. Oda rakja az asztalra. Hogy fogja érezni akkor magát?

• Milyen érzés lesz végiggondolni, hogyan ossza be ezt a pénzt? Mire költse? Fűtésre, világításra vagy ennivalóra? Egyáltalán, milyen érzés ilyen dolgokon töprengenie 67 évesként?

• Milyen érzés eladni a családi kocsit és tudni, hogy már sohasem fog másikat venni?

• Megalázó érzés lenne hetvenévesen is dolgozni: például egy McDonalds-ban tálcákat pakolni, meg WC-t pucolni?

• Mit fog érezni, amikor először kell pénzt kérnie a legszükségesebbre a gyerekeitől?

• Hogyan fogja magát érezni, amikor a gyerekei elől eltitkoltan életjáradékért el kell adnia a családi lakást, amiért egész életében küzdött? És amikor megtudja, hogy a 10 milliós lakásáért a nyugdíja mellé csak 39 ezer forint életjáradékot fog kapni?

• Milyen érzés lesz a gurulós bevásárló kocsival átmenni a város túl felére a hipermarketbe az akciós csirke farhátért? Most ma ezt csak viccesen banyatanknak hívja, így az autóból nézve. De mit fog érezni, ha magának kell élete végéig így bevásárolni mennie, ha kell messze is, de a legolcsóbb holmikért?

• Keserű érzés lenne, ha beállítanak a csodálatos unokák és még egy Kinder tojással sem tudja meglepni őket?

• És milyen érzés lesz, ha romlik a szeme és az orvos azt mondja: szürke hályog – meg kell operálni. De ennek költsége 270 ezer forint. A TB ezt már sajnos Önnek nem tudja fedezni, de egy fehér botot ki tud utalni.

• És hogy fogja magát érezni, ha megtudja milyen szerencsés: hiszen nőként átlagosan 23 évet, férfiként 17 évet élhet így boldog nyugdíjasként!

 

Persze nem muszáj ennek így lennie. Dönthet úgy – mert most már tudja, az államra nem számíthat, – hogy saját maga gondoskodik a nyugdíjáról.

• Milyen érzés lesz, amikor egyszer csak hatvan évesként kap egy levelet, hogy elkészült a nyugdíj tőkéje, és innen kezdve másfélszer annyi pénz áll havonta csak ebből rendelkezésre, mint amennyit eddig a munkájával keresett?

• Mit érez majd, amikor szabadon dönthet, akkor megy nyugdíjba, amikor csak akar?

• Milyen érzés, hogy végre van ideje és utazgathat, hobbijának élhet, minden aggódás nélkül?

• Milyen érzés lesz rájönni végre ideje és pénze is van élni?

• Hogy érzi majd magát, ha tudja, van lehetősége a gyerekeit támogatni, unokáit kényeztetni?

• Hogy érezné magát, ha az lenne a legnagyobb problémája, hogy arról döntsön: inkább salsát tanuljon vagy golfozni?

• Milyen érzés, ha tudja, ha mégis megbetegedne, képes megfizetni a gyógyszereket és orvosokat?

• És hogy fogja magát érezni, ha megtudja milyen szerencsés: hiszen nőként átlagosan 23 évet, férfiként 17 évet élhet így boldog nyugdíjasként!

Ha ön 50 alatti, akkor dönthet ez a két forgatókönyv közt.

Persze, egy ilyen döntés nagy áldozatokkal jár. Lehet, hogy a 102 centis tv helyett be kell érnie 82 centissel. Lehet, hogy a három évenkénti kocsi csere helyett be kell érnie, hogy csak négyévente cserél. Lehet, hogy a lakásfelújítást is el kell halasztania egy évvel. Tudom, ezek iszonyatos lelki kínokat tudnak okozni. De olvassa csak végig még egyszer, mit fog érezni majd friss nyugdíjasként? Onnan visszanézve, valóban annyira komoly és kihagyhatatlan dolgok voltak ezek?

 

Original

Amikor az ember az amerikai sajtót olvassa először is azon döbben meg, hogy nem (csak) azzal foglalkoznak, ki a felelős, hogy történhetett mindez, nem aggódnak és nem rágódnak, hanem azt elemzik, magyarázzák, mindenkinek a saját élethelyzetében, tudásszintjén: Mit kell neked csinálni? Hogyan gyere ki ebből jól? Mi az, amit neked el kell kerülni?

...

Az rendben van, ha izgulunk, de próbáljunk meg nem pánikba esni. Ha több mint 10 éve van még a nyugdíjig, és megtakarításai megfelelően porlasztottak, akkor valószínűleg könnyedén kimászik ebből a helyzetből, amikor a piacok majd kijönnek a válságból.

Original

Kettős érzület. Jelentős részét már ismertem, mert Joeal honlapján is szerepel. De azért voltak érdekes dolgok, amik nem.

Tanulságos és érdekes

Jó kis kivonat

Kiválló kiadvány. Csak maximumon beszélhetek rólla. Nem célja, hogy megtanítson emberekkel bánni. A cél csak az, hogy eszközöket adjon a kezedbe egy jó kis retrospektív (magyarul kb visszatekintés) megbeszélésekre.

A retprospektív fázisai:

1. Set the stage
2. Gather data
3. Generate insight
4. Decide what to do
5. Cose the retrospective

Minden lépéshez van egy halommódszer, technika arra, hogyan lehet a megfelelő lépéseket összegyüjteni. Technikák, ami rutinosabb emberekkel és technikák, amik zárkózottabb emberekkel működik jobban.

Olyan könyv, ami beteszek az újraolvasandók közé.

honlap

sample

Technical debt always has the same 3 questions:

1. How much is the technical debt really costing us?

2. How much will it cost to pay down this debt?

3. How will I know it is time to pay down this debt?

So how does one answer all of these questions in a way that can be understood by a project stakeholder?

1. Keep track of time spent working around the debt

find a way to measure your pain in a quantifiable manner that can be perceived by anyone as money and time wasted.

Answers the question: “How much is the technical debt really costing us?”

 

2. Estimate how much it will take to pay off the debt

Estimating how much time and effort it will take to pay off the debt is perhaps the easiest of the questions to answer. Simply put together your battle plan for the refactor and estimate it out. Feathers in Working Effectively with Legacy Code might even suggest actually doing the refactor 70% through and then throw it away just to truly understand the size and steps to support the change for real.

Answers the question: “How much will it cost to pay down this debt?”

3. Determine a tipping point of when it makes sense to refinance (pay it off)

Now that we have measured both the cost of the debt (debt interest) and the cost of the refactor (debt refinance costs), we can frame in the answer to if it makes sense to eliminate the debt by using a house mortgage analogy.

The exact same goes for software: if the data access layer is causing us 60 hours a month in lost time, and it will cost 300 hours to refactor, does it make sense to pay this off right now knowing we will see a return in productivity in 5 months?

Answers the question: “How will I know it is time to pay down this debt?”

Original

When I worked with Zak Tamsen, one of his favorite (software development) sayings was: Kill Your Darlings. The idea was simple, don't get too attached to code.

Original

• Dead Programmer

  This is the highest level. Your code has survived and transcended your death. You are a part of the permanent historical record of computing. Other programmers study your work and writing. You may have won a Turing Award, or written influential papers, or invented one or more pieces of fundamental technology that have affected the course of programming as we know it. You don't just have a wikipedia entry -- there are entire websites dedicated to studying your life and work.

  Very few programmers ever achieve this level in their own lifetimes.

  Examples: Dijkstra, Knuth, Kay

   

• Successful Programmer

  Programmers who are both well known and have created entire businesses -- perhaps even whole industries -- around their code. These programmers have given themselves the real freedom zero: the freedom to decide for themselves what they want to work on. And to share that freedom with their fellow programmers.

  This is the level to which most programmers should aspire. Getting to this level often depends more on business skills than programming.

  Examples: Gates, Carmack, DHH

   

• Famous Programmer

  This is also a good place to be, but not unless you also have a day job.

  You're famous in programming circles. But being famous doesn't necessarily mean you can turn a profit and support yourself. Famous is good, but successful is better. You probably work for a large, well known technology company, an influential small company, or you're a part of a modest startup team. Either way, other programmers have heard of you, and you're having a positive impact on the field.

   

• Working Programmer

  You have a successful career as a software developer. Your skills are always in demand and you never have to look very long or hard to find a great job. Your peers respect you. Every company you work with is improved and enriched in some way by your presence.

  But where do you go from there?

   

• Average Programmer

  At this level you are a good enough programmer to realize that you're not a great programmer. And you might never be.

  Talent often has little do do with success. You can be very successful if you have business and people skills. If you are an average programmer but manage to make a living at it then you are talented, just not necessarily at coding.

  Don't knock the value of self-awareness. It's more rare than you realize. There's nothing wrong with lacking talent. Be bold. Figure out what you're good at, and pursue it. Aggressively.

   

• Amateur Programmer

  An amateur programmer loves to code, and it shows: they might be a promising student or intern, or perhaps they're contributing to open source projects, or building interesting "just for fun" applications or websites in their spare time. Their code and ideas show promise and enthusiasm.

  Being an amateur is a good thing; from this level one can rapidly rise to become a working programmer.

   

• Unknown Programmer

  The proverbial typical programmer. Joe Coder. Competent (usually) but unremarkable. Probably works for a large, anonymous MegaCorp. It's just a job, not their entire life. Nothing wrong with that, either.

   

• Bad Programmer

  People who somehow fell into the programmer role without an iota of skill or ability. Everything they touch turns into pain and suffering for their fellow programmers -- with the possible exception of other Bad Programmers, who lack even the rudimentary skill required to tell that they're working with another Bad Programmer.

  Which is, perhaps, the hallmark of all Bad Programmers. These people have no business writing code of any kind -- but they do, anyway.

  Original

• Amount of uncertainty – Higher the uncertainty, shorter should be the iteration length to tackle the uncertain scenario.

• How Long Priorities Can Remain Unchanged – If the priorities for the stories are changing within an iteration then it is a fair indication that the iteration length needs to be shortened.

• The Overhead of Iterating – If the project needs a ‘manual’ regression suite to be executed at the end of each iteration then shorter iterations could be more expensive.

• How Soon a Feeling of Urgency Is Established – If the iteration lengths are too long then the team tends to become complacent through the early phase of the iteration and gets into a crunch mode towards the end. The key is to decide on a length which encourages the team to work at a consistent pace.

Original

Original

Scrum is a tool. Kanban too. And cool.

Original

Alapvetően fontos ismeret a tapasztalatról s türelemről. 

1. Understand what is most important to work on.

2. Get more done by doing fewer things at once.

3. Understand your own capacity before you commit. Track where your time goes for a couple of weeks. How much time do you spend checking email, answering questions, going to meetings? Look for ways to reduce interruptions and reduce the biggest unproductive use of your time. (Taking breaks is not an unnecessary use of your time. We all know that we do better if we take a little breather from time to time.)

4. Review all the meeting you attend on a regular basis.

5. Make commitments based on your known capacity, rather than on an ideal 40 hour week.

6. Work in inch pebbles. Break down projects into tasks that you can complete in a day or two. When you do this, you can report tangible progress at least twice every week. You will become known as someone who gets work done.

7. Test as you go. Check in code at the very least once a day, and run all your tests for that piece of code each time you check in. That way, you will avoid having a false assessment of progress by deferring knowledge of problems until the (false) end of the task.

8. Peer review all fixes. A defect is a clue that the code is difficult to understand or poorly written. So you will avoid breaking something else by having another set of eyes look at the fix.

9. Write tests for the defect fix, and then write a half-dozen tests (at least) in the code around the defect. Defects tend to cluster, so you will be strengthening your code and your feedback system by writing additional tests.

10. Work at a sustainable pace. Tired people make mistakes and write or miss defects.

Original

• Address issues directly. These conversations aren't always easy. Sometimes people delay the uncomfortable discussion until the situation becomes intolerable, letting anger and resentment build....When hisj coworker talked to the manager instead of talking directly to Seth, he broke trust.

• Share Relevant Information. If you don't support an idea or approach, say so....When someone on the team withholds and opinion or concern when a topic is under discussion and then comes back later to say "I thought it was a bad idea from the start," other team members feel blindsided. That breaks trust....Relevant information is about the task, but it's also about you....In order for teams to function, team members need to believe that their co-workers are reliable. Without the confidence that others are reliable and will carry their share of the load, few will commit to a shared goal.

• Say No When You Mean No. Sometimes you just can't take on another task, or do a favor that someone asks for.

• Follow Through on Commitments or Give Early Notice When You Can't. No reasonable person expects that every person can meet every commitment all the time....So let people know as soon as you know, and renegotiate.

• Show What You Know and What You Don't Know.

Original

Időgazdálkodás: mindig nagy kedvencem volt. Gyakorlatilag véletlenül botlottam bele, de miután megismertem, hogy a szisztematikus időmenedzsment mikét változtattam meg azt, hogy mit is tudok ténylegesen végrehajtani más síkra helyezett. Egyik leginspirálóbb a GTD volt. Egyszerű, mint a faék és mégis roppant hatékony. Csináltam aktívan, de végül megbuktam.

Mindent azon elvek szerint szerveztem. Miért? Hibás volt a módszer? Nem. Rosszul használtam? Nem mondhatnám. Akkor mi volt a gond?

Jellemző volt a GTD rendszeremre, hogy mindent abban tartattam. De tényleg. A magánéleti céljaimat, a munkahelyi projekteket, bevásárlólistát. Szóval mindent. Nem is volt gond. De nyomasztott. Elsőre nem is tudtam, hogy mi. Aztán kezdtem kapiskálni de még nem találtam meg a végső választ. amit észrevettem és nem tetszett az az volt, hogy eluralkodtak a munkahelyi projektek a rendszeremben. Mikor végignéztem a projektjeim listáját és a benne lévő feladatokat szinte elnyomott, hogy mi mindent kell/szeretnék ott leintézni. Nem a delegálással volt a gond, hanem egyszerűen sok mindent akartam megvalósítani, sok mindennel kellett foglalkozni. De ez csak egy tünet volt, ami zavart, hogy mikor végignéztem elnyomta a munkahelyi lista a magánéletimet. Nem tudatosan egy megoldást alkalmaztam ennek a feszültségnek megoldására: elkezdtem hanyagolni a GTD rendszert. Gyakorlatilag nem tettem bele új elemeket és a meglévők szépen lassan kifutottak. A munkahelyi dolgokat elkezdtem a munkahelyi dokumentumokban és rendszerekben használni. A magánéleti meg valahogy elsiklott. A feszültségem csökkent, de a teljesítményem romlott.

Olvastam egy másik könyvet (elkezdtem, mert akkor rossz passzban voltam és hangulatom a béka segge alatt és lejegeltem egy laza informatikai könyvért cserébe) annak címe Először a fontosat! Abban említést tesz, hogy "elavult" időgazdálkodási módszerek miért hibásak: nem foglalkoznak azzal, hogy milyen szerepei vannak az embernek és mi a ténylegesen fontos. Azaz volt korábban ezekről szó, de az időgazdálkodási módszerek az idő menedzselésére fektették a hangsúlyt és ettől függetlenül (rendszeren kívül) volt a tényleges cél meghatározása és fontossági kérdések. Ebben a könyvben (amíg elolvasta) erre nagy hangsúly került. Az embernek különféle szerepei vannak. Több szerep a munkahelyen, többféle szerep a magánéletben. Mindegyik szerepnek mások a céljaik ezek néha ellenmondanak egymásnak. Másik a sürgős és fontos dolgok. Ezen tényezőkkel is figyelembe kell venni, amikor az időnkkel gazdálkodunk. Később visszanéztem a GTD könyveket és megtaláltam, hogy abban is ki van ez hangsúlyozva, de elsiklottam felette. hiszen olyan sok szól a munkaszervezésről, hogy a prioritások "csak meg vannak említve", mint heti áttekintő része. Ez a felismerés jó volt, mert visszazökkentett a rendes szervezésbe. Jó teljesítmény és csökkent a feszültség.

Miért is említem meg mindezt? Minap kaptam egyik munkatársamtól a Bagolyvár Időforrás Prémium csomag hanganyagát. Ami elsőre leesett, hogy ugyan ezekre a problémákra ad választ. De a csomag ennél sokkal több. Rengeteg témában adott ihletet. Ami különösen tetszett az a lelkesedés. Rá kellett jönnöm, hogy az írott motivációs anyagok nem olyanok, mint egy fele olyan jó, de lelkes, motivált előadó. Egyszerűen ilyen az emberi természet, átragad a lelkesedés és tettrekészség. Fontos kivel veszed körül magad.

Lássuk a tartalmát:
 

CD1
5 GONDOLAT – amely örökre megváltoztatta az életemet
01 Alapértékeim tisztázása, avagy séta az I gerendán
02 ha vezetőként beosztottai munkáját végzi, nem marad ideje a saját feladataira
03 A kulcs: heti tervezés
04 A fejben tárolt dolgok zavarják a gondolkozást
05 Az időhiány valójában a fontossági sorrend hiánya
***
06 Miért vagyok itt?
07 Eredményesség gyorsteszt
08 Tervezés
09 Hatékonyság
10 Fegyelem
11 Mobil szervező alapelvek
12 A Mobil szervező összeállítása
13 Éves áttekintő – Heti áttekintő
14 Heti tervezés – Időpontok
15 PapaBank

CD2
01 Késés és rövidlátás
02 Ne csak az életedben, de az életeden is dolgozz
HETI TERVEZÉS – FELADATOK
03 Miből van pénzem?
04 Miből lesz pénzem?
05 Miből/Mikor lesz nyugdíjam?
06 Élezd meg a fűrészt!
07 Információk
08 Delegálás
09 Otthon
10 Heti zárás
11 A .xls; mentések
12 Egyszerűség, rendszer, távirányítás
13 Számítógép
14 Mennyit ér az időm?
15 Napi tervezés

CD3
01 MOST
02 Semmit ne tarts fejben
03 Papír kontra memória
04 Egyensúly
05 Értelmi és érzelmi tanulás
06 Munka és otthon
07 Szabadság gyorsteszt
08 Fontos és sürgős
09 Idő és pénz
***
10 IDŐPIRAMIS
11 Kontrolláld
12 Takarítsd meg
13 Fektesd be
14 Teremtsd
CÉLKITŰZÉS
15 Célkereszt
16 Ésszel és szívvel
17 A lét határozza meg a tudatot
18 Érzelmi komfortzóna

CD4
01 A gondolat teremti a valóságot
02 Végigmenni a skálán
03 Varázsdoboz
04 Célok és határidők
05 Következő lépés
VEZETŐI IDŐGAZDÁLKODÁS
06 Vezetői eredményesség
07 Gyorsteszt
08 Hatástöbbszöröző 3 + 1
09 Kommunikáció
10 Modern technológiák
11 Emberek menedzselése
12 Emberek vezetése
13 Evolúciós hálózatok
14 (S)ikerspirál
15 Ki vagyok?
16 Ki lehetek?

PRÉMIUM HANGANYAG

CD5
01 Bevezetés
02 KORSZAKVÁLTÁS
03 Kapcsolatok
04 Motiváció
05 Tanulás
06 Idő
07 Fókusz
08 Célkitűzés
09 Tőke
***
10 A tanulás forradalma
11 A tudományról
12 Polaritás
13 Az ember kettős természete
14 Párhuzamos világképek
15 Látszólagos ellentétek

CD6
01 Fókuszváltás
02 Üzleti szemlélet
03 A természetes út
04 Az időszervezés eszközei
05 A célkitűzés paradoxona
06 Éves tervezés
07 Az időszervezés ciklusa
08 A mobil szervező felépítése
09 Cascade prioritás modell
10 Környezet profil

CD7
TÁRGYALÁSTECHNIKA VILLÁMTRÉNING
01 Felkészülés ésszel
02 Felkészülés szívvel
03 Forgatókönyvek
04 Tervezés
05 Elvkövető tárgyalás
06 Versengő tárgyalás
07 "Szovjet" típusú tárgyalás
***
SZILÁNKOK
08 Tanulás az információs korban
09 Ha önmagadhoz más jobban ért
10 Az átállás hibái
11 Rossz gondolat
12 Egyik láb, másik láb
13 Kikkel töltöd az idődet?
14 Testreszabott megoldások
15 "Vízhatlan rekeszek"
16 Stressz-mentes élet
17 Komfortzóna
18 Megtérülés gondolkozás
***
19 ÉRZELMI ALKÍMIA
20 Zárszó

Ok, here’s what to do. Ask these kinds of questions:

• Give me a recent example of how you helped a team develop a drumbeat, a project rhythm.

• How do you know the project is on track? (Ask for examples)

• What have you done to help a project get back on track? (Ask for examples)

• How do you obtain status from people? (Ask for examples)

• Tell me about an obstacle you recently removed. … How long did it take?

• Have you ever been in a position where the product owner wanted to add a new item to the iteration backlog after you’d started the iteration? What happened?

Because a Scrum Master helps the team stick with the process and remove obstacles, you can start with questions such as these. Consider adding an audition such as facilitating a standup meeting, working with the product owner on the backlog.

Original

I will let you in on a secret: the „experts” in any given field have usually just read one HOWTO more than you have.

...

Developing software is definitely not the most complicated and demanding way to make money.

Original