Формулировка требований: от очевидного через ум-за-разум и далее к пониманию того, что ничего не понятно

Наболело.

Как же сложно формулировать свои мысли БА. И не только начинающему, но и опытному. И, казалось бы, что может быть проще: записать пожелания заказчика образом понятным и заказчику и разработчику. Ан, нет! Сложно это, сложно!!!

Фраза из И-нета "Еще когда проект существует лишь в виде идеи "а хорошо было бы сделать Нечто", уже подразумевается, что сие Нечто должно удовлетворять целому набору специфических — далеко не очевидных, однако крайне ответственных и от этого не менее расплывчатых — требований."

Первое, что нужно уяснить: требования в голове заказчика и его сотрудников.
Именно там и нигде еще. И нужно просто вытянуть эти требования, не нужно их сочинять. 

Просто? Блин, это сложнее, чем даже просто сформулировать свою мысль!

Второе, что нужно уяснить: требование должно быть записано однозначными терминами. Термины должны быть согласованы и зафиксированы в Глоссарии. Все на проекте говорят на 1 языке. Никаких синонимов, никаких двойных толкований. 1 термин = 1 значение.

А вот это на первых порах для БА, обученных в школе использовать местоимения и показывать интеллект богатством синонимов и оборотов речи, непосильный труд... Иногда хочется спросить учителей русского языка: вы понимаете, что правила литературной речи хороши лишь для литературы. В реальной работе это ой как мешает!

Третье, что нужно уяснить: читайте то, что пишут в проектной документации коллеги. На проектах, в отличие от пустых бумаг отчетов, пишут важные вещи. Как же нас разучили читать. Мы пишем зачатую кучу ненужных бумаг для отписки. Радуемся количеству написанных страниц. И еще больше радуемся тому, что это особо никто не читает. Так вот в ИТ-проектах не так: пишем документы, которые ЧИТАЕМ.

Что запомнилось с ТИБО-2014

Каждый год на ТИБО кто-то из компаний обязательно сделает что-то запоминающееся.
Что запомнилось в ТИБО-2014?


1. Классный почти карманный 3D принтер. 
Мастерски из красной (или любого другого цвета) проволочки делает любой пластмассовый предмет. На экране видно, что должно быть в итоге. В под рукой мастера красный предмет обретает формы... :) Понравилось смотреть, как на моих глазах создается крышка к смартфону :)



Впечатлил сканер, который на ходу определяет, кто стоит перед камерой. Правда, пока определяет с небольшой погрешностью (+-9 лет) и почему-то в профиль дает больше лет, чем в анфас... С определением чувств пока слабоват, но пол определяет верно и вообще очень веселая штука :) Как зеркальце "Свет мне зеркальце скажи, да всю правду доложи!"


Атлант Телеком раздавал коктейли собственного приготовления. Интернет пока у них не суперскоростной и устойчивый (особенно, когда не заплатишь вовремя). Но точно теперь могут сказать, что кормят своих клиентов, ничего не жалеют!

Не очень поняла назначение и глубинный смысл оформления летящими человечками биллинг-разработчика. Но креатифф есть. Возможно, вы продвинитесь чуть дальше, чем я в понимании :) 

А вот примерно так будет выглядеть учебник будущего. Это Биология. Какой-то класс школьной программы. Все на планшете - совместная программа МТС и Мин.образования РБ. Респект! 

И к оформлению стенда подошли очень основательно. Мне понравилось! С удовольствием пообщалась с девушками из компании МТС. Рассказывали все с превеликим удовольствием и очень толково. Еще раз респект и уважуха!

А вот примерно так будет когда-то в будущем выглядеть человек на ресепшн. Мило улыбаться и рассказывать, какие есть услуги, куда повернуть и куда последовать. Плоско, занимает мало места, может повторять без запинок и без обид все инструкции.

И в завершении, конечно, как обычно выделился Воргейминг - устроили шоу-рум с громадной очередью. 

Умейте искать и правильно заимствовать идеи

Иногда кажется, что революционные вещи выдумывают те, кто их презентует. Нет, вы даже не представляете, кто именно предлагает революционные идеи. А не знаете, потому что, когда эти идеи предлагают, они кажутся настолько фантастические, что записывают их только в фантастических романах.


Узнаете?

Да, это один из рабочих компьютеров 1970х - IBM 2250 Mod 4 display station. Стоила машинка всего $280 000 (это при тех ценах). 


Вот даже мануал для машинки есть: http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/2250/A27-2723-0_2250mod4Descr.pdf

Думаете Стив Джобс один, кто взял у IBA идею с управлением данными кликами по монитору? Конечно, нет! До этого были Xerox, Nokia и многие другие. Но управление пальцами по экрану с удовольствием и за приемлемую цену - это 100% Стив!!!

И кого мы сейчас считаем изобретателем? Правильно! Стива!


К чему веду беседу? Прямое копирование - это, конечно, плохо. Но найти рабочую идею, доработать (часто незначительно) - это правильно. На этом принципе строится экономика. Мы должны принимать лучшее и развивать. Только так мы будем помогать прогрессу.

11 уроков из жизни опытного бизнес-аналитика

The 11th Powerful Business Analyst Lesson from Life of Pi - This Will Surprise You!
It was a tex-mex night at Rose and Crown pub where we have our monthly GTA Business Analysts meetups. Bennett (who is btw, the voiceover for the intro on the BA podcast that I host) always has interesting insights that he brings to the table (no pun intended).
He seemed to really enjoy the “10 Powerful BA lessons from the Life of Pi” that to my pleasant surprise became the top article of 2013 here on BA times. In addition to these 10 inspirations, he reminded all of us about a scene from the movie that can serve as a very important lesson in life; his perspective on this event in the movie inspired me to write this post (Thanks! Bennett).
Let’s also explore the angle of how this can serve as a powerful lesson for Business Analysts later in this post.
So, the scene he was alluding to was the one that can make you wonder to say the least.
When you read about this in the book or watch it come to life in the movie, you will be taken aback. The first question that may cross your mind is:
“Are you serious?” or “Why Pi Why? Why did you do that?”
It so happens that when you are in the middle of the ocean with thinning supplies and having company that can eat you up alive any second, your gut response would be to elude danger. Pi had to build a satellite raft to stay away from the big beast and to ensure he stays alive out in the wild waters. So, when the storm hits the ocean and everything goes helter-skelter the tiger gets overthrown into the ocean.

HURRAY! THE DANGER IS AVERTED!

“Adios Tiger!”, you may exclaim sub-vocally rejoicing Pi’s freedom in the theatre or jump up in joy if you are in your living room.
However, he does something that has a deep meaning and implication to his survival.
He pulls the tiger back on the boat and rescues him. Because he knew that the Bengal beast was the reason for his survival. He had to be alert and resourceful to continue to survive and also keep the tiger alive. He lived because he knew he was going to die, he forged ahead in the unknown territory because the ocean was a dead end for him, and he was sane because the sheer panic to survive left no room for insanity.
It could have been Pi’s perfect moment to scoot away and bid adieu to the big cat. However, the same danger was the very root of his survival in the sea. Pi remained alive, agile and alert because of the tiger. He had a purpose to serve and something to look out for and to look after. Someone to fear from and to confront with.
So, here is another lesson for life:

“BRING THE TIGER IN”

When we are riding a high wave in the ocean, confronting real tangible fears of the water and the unknown, that’s what is making us strong. There are times when we do realize that an imminent danger is a bad thing, when in reality it may not be.
So, what is the tiger in the context of being a Business Analyst (or any professional)?
Let me illustrate with three examples.

A TOUGH PROJECT – STAYING ON

Sometimes, the urge to quit an organization or project because of tough stakeholders or insurmountable politics or other challenges will seem like an obvious choice. However, this can make us stronger and build our resistance and immunity to face them in future. When you make a reasonable assessment of the danger and get a perspective on the situation, you can use a tough project as an excellent growth opportunity.

CAREER STAGNATION – MOVING ON

As a business analyst, you are champion for facilitating the change in an organization. If you fear change or fear the possibility of confronting a career change, you maybe in trouble. Without tangible career growth, if a stable job and wonderful colleagues (is there anything more?), make you feel like this is your dream job, then you need to step back and get a perspective. Moving on to explore other opportunities is another way you can bring the tiger in.

AN UNREASONABLE PROJECT MANAGER OR PEOPLE MANAGER

Most of the times an unreasonable project manager or people manager will have something useful to offer as an experience for you. Take it up as a challenge to question estimates, provide reasoning, and persuade to help a PM understand your POV. If your career manager has unreasonable demands, use this an opportunity to negotiate and set realistic expectations.
As you can see, there is always a reason for an event to take place in anyone’s life or career. The immediate danger of the tiger actually kept Pi live; so, when you confront your tiger make sure you think of this lesson to help the beast embark on your boat and make you stronger!
So, what has your tiger been in the present or past projects? Are you bringing it back on the boat?


Как узнать, что ты уже готов стать бизнес-аналитиком?

FEATUREJune26thWhen I think about my transition into business analysis, the first thought that comes to mind is a hallway conversation. A senior BA on the business analyst team approached me on my way back to my desk and mentioned a new position was opening in the department. She recommended I apply.
My first response was “well, there are a lot of projects in QA right now; it might not be a good time.” And her much wiser response to me was “Well, then when will be a good time? This is a good opportunity and probably more money too.” It was good advice. After a lot of soul searching about whether or not moving into business analysis was really a good career move for me, I acted on her advice and applied to the internal position. About a month later, after just a year and a half on the QA team, I found myself moving from the second floor to the third to sit at my new desk with the BA team.
But in all reality, my career transition into business analysis did not start with that conversation. And while at the time I saw this conversation as a lucky one, I had been unknowingly approaching my QA role as an aspiring business analyst.
In what follows I’ll share what I now understand to be the key activities that helped me demonstrate I was ready to be a business analyst.

#1: PARTICIPATING IN REQUIREMENTS REVIEW MEETINGS

I wasn’t immediately invited to attend requirements review meetings. But I was interested in learning more so I asked to be invited. Again. And Again. And Again. Finally I got myself on the invite list. I listened and learned and eventually started to speak up.
I found errors. I questioned details. I helped make the requirements better by being a critical consumer. From the perspective of the business analysts leading these meetings, I was probably erring on the side of being annoying. I have no doubt that this factored at least some degree into that hallway conversation.
I can just hear them scheming: Maybe if we get her on our side, she’ll stop pestering us in our meetings!
My advice to you: Get yourself invited to meetings, especially those related to requirements. Listen first, learn everything you can, and then make yourself as much of a pest as you dare!

#2: CREATING A NEW PROCESS

The particular role I was assigned to was one of those business activities that everyone realized was necessary but no one wanted to own. The type of testing I did had been bunted around from department to department for the last few years. The last person in my role had left after 6 months.
After being hired, I took ownership of the work and created a process. Over time I took things further by organizing related work done by other departments and automating part of the process. By the time I left things were running smoothly and my work could be transitioned to someone else in the department.
My advice to you: Take ownership of work that’s laden with solvable problems and that no one wants. You’ll face very little resistance and get noticed when things get better quickly.

#3: JUMPING INTO THE LIAISON ROLE

Testers tend to be liaisons. When a business stakeholder finds an error, it’s logical for someone from the test team to validate it, write it up, and submit it to the software team for fixing. There was another gap here in my organization and I jumped in to fill it. Before long I was talking to developers from different offices to explain the problems we were seeing and validating issues submitted from our user acceptance test process. 
My immature communication skills were put to the test and over time I learned how to communicate with developers as well as how to communicate technical information back to business stakeholders.
My advice to you: Jump into the fray and communicate. It doesn’t matter where the communication break-down is, if you can help fix it, you’ll demonstrate many BA competencies.

#4: DEVELOPING PRODUCT KNOWLEDGE

And while doing all of the above, I learned our products inside and out. I understood how the software was put together and what the key features of most of our products were. I also got to know all of the key business stakeholders.  This knowledge proved immensely valuable for my first business analyst role, although it was eventually career limiting and I think I was wise to leave it behind when I moved into a BA role in another organization.
My advice to you: If you know the business, learn the technology. If you know the technology, learn the business.  Then leverage the business, industry, or software domain experience you already have for your first business analyst role.

HINDSIGHT IS 20/20 BUT

Of course, at the time, I couldn’t have explained any of this. It’s taken a lot of self- analysis for the patterns to emerge. But that doesn’t mean the pattern wasn’t there. I just didn’t see it at the time.
Today, in my role as a coach and mentor for aspiring business analysts, I find that most of the mid-career professionals I talk to have similar patterns. They’ve been jumping in and demonstrating they have the mindset of a business analyst for a long, long time. And now they are waiting for their chance meeting in the hallway – for someone to give them their first shot. The thing is, once you see your own pattern, you are empowered to change the conversation and seek out the opportunities where you have the most chance of success.
I hope that by sharing my pattern, I help you see parts of your own.
What elements of my pattern resonate with you? In what other ways are you already demonstrating your capabilities as a business analyst?

Основные метрики БА (оценка качества работы)

three ba
What do you know about healthcare.gov, the United States' new online healthcare marketplace? No matter your political affiliation, you have to admit the launch of the website has been a giant fiasco.
When you visit the site, here are a few of the interesting things you might experience:
  1. A waiting line. Yes, just like the Department of Motor Vehicles —If the system is busy, you will be put into a queue and have to wait before you can begin the application process.
  2. No mobile capabilities, you need to use a desktop or a laptop for best results.
  3. Great advice like: “If you’ve created an account previously and have had problems with it, create a new account with a new user name, email address, and password. Be sure to clear your cookies and cache before you create your new account.”
I am fascinated by this very public debacle. My BA curiosity kicks in and I want to know:
  • Is it possible to have a smooth launch of a large, complex project with dozens of vendors trying to integrate project plans, requirements, designs, systems, etc.?
  • Who decided to launch a broken system and what was their rationale? Did anyone advocate for prototyping, a pilot program or a phased approach?
  • Is it faster and cheaper to launch a flawed system that needs several months of repairs or spend years trying to get the system right before launch?
  • What skills or tactics could we use to prevent similar problems with our projects?
As our friends at Healthcare.gov repair, update, and maintain the healthcare marketplace, it seems likely they are tracking hundreds of standard metrics like number of applicants, number enrolled, number of defects, system downtime, system error rates and response times.
These metrics are important and offer a great snapshot of the current state of the system. Trend lines for these metrics might help you with system troubleshooting or system risk management strategies.
However, these system-focused metrics don’t offer insight to improve project management or business analysis processes. They don’t help you assess the value of the BA role or track stakeholder satisfaction.
Though you may not work on complex, high-profile projects like healthcare.gov all BAs, need to evaluate and improve their processes. Here are three metrics that help BAs gauge their effectiveness, value and efficiency:

1) LAYERS OF DEFECTS

Can you imagine the size of the defect log for a system like healthcare.gov?
As time passes, most large systems develop layers of defects. A project goes live with 10 defects. The fixes for those defects result in more defects, and so on. How many layers deep are your defects and missed requirements issues?
When I work with organizations and BAs, I establish this metric by asking, “What originated this work?” for every project/enhancement/bug fix. I often hear one of the following:
  • “It’s from another enhancement that did not work out right.”
  • “It’s a new requirement for a project that went live last month.”
  • “This fixes a defect from a project that went live last year.”
  • “This addresses issues from another defect that we misunderstood.”
Then I ask again, “What originated this work?” I get the same responses. In many cases, I ask this question multiple times and find more than FIVE layers of defects hiding under each project.
I am finding that many organizations spend 80% of their time and money working on projects that are essentially rework—features and functionality that originated from missed requirements, misunderstood requirements, poorly tested requirements, etc.
This never-ending maintenance work indicates weakness in requirements processes. The rework hogs resources that would be better spent on innovative and strategic capabilities.
Tracking the layer of defects or the percentage of work being done to fix something broken or missed will help organizations gauge the health of their BA and even testing processes. BAs should use this metric to determine how to “get it right the first time” and free up resources that will offer more strategic value to stakeholders.
The balance to this metric is if you are expecting rework that is due to an agile approach where the rework is really learning and discovery and part of the process. In this case, rework for these projects should be removed from the metric.

2) BUSINESS SPONSOR’S PERCENT OF SUCCESSFUL PROJECTS

The definition of success varies from project to project. When I think about healthcare.gov I can imagine many different definitions of success:
  • Project team: “The system will be delivered on time and under budget.”
  • Consumers: “I want the system to be like the amazon.com of healthcare.”
  • Democratic Party Leaders: “I want the system to help us secure the presidency for 8 more years.”
  • Republican Party Leaders: “I want the system to fail miserably to help us secure the house, senate and presidency.”
  • Media: “I want the system to cause controversy so I have news to fill my 24-hour cycle.”
  • People who already have good healthcare insurance: “What system?”
BAs need to consider the definition of success from multiple perspectives. But whose perspective is most important?
When I ask leaders of PMO offices what percent of their projects are successful, they typically reply with an answer between 80-90 percent. When I ask the business sponsors the same question, time and time again I hear that only 20-30 percent of their projects are successful. Funny isn't it?
PMO: 80%-90% of our projects are successful
Business Sponsors: 20%-30% of our projects are successful
So, I ask how they measure it?
  • PMOs often measure by cost and schedule
  • Business sponsors measure by: "Did I get the value I expected based on the money I paid?” or "Was the project worth doing—is my life better?"
The BAs primary job is to identify and protect the sponsor’s value proposition, so the success metric needs to be driven by the sponsor’s perception of value. It’s critical to the requirements and BA role.
In many cases, BAs need to set time and budget aside and work based on value.
In some cases value will conflict with time and budget (Ahhh, yes, healthcare.gov!). When you recognize this conflict, you need to partner with the PM and/or sponsor on your concerns.
How can BAs drive this success percentage higher?
  • Understand what outcomes the sponsor values most and why.
  • Look for inconsistences between the sponsor’s expectations and the project team’s expectations?
  • Determine how to prevent inconsistencies.
  • Determine how to front-load the value—give your sponsor value ASAP.

3) REWORK CAUSED BY DIVING INTO DETAILS TOO SOON

OK. I am dragging you back to healthcare.gov one more time. I can’t begin to imagine the pressure analysts in this environment felt as they began to outline requirements! I can only assume that SME resources were extremely limited and tight deadlines caused BAs to choose a path: all details or no details.
Based on my experience, most analysts on intense, complex projects jump directly from a high-level business need or scope document to the nitty-gritty details. They feel crunched for time or have limited access to resources, so they gather and document as much detail as possible without leading stakeholders through the big picture.
This nose-dive to details seems efficient, but usually results in and unmanageable amount of rework as the project progresses:
  • You may have trouble completing deliverables as you need to re-write when you are still eliciting.
  • Traceability becomes complicated and gaps arise when detailed requirements do not have connections to higher-level features or processes.
  • Change control becomes a nightmare if you add design details to requirements documents. The design will change after your requirements document is base-lined, creating a change control headache for you with each update.
So ask yourself:
  • How much time do I spend rewriting or updating requirements?
  • Do I rewrite because of new things I learn during the elicitation process?
  • Do I rewrite because of enhancements and defects?
Then, improve your rework metrics:
  • Complete higher level modeling and requirements ahead of details.
  • Capture details informally, but don’t add them to official project documents until higher level models are approved.
  • Avoid managing traceability and change to a level of detailthat will change (i.e. screen designs)
Great BAs know how to guide their stakeholders through a progressive elicitation process that moves from concepts to details. They manage rework and change control by understanding when and how to offer details.
Which metrics do you find most valuable and why?


USER STORIES AND USE CASES - DON’T USE BOTH!

User Stories and Use Cases - Don’t Use Both!
We’re in Orlando for a working session as part of the Core Team building BABOK V3 and over dinner this evening we got to discussing the relationship between user stories and use cases (it wasn't the only thing we discussed, we are also a social group ;-)).
We noted with concern that there have been a number of recent discussions (client, articles, blogs and general industry) of using both User Stories and Use Cases at the same time in Agile projects. This seems to us (with general agreement around the table) to be both a waste of effort and actively against the Agile philosophy of doing the simplest thing that will work and deferring the detail until just ahead of when the component of the product will be built.
We would like to outline the basic differences, considerations and risks of using this approach. Even it is seems to be a trending topic, we would like to fill the gap in addressing beyond the trend and move towards the practically and risks of using Use Cases on Agile projects.

DIFFERENCES AND SIMILARITIES

So what are the differences and similarities between User Stories and Use Cases, and when do we recommend using the different tools?

USE CASES

A Use Case is "an end to end sequence of interactions between an actor and a system that yields a result of observable value to an actor, usually the instigating actor". Um, so what does that actually mean? Generally a Use Case (the textual description, not the stick figure diagram) is written as a flow or sequence of steps in the format
Actor does something
System does something
Actor does something else
System does something else
...
A Use Case is made up of one main flow and a number of alternate and/or exception flows some of which can branch back to the main flow.
Now Use Cases are by nature fairly detailed - they describe the steps in an activity and the points in the flow where things can change. To produce a useful (can be given to someone to build from) Use Case you need to define the set of interactions in quite a bit of detail, you need to understand what the business rules are that govern the activity, the options that the actor will have available to them when undertaking the activity, the ways things could go wrong and what bits of information are needed in the flow of interactions. To do this you need to spend quite a bit of time and effort analysing the activity and producing the document. This is BDUF - Big Design Up Front which is the antithesis of Agile.

USER STORIES

User Stories were originally a reaction to this big up front thinking. When Kent Beck definedeXtreme Programming (XP) he came up with the concept of a User story as a tool to support the iterative and incremental approach which is inherent in all the Agile methods. Mike Cohn went on to write a book which explained what User Stories are and how they are used in Agile projects. In addition to these two, Jeff Patton publicized the technique of Story Mapping to show how User Stories can be used to cover the breadth and depth of functionality needed in a product.
The key to writing good User Stories is to understand that the intent is not to provide the detail early on in a project, but to provide a framework where the detail can be added as it is needed, just enough and just in time. Drawing on the work of Beck, Cohn and Patton and many others the generally accepted approach to producing User Stories and using them to guide the development of the product follows a decomposition approach.
The decomposition comes in the form of a story map. The beginning of a story map is defining the Backbone stories – the key User Activities or Tasks which need to be accomplished to do the work of the product, the large discrete chunks of functionality which need to be delivered to be able to say we have solved the problem. These large chunks are often referred to as Epics (a big story ;-)), they equate to an elementary business process, something that is done in one place, at one time, by one person. Comparing this to Use Cases, this would be the result of the Use Case survey - a list of the discrete elements of the product, goals of the actors.
When building a story map, these Epics are normally laid out in a single row showing the logical sequence and handoffs between the steps in the process. Visually these Epics will be written on a different colour card to t e User Stories which will come later.
wick mar4 2Image: An Example of a Story Map – Epics in green along the top
Epics can be put in sequential order along the top (if sequence is appropriate, which it normally is).
The next step in the Story Map is to populate the map with the User Stories that fall under the Epics. Each User Story is a small, discrete piece of functionality that has value to some user of the product and is a decomposition of the Epic above. The most common format for writing User Stories is "as a (role) I want (feature or capability) so that (business value to be delivered)" -
  • As an internet banking customer I want to list my account balances so that I can understand my financial position.
  • As an internet banking customer I want to list transactions on an account so that I can check the detail
The three elements are important - knowing who the story is for helps ensure we build a useable product, what the functionality is that is needed and the value which will be derived from having that functionality enable us to make good priority decisions.
Priority based on business value is very important to defining User Stories. Knowing the value from a story enables us to make good decisions about the sequence of work - building the most important business value components first and getting feedback early rather than trying to build everything at once is inherent to Agile.
The User Stories are the orange cards in the image above.

PRIORITY AND SEQUENCE SHOWN IN THE MAP – IDENTIFY THE MVP

One of the benefits obtained by building a Story Map that shows the logical flow of activities (from Epic to Epic along the top) and the discrete elements of those Epics vertically down the page is the ability to clearly see both sequence and priority. Stories that are higher up on the map are more important (needed sooner) than those lower down.
The prioritisation and sequencing approach enable the discovery of the Minimum Viable Product(MVP) – those elements which need to be delivered to provide the opportunity to learn and adapt the product based on feedback from real customers/users. Finding the true essence of the product and getting that into the hands of real customers (probably just a small subset initially but enough to get feedback to validate the assumptions being made in the development of the product).
In a real-world internet banking example, the very first version of the product which was put in production had the ability to log in and to list balances and this version was used by the project team and a small group from within the bank. Having this “walking skeleton” built and put into production validated the architecture of the product, identified a number of unexpected challenges with the deployment process and gave the team feedback about their design philosophy which enabled them to make some significant changes when they were cheap and easy to do.

THE ELEMENTS OF A USER STORY

In his book, Mike Cohn says that a User Story has three C's - the Card, the Conversation and the Confirmation. The Card is the initial User Story, written on an index card or PostIt note. This is deliberately short and devoid of detail. The intent is to defer the detail until later in the project, just ahead of when this piece will be delivered. The detail is established through the second C - Conversations. As the project progresses and elements are delivered there will be a number of conversations that result in clarity of understanding about what is actually needed to deliver the value identified in the User Story.
The final C is Confirmation - these are the Acceptance Criteria for the User story - the details which will enable the customers and the technical team to agree that "if this story meets these criteria it is done". This is the detail which is all too often left out in bad Agile projects (“Tragile”). This detail needs to be agreed to, and it will contain whatever is needed to enable the delivery of this component of the product. The key difference between Agile and other approaches is when we produce this detail. In an Agile project this will be produced collaboratively with the customer representatives just ahead (a couple of hours to a couple of days) of when the piece will be built.
The most common format for these acceptance criteria is the <given><when><then> structure of Acceptance Test Driven Development. Each user story will have a number of acceptance criteria and may also have other elements which will help ensure the right thing is built - these could include screen mockups, technical notes, models such as class diagrams and whatever the team needs to enable them to deliver the business value.
Examples (for the list account balances user story)
Given the customer has one credit account and one savings account
When they have logged in successfully
Then the two accounts will be listed in account number order (Account no, Name, Balance, Available Funds)
Given the customer has no accounts
When they have logged in successfully
Then a message indicating that there are no accounts to show will be displayed
Given the customer has twenty one accounts
When they have logged in successfully
Then the first twenty accounts will be listed in account number order
And a Next Page option will be enabled
Given the customer has twenty five accounts
And they have logged in successfully
And they are on the first page of the list
When they activate the Next Page button
Then the list will be cleared
And the list will be populated with the last five accounts
And the Previous Page button will be enabled
And the Next Page button will be enabled
Gojko Adzic's book Specification By Example provides an excellent reference on how and when to produce acceptance criteria.
Ultimately the Acceptance Criteria will be proven through a set of test cases (ideally automated) which show that the product works as needed to deliver the business value.

REDUCE WASTE AND BE RESPONSIBLE

Again, the key to reducing waste and rework is to defer this detail until just ahead of when it is needed, rather than trying to clarify it all up front. Things will change over the life of the project and deferring the detail makes it cost-effective to adapt to this change.
However – taking this just-in-time approach is not an excuse for poor architecture or bad design. Early on in the product development it is important to set clear architectural guidelines, design principles and deal with what Philippe Kruchten calls the “Architecturally Significant Non-functional Requirements” – those aspects which will be extremely expensive and difficult to refactor later. Note however that we say “guidelines” and “principles” – don’t try to build the complete architecture up front, allow it to be emergent inside the boundaries of these clear guidelines.

TRACEABILITY IN USER STORIES

Hopefully it is clear from this description that User Stories actually have a powerful traceability mechanism built into the design of the technique.
There is a cascading one to many relationship:
  • A Role or Class of User derives value from one or many Epics
  • One Epic could have many User Stories
  • One User Story will eventually have many Acceptance Criteria
  • One Acceptance Criterion will have multiple Test Cases which prove it is working as expected
This traceability is enacted through the “so that” component of the user story, which ensures that every piece which is implemented has a direct relationship to the business value to be derived from that component/capability.

TIMING MAKES THE DIFFERENCE

The key is the timing - User Stories are deliberately abstract early on in a project and will evolve over time on a just-in-time and just-enough basis. This is because Agile projects expect and anticipate change and respond to this change by adapting the product to the evolving needs. More User Stories will be added, some will be dropped and our understanding of many will change as time progresses. The reality of today's business world is that change is inevitable, so trying to define the detail of all aspects of the upfront will result in lots of wasted effort and time as much of the work will need to be redone.
The Story Map is a fluid and changing tool – as stories are completed they are removed, new ones added and change is accepted as a normal part of the way we maximise the delivery of value to our stakeholders and the organisation for whom the product is being built.
The detailed Acceptance Criteria for any User Story will on be produced just ahead of when it will be delivered, maximizing the amount of work not done (one of the 12 principles of the Agile Manifesto)
One of the mistaken and dangerous myths of Agile is that “Agile projects have no documents” – the reality is Agile projects have the documentation that is needed to ensure value is delivered, and nothing more. The philosophy is to defer work until just ahead of when the output of that work is needed (a concept inherent in Lean thinking) and only do that work which is necessary to achieve the desired outcome (preventing waste from unnecessary effort and rework).
This is in stark contrast to Use Case thinking where the goal is to define in the various flows of the use case all the detail of the requirements up front. This approach will inevitably result in wasted effort as the use cases will have to be maintained and updated as the changing needs emerge. In agile we want to evolve the solution iteratively and incrementally as we learn based on feedback from real customers/users, not rework the documentation and requirements.

COULD YOU USE USE CASES INSTEAD OF USER STORIES IN AN AGILE PROJECT?

Theoretically Yes – you could indeed use Use Cases instead of User Stories to express the business needs. None of the Agile approaches are prescriptive about how you express the list of capabilities/features the product must contain (what Scrum calls the Product Backlog), however we see significant risks in trying to do so. Use Cases miss the mark on the “WHY”; they are not well suited to expressing the separate pieces of business value and supporting the iterative, incremental approach to developing the product – they tend to be monolithic and encourage an “all or nothing” way of thinking vs. an adaptive evolutionary style of learning and discovering the solution together through quick build and feedback loops.

COULD YOU BUILD USE CASES AFTER DEVELOPING AN AGILE SOLUTION TO DOCUMENT THE REQUIREMENTS AFTER THE FACT?

Theoretically, yes . . . however with this approach you have missed out on a critical technique in User Stories to guide conversations towards maximising value and minimising extra work throughout the development process.

RISKS AND DANGERS OF USE CASE THINKING IN AGILE PROJECTS

  • Compromised Innovation
    • Use Cases bring on a lot of detail before getting feedback on a built product. This cognitively brings user mind-sets into a predefined interaction and solution, negating the potential for further innovation. The exploration and learning aspect is compromised and focus goes from solving a need to perfecting an already defined solution.
  • Compromised Timelines:
    • Too much detail before building compromises the benefits of time in the Agile approach. Spending time detailing out Use Cases is spending time on what and how when we be should focusing on the why. Defer the what and how until just ahead of when it is needed
  • Compromised Value:
    • Use Cases confuse the role of Acceptance Criteria in User Stories and agile. Many teams are using Use Cases as an alternative to creating Acceptance Criteria for their User Stories. Acceptance Criteria evolve in levels of detail as builds iterate and evolve and more is learned together through the agile process. This learning process is where the value lies as the needs are quite unknown before starting.

CONCLUSION

Many teams embarking on their Agile journeys are finding comfort in techniques used in the past for requirements definition, particularly Use Cases. Use Cases resemble user stories in more detail, and User Stories were developed as a condensed technique to alleviate the lack of WHY in Use Cases and to alleviate too much detail too soon when using an Agile approach.
We believe that User Stories and Acceptance Criteria are the techniques aligned to deliver the benefits of the Agile approach and Use Cases compromise and put the benefits of the Agile approach at risk.
Teams thinking about using Use Cases should strongly consider looking at the methods and evolutions of defining Acceptance Criteria (especially the <given><when><then> model) with many scenarios and levels of detail that evolve as feedback through the iterative cycle and delivering increments of the product as it evolves. Keeping with user stories (Including story maps & epics) along with well defined and evolving acceptance criteria will meet the goal of leveraging the benefits of agile without putting timeline and value at risk.
Don't forget to leave your comments below.
About the Authors
shane hastieShane Hastie
Shane is the Chief Knowledge Engineer and Agile Practice Lead for Software Education, a training and consulting organisation based in Australia and New Zealand, working all around the world. 
Shane teaches courses and consults around business analysis and agile and is passionate about bringing the two communities together.
He is a member of the board of the Agile Alliance, and is the lead editor in the Process and Practices community on InfoQ.com
He can be reached at shaneh@softed.com and on twitter as @shanehastie
awickAngela Wick, CBAP, PMP
Ms. Wick is passionate about inspiring innovative BAs and is a leader in the business analysis field. Angela is a trainer of business analysis, project management and in bringing innovation and creativity to these roles. She enjoys working with traditional and agile teams, and especially in preparing teams for agile in their organization. She also consults with organizations in building BACoEs, BA practices, BA Career Models, and BA competencies. Angela is a lead contributor to the BABOK v3 and the IIBA Competency Model. Angela is also a monthly blogger on BaTimes.com
Angela can be reached at Angela@angelawick.com and on twitter @WickAng
Both Shane and Angela are Core Team members for the IIBA team building version 3 of the Business Analysis Body of Knowledge (BABOK)

Каким будет бизнес-анализ в ближайшем будущем

awhittenberger feb4It is customary that at the start of a new year people reflect upon the past and look into the future. I believe you will agree some people are better at both activities than others. In fact, recently Julian Sammy, Head of Research and Innovation at the IIBA® did both. In this recentarticle he takes a look at predictions that he and other members of the Senior Leadership Team of the IIBA® made in 2011 about what 2013 will look like. He then takes a look at what he thinks 2016 will look like for the business analysis profession.
So I will jump on the band wagon (because it is a popular thing to do and because I have something to say) and give you a look at what I think the business world will look like for business analysis professionals for the next couple years. Trends take time to develop and take hold so I will take a multi-year look into the future, and why I believe Julian looked three years into the future. You will see my analysis has a heavy tendency toward the tactical IT Business Analyst role because, well let’s face it, that is what I know best; and it is still the largest business analysis role in existence today. Maybe one of my trends should be a prediction of how that will change soon. Ok, I got my crystal ball out, are you ready?

TREND 1 – AGILE IS HERE TO STAY

There are those that still believe that agile is a fad, soon to pass. Sorry, anything that has been here for 10+ years is not a fad. Many fashions (remember bell bottom jeans) are a fad; agile is here to stay. Although acceptance of agile methodologies may stagnate a bit, many of the tools and techniques of agile will find their way into IT project work in many companies; further developing the hybrid project approach.
Resistance of agile acceptance will come from companies that “tried” agile and failed. Some will “try” again or for the first time, some will abstain; yet some will realize you don’t “try” agile, you decide to give it your “all” (all the organizational support it needs) or don’t bother. Further resistance will come from the idea of a 100% dedicated team to one project seems an unwise use of resources in today’s business environment; and agile professionals will struggle to answer that concern to the satisfaction of business management. Also, lack of truly effective Agile Coaches will hinder the willingness of companies to give it a go. This will become a valuable consulting role; if you’re looking to drive your career into a role of the future, consider this one.

TREND 2 – BUSINESS AGILITY WILL DEMAND GREATER COLLABORATION ON IT PROJECT TEAMS

Greater demand for quicker IT project delivery times will continue to crunch project schedules and resources. The trend of doing more with less will continue. This will demand greater collaboration among the project team. The BA Team, QA Team and PM will give way to the IT project team; with the BA as the liaison to the business stakeholder. They will all merge into the “core” project team with the responsibility to deliver full functionality, on-time and on-budget. The “we vs. them” mentality will slightly diminish between business and IT, but it will drastically diminish among the IT team itself; gaining greater synergies for a more effective working environment.

TREND 3 – RESURGENCE OF STRATEGIC ENTERPRISE ANALYSIS

Continued dissatisfaction with dismal project success rates will bring about a resurgence of the strategic business analysis role. This role demands a whole different skill set than the traditional IT business analyst. Skills to do market research, capability gap analysis, SWOT analysis, benchmarking and feasibility studies will become in greater demand. The skill to create a bullet-proof business case describing the business value of IT projects will become paramount. This role will work with project approval committees to define for them the business value and risks of projects under review, thereby giving necessary support to project portfolio management.

TREND 4 – THE VALUE OF PRODUCT VISION GIVES RISE TO THE PRODUCT OWNER AND PRODUCT MANAGER ROLES

Product Vision will gain wider acceptance as many will come to the realization that this means more than maintaining future enhancement and feature lists, and product roadmaps. System users will become greater source of future direction of product vision of systems development. Yes, these roles exist today, but primarily in large enterprises. We will see this role gain acceptance in Small to Medium Sized (SMB) companies. Even in large enterprises these roles will gain greater recognition with clear career paths. As these roles gain higher profile recognition, people in the role realize that their value comes in communicating that product vision to all business and IT stakeholders so that all have a shared vision of the future product. For business and IT professionals looking to drive their career, this is another good direction for the future.
awhittenberger feb4 2

TREND 5 – REQUIREMENTS COLLABORATION TOOLS INTEGRATES SOCIAL MEDIA AND THE DESKTOP

With greater emphasis being put on business agility and greater collaboration on the IT project team, requirements management tools providers will jump on the opportunity, as these tools make the transition to requirements collaboration tools. Transparency of requirements during their development will become enhanced as other members of the project team, including business stakeholders will have that visibility. The requirements tool itself will become the accepted communication tool among the team, allowing them to interactively communicate about the requirements being developed. Yes, some tool providers have already integrated this capability, but organizations will integrate this capability into its business and IT processes, again due to gaining business agility.
The great enhancement in coming years in this area is that these tools will integrate to peoples’ desktop. Imagine being in conversation with a group and needing to schedule a meeting to continue the conversation. Imagine being able to scan everybody’s calendar and having a few suggested dates and times that everyone can make it to the meeting. Upon agreement of a good date and time, imagine everyone in the conversation receiving a calendar meeting invitation moments later; and all this happens right there in one tool. Now imagine that the conversation included vendor personnel who use Lotus Notes calendar while you use Microsoft Outlook; and some participants use Google calendar. Each recipient receives the proper invitation for their calendar.
Finally, the business analyst doesn’t rely on Microsoft Office as their primary requirements tool. Yes, some large, and SMBs, have been past this stage for a few years. However, this trend will become much more wide spread as more and more companies invest in these requirements tools; and those that have had them for a while will invest in the next generation of these tools to gain the benefits of the increased collaboration for their project teams.

TREND 6 – THE BUSINESS ANALYST AS PROXY FOR THE BUSINESS STAKEHOLDER

In organizations where the Business Analyst reports to IT management and work on IT projects, the company will recognize the value of putting a Business Analyst on the business side to work as a proxy for key business stakeholder(s); this will be an additional BA role within the organization. This will free up the business stakeholder(s) to run the business while their proxy takes on the responsibility of working on IT projects to bring about the change that the key business stakeholder desires. This, of course, means that the business analyst has to not only share the product vision of the business stakeholder, but must understand the ‘what’ and the ‘why’ of all the business change requests with great clarity.

TREND 7 – BUSINESSES INCREASES ITS INVESTMENT IN TRAINING

Changes in the business analysis environment will increase at even greater velocity. That along with the increase need of collaboration with a lot of different roles within the business organization will cause business analysts to develop new skill sets. Businesses will continue to see the value in investing in the development of its people, but will look for greater bang for their buck when investing in training for business analysts and other project professionals. Training that take the people away from work for shorter time, allow more people to attend the training for lower cost will see increased utilization over the traditional classroom training class.
Education providers in the space will scramble to beef up their virtual classroom offerings with excellent content, while continuing to offer the traditional classroom training for those organizations that value the in-person interaction with the instructor and other students, and are willing to pay for it.
Local IIBA® chapter professional development days (PDD) will help fill this need as well. PDDs like WI BADD (Wisconsin), I-BADD (Iowa) and SO BARC (Cincinnati, OH) will continue to gain attendance over the next few years. Chapter’s that don’t yet offer this service will see the value and begin to provide this service to their business community. Likewise, local business education providers that have any capability in this space will beef up their business analysis offerings to leverage the opportunity of this trend.
awhittenberger feb4 3.jpg

TREND 8 – BUSINESS ANALYSIS JOBS WILL CONTINUE TO BE IN ABUNDANCE

With organizations putting focus on business analysis roles, additional roles will prop in those organizations. With the diverse skill set necessary to be effective, business analysis jobs will be in abundance. We will see an influx of people flowing into the business analysis profession from other professions including project management, quality assurance, business and operations. Now the flow will be both ways as people move from business analysis to project management and the other professions, but the flow into business analysis will be greater. Even with that inward flow it will not keep up with the demand for good business analysts, creating even greater demand for training.

TREND 9 – WE WILL SEE A RESURGENCE OF BUSINESS ANALYSIS CENTERS OF EXCELLENCE

With all these changes in the business analysis space, organizations will also look inward for training for their business analysts and give them opportunities to learn from each other. Business Analysis Communities of Practice (BACoP) and Centers of Excellence (BACoE) showed rapid growth in 2011 and 2012, and stagnated a little in 2013. Organizations will see their value in training and incorporating best practices across lines of business. They will help ensure the same level of service across lines of business. We will see a slight uptake in BACoPs and

TREND 10 – BUSINESS ANALYST AND PROJECT MANAGER ROLES WILL CONTINUE TO OVERLAY

As the Project Management Institute (PMI®) continues to expand its teachings into areas like stakeholder management and collecting requirements they will lose focus on their core purpose and core audience. Businesses will realize that requirements, and stakeholders, need more than just management or documentation. They will realize the different skill set and focus (business focus, not project focus) needed to effectively develop requirements from the business and project management will give way to a project leadership mentality. Businesses will see that dual project leadership roles, one focused on the project and one focused on the solution, has greater probability to lead to increased project success rates.
The practitioners that perform these roles, through their professionalism, will find ways to work together for the benefit of the organization no matter the teachings of the PMI® or IIBA®. As for the IIBA® and PMI®; just like David and Goliath, David will
So that’s how I see the next couple of years for business analysis, and related, professionals. Now let’s see how I stack up to the ESI International’s predictions for the
So which do you agree with? What would you add or subtract from the list?
Don't forget to leave your comments below.

Как быстро оценить бизнес (нишу проекта)

Бизнес-аналитику иногда приходится оценивать варианты реализации того или иного проекта. Можно сделать для себя заготовочку (как в видео) и проводить оценку решений (ниш, бизнеса) за 5-10 минут.


Взято отсюда: https://www.youtube.com/watch?v=7wl-5SxyhOY

Простая бизнес-логика в непростой картинке

На одном сайте в разделе "логические головоломки" нашла схему про логику бизнеса. Тот, кто разместил схему в головоломки был прав. Тот, кто назвал схему "Упрощенная" явно лукавил.


Жизнь проекта одной картинкой

Как начать творить? Профессиональные советы

Не ждите, пока разберетесь в себе

Если бы я не решился «начать творить», пока не разберусь в себе, пока не пойму, кто я и зачем живу, то до сих пор занимался бы самокопанием, а не делом. По своему опыту знаю, что понять собственную природу человек способен, только делая что-то, выполняя какую-то работу.
Вам может быть страшно начать. Это нормально. Есть вполне реальная черта характера, ярко выраженная у многих образованных людей. Называется она «синдром самозванца». Вот его медицинское определение: «синдром самозванца — психологическое явление, при котором человек неспособен принять собственные достижения». Это значит, что вы чувствуете себя мошенником, думаете, что действуете экспромтом, и не имеете ни малейшего понятия о цели своих действий.
Знаете что? Все чувствуют это. Спросите любого, кто создал хоть что-то действительно креативное, и он вам честно ответит, что не представляет, откуда приходят правильные решения. Он просто делает свое дело. Каждый день.

Пишите о том, что любите

Каждый начинающий писатель однажды задает вопрос: «Что мне написать?» И стандартный ответ таков: «Пишите о том, что знаете». Этот совет приводит к появлению ужасных историй, в которых не происходит ничего замечательного.
Мы занимаемся искусством, потому что любим искусство. Рисуем в определенном стиле, потому что вдохновляемся теми, кто создавал подобные работы. По сути, любое художественное произведение — это «фан-проза».
И поэтому лучший совет — пишите не о том, что знаете, а о том, что вам нравится. Пишите такие истории, которые сами любите, которые сами хотели бы читать. Данный принцип применим и к личной жизни, и к карьере: всякий раз, когда вы не знаете, что делать дальше, просто спросите себя: «Какая история была бы лучше этой?»
Подумайте о своих любимых произведениях и их авторах — ваших героях. Что они упустили? Чего не сделали? Что могли бы сделать лучше? Если они еще живы, над чем могли бы работать сегодня? Если бы все ваши любимые творческие личности собрались вместе и занялись каким-то одним делом под вашим руководством, что могло бы получиться?
Пойдите и сделайте это.
Итак, мой манифест таков: нарисуйте картину, которую хотели бы увидеть; начните бизнес, которым хотели бы управлять; сыграйте музыку, которую хотели бы услышать; напишите книгу, которую хотели бы прочесть; придумайте товары, которыми хотели бы пользоваться, — делайте именно то дело, которое хотели бы видеть сделанным.

Не жалейте времени на безделье

За время своей недолгой карьеры я научился одному: по-настоящему успешными бывают только побочные проекты. В данном случае я имею в виду то, чем вы занимаетесь от безделья. Так, для развлечения. Но именно это и получается хорошо. И тогда начинается настоящая магия.
Не жалейте времени на безделье. Как-то один из моих коллег сказал: «Когда я слишком занят, я глупею». А разве это не так? Творческим людям бывает полезно просто посидеть сложа руки. Лучшие мысли приходят в мою голову как раз в те минуты, когда я ничем не занят, потому-то, наверное, я никогда не отдаю рубашки в химчистку. Мне нравится гладить их самому — это так скучно, что в голову почти всегда приходят отличные идеи. Так что, когда у вас закончатся идеи, помойте посуду. Отправьтесь в действительно долгую прогулку. Сядьте и смотрите в одну точку столько, сколько сможете. Как сказала художница Майра Кальман, «откладывая в сторону работу, я фокусирую свой ум».
Не жалейте времени на безделье. Гуляйте по незнакомым местам. Бродите просто так. Хорошо не знать, куда приведет дорога.

Уезжайте из дома

В определенный момент, как только появляется такая возможность, каждому из нас приходится уходить из дома. Всегда можно вернуться, но как минимум один раз нужно уйти.
В привычном окружении мозг чувствует себя слишком комфортно. Нужно встряхнуться, вывести его из привычного равновесного состояния. Например, полезно провести некоторое время в другом месте, среди людей, которые живут другой жизнью. Во время путешествия мир кажется иным, а когда мир кажется иным, наш мозг работает интенсивнее.
Можно рассмотреть множество факторов, помогающих творческому процессу, — и все они зависят от вашего вкуса. Например, лично я считаю, что творчеству помогает плохая погода. Не хочется выходить на улицу, поэтому сидишь дома и работаешь. Когда я жил в Кливленде, то очень много успевал сделать за время холодных зимних месяцев. Здесь, в Техасе, всю работу я делаю палящим летом. (Зима в Кливленде и лето в Техасе имеют примерно одинаковую продолжительность — по полгода.)
Очень помогает, если живешь среди интересных людей, причем они совсем не обязательно должны заниматься тем же делом, что и ты сам. Я испытывал почти кровосмесительное чувство, общаясь исключительно с писателями и художниками, поэтому мне нравится, что в Остине живет такое количество режиссеров, музыкантов и компьютерщиков. Ах да, еще кухня. Кухня должна быть хорошей. Нужно найти место, которое будет подпитывать вас — творчески, социально, духовно... ну и в буквальном смысле этого слова.
Тем не менее, даже если у вас появится новый дом, его нужно будет периодически покидать. И в какой-то момент, возможно, даже переехать снова. Радует, что в наше время связь со многими друзьями при этом не прерывается, ведь они остаются там, где и были, — в интернете.

Держитесь поближе к талантливым людям

Вы можете быть хорошим настолько, насколько хороши люди, окружающие вас. В цифровую эпоху это означает, что нужно общаться в интернете только с лучшими людьми — с теми, кто гораздо умнее и талантливее вас; с людьми, которые делают что-то действительно очень интересное. Внимательно следите за тем, о чем они говорят, что делают, чем увлекаются.
Актер и кинорежиссер Харольд Рамис, который людям моего поколения известен по роли Игона в фильме «Охотники за привидениями», как-то поделился своим правилом успеха: «Найдите самого талантливого человека в комнате и, если это не вы, держитесь рядом с ним. Следуйте за ним повсюду. Старайтесь быть полезным ему». Рамису повезло: в его «комнате» самым талантливым оказался его друг Билл Мюррей.
А если однажды вдруг окажется, что самый талантливый человек в комнате — это вы, придется искать другую комнату.

Не бойтесь быть скучным

Я скучный человек, работаю с девяти до пяти, живу в тихом пригороде с женой и собакой. Тот полный романтики образ гениального творца, помешанного на наркотиках, болтающегося где попало и спящего со всеми подряд, давно вышел из моды. Это для суперменов и тех, кто хочет умереть молодым. Суть проста: творчество требует громадного количества энергии. Растрачивая ее на ерунду, вы ничего не оставите на творчество.
Лучше всего исходить из того, что какое-то время вы еще поживете. (Именно по этой причине Патти Смит советовала молодым художникам все-таки посещать стоматолога.) Регулярно завтракать. Делать зарядку. Много гулять. Много спать.
Нил Янг пел: «Лучше сгореть, чем раствориться». А я говорю, что лучше гореть медленно и дожить до внуков.

Не бросайте основную работу

Истина заключается в том, что, даже если вам повезет и вы станете зарабатывать на жизнь любимым делом, это может случиться не сразу. А до тех пор вам нужна какая-то работа.
Основная работа — это деньги, связь с миром и определенный режим. Свобода от финансового прессинга означает свободу творческого выражения.
Благодаря основной работе вы находитесь среди людей. Пользуйтесь этим — учитесь у них, крадите у них. Я старался находить такую работу, которая давала новые знания и навыки для моего собственного творческого процесса. Например, работая библиотекарем, я научился проводить исследования; работая веб-дизайнером, узнал, как создают сайты; работая копирайтером, понял, как продавать при помощи слов.
В основной работе хуже всего то, что она отнимает время, но компенсируется этот недостаток наличием графика, в котором вполне реально выделить определенное время и для творчества. Наличие и соблюдение графика может быть даже важнее, чем большое количество свободного времени. Бездеятельность убивает творчество.
Хитрость состоит в том, чтобы найти такую основную работу, которая сносно оплачивается, не вызывает тошноту и оставляет достаточно сил для творчества в свободное время. Хорошую работу такого типа найти нелегко, но можно.

Хорошо делайте свою работу и делитесь ею с людьми

Я получаю множество сообщений от молодых людей с одним и тем же вопросом: «Как мне добиться известности?». Если бы я знал секретную формулу известности, то сообщил бы ее вам. Но мне знакома только одна, причем не особенно секретная: хорошо делать свою работу и делиться ею с людьми.
Моя формула состоит из двух частей. Первая — это «хорошо делать свою работу», что чрезвычайно тяжело. И коротких путей тут нет. Трудитесь каждый день. Знайте, что неудачи неизбежны. Ошибайтесь. Исправляйте ошибки. Последовать второму совету — «делитесь ею с людьми» — было сложно еще лет десять назад. Теперь же нет ничего проще: размещайте свои произведения в интернете.
Когда я говорю об этом людям, меня спрашивают: «В чем секрет интернета?» Шаг первый: удивитесь чему-нибудь. Шаг второй: пригласите других удивиться вместе с вами.
Удивляйтесь тому, чему еще никто не удивлялся. Если всех интересуют яблоки, заинтересуйтесь апельсинами. Чем более открыто вы будете делиться своей страстью, тем более близкой будет казаться людям ваша работа. Художник не фокусник. Никто вас не накажет за то, что вы поделитесь своими секретами.
«Не беспокойтесь о том, что кто-то украдет ваши идеи. Даже если они и правда хороши, вам придется заталкивать их людям в глотку» Говард Эйкен, пионер компьютеростроения.