Кароткая гісторыя SharePoint (З пункту гледжання адноснай якія прыязджаюць)

Увага: Гэты артыкул была першапачаткова размешчана на www.endusersharepoint.com. I forgot to post it to my own blog 🙂

SharePoint развівалася шмат, так як першых дзён, як свайго роду тэхналогія інкубацыі ў Microsoft –гэта Evolved амаль як у фільме жахаў, дзе стварэнне вар'яцкага навукоўца бярэ на сябе сваю ўласную жыццё, breaking free of its creator’s expectations and rules. The technical evolution is obvious – the WSS 3.0 аб'ектная мадэль багацей і складаней, чым WSS 2.0, which was itself an improvement over earlier versions. The next version will no doubt show tremendous improvement over 3.0. From an End User’s perspective, аднак, Эвалюцыя SharePoint з'яўляецца яшчэ больш значным.

У першыя дні, SharePoint didn’t offer much to End Users. They would have their usual functionality requirements, work with IT to define them well and implement a solution. IT would use SharePoint to solve the problem. The product wasn’t very accessible to End Users. I’ve thought threw a few analogies, but I decided to stick Venn Diagrams to show what I mean. When Microsoft first released SharePoint to the world as a commercial offering, вынікала, адносна традыцыйнай мадэлі з канчатковым карыстальнікам <-> IT relationship. A lot of End Users, мець зносіны і не працаваць з вельмі невялікім лікам ІТ пастаўляць рашэнні, якія вырашэння бізнес-задач:

Агульная прадметнай вобласці, для якой SharePoint з'яўляецца прыдатнай платформай дастаўкі малая (especially compared to today’s SharePoint. End Users and IT worked in a more classic arrangement with IT: вызначыць патрабаванні да яе, чакаць яго робяць сваю працу за фіранкай і прыняць пастаўку тавару канчатковага прадукту.

Як SharePoint эвалюцыянавалі, каб 2.0 свет (WSS 2.0 і SharePoint Portal Server), several things happened. Першы, the “problem domain” increased in size. By problem domain, I mean the kinds of business problems for which SharePoint could be a viable solution. Напрыклад, вы не вельмі моцна перажываць з-за сур'ёзнай рэалізацыі пошуку рашэння ў асяроддзі SharePoint да SPS (і нават тады, гэта не было так добра, як гэта павінна было быць). У той жа час, Канчатковыя карыстальнікі маюць беспрэцэдэнтную магчымасць не толькі вызначыць, but also implement their own solutions with little or no IT support.

The 3.0 платформа (WSS і MOSS) maintained and increased that momentum. The problem domain is enormous as compared to the 2.0 платформа. Virtually every department in a company, пачынаючы ад здароўя і бяспекі вытворчасці дэпартаментаў маркетынгу, ад продажаў кантроль якасці - яны могуць знайсці добрае прымяненне для SharePoint (і гэта не той выпадак, заціраньня круглую затычку ў квадратнае адтуліну). У той жа час, the platform empowers even more End Users to implement their own business solutions. I try to capture that with this diagram:

This has proven to be both a potent and frustrating mixture. The 3.0 platform turns previously stable roles on their heads. Suddenly, Канчатковым карыстальнікам эфектыўна суддзя, журы і кат бізнес-аналітыка, application architect and developer for their own business solutions. This gets to the heart of the problem I’m writing about. But before I dive into that, давайце разгледзім слон у пасуднай краме.

Узіраючыся ў крыштальны шар

Як будзе SharePoint 2010 ўплывае на гэтую мадэль? Will it be incremental or revolutionary? Will more, менш або прыкладна такое ж колькасць канчатковых карыстальнікаў аказваюцца ўпаўнаважаны ствараць рашэнні ў SharePoint 2010? Will SharePoint 2010’s problem domain expand even further or will it just refine and streamline what it already offers in WSS 3.0 / MOSS?

Там дастаткова інфармацыі "там", каб з упэўненасцю сказаць, што агульны адказ:

• The problem domain is going to dramatically expand.
• Канчатковыя карыстальнікі апынуцца нават больш магчымасцяў, чым раней.

The Venn Diagram would be larger than this page and cause some IT Pros and CxO’s to reach for their Pepto.

I believe it’s going to be a tremendous opportunity for companies to do some truly transformational things.

Няма Быкі ў маім краме Кітаі!

Гэта гучыць выдатна, але з майго пункту гледжання ў якасці кансультанта SharePoint і пакласці сабе ў абутак ІТ-мэнэджара, I see this vision. I own a China shop with beautiful plates, крышталь, і г.д. (мой асяроддзі SharePoint). I’ve rented a space, I’ve purchased my inventory and laid it all out the way I like it. I’m not quite ready to open, але ў чаканні, I look at the door to see if my customers are lining up and I notice an actual bull out there. I look more closely and I actually see два bulls and even a wolf. Then I notice that there are some sheep. Sheep are так дрэнны, але яны, можа быць замаскіраваны ваўкі? I don’t want bulls in my china shop!

Сітуацыя становіцца яшчэ горш! When I rented the space, I couldn’t believe how nice it was. Wide and open, ўзрушаючая выгодамі, very reasonable price. Аднак, цяпер я зразумеў, што шырокія адкрытыя прасторы і велізарныя дзверы проста ідэальна разлічана на быка, каб прыйсці і ён бадзяўся па спустошыць мой Кітаі.

Я вылучаю гэтую аналогію занадта далёка, вядома. End Users are not bulls (большасць з іх, у любым выпадку) і ІТ-аддзелаў ня (або, канешне, не павінны) view their user community with that kind of suspicion. Аднак, ёсць такі дасканалай сутыкнення адбываюцца ўжо ў 3.0 platform that I expect will only get worse in SP 2010. SharePoint already empowers and encourages End Users to define and implement their own solutions.

Гэта выдатна, і ўсё, але справа ў тым, што яна па-ранейшаму вельмі тэхнічны прадукт і ўсё яшчэ заклікае да энергічным выгляд аналізу бізнес-патрабаванняў, design and general planning and management that technical projects require to be successful. These are not the kind of skills that a lot of End Users have in their bag of tricks, especially when the focus is on a technical product like SharePoint.

I’ve given this a lot of thought over the last year or so and I don’t see any easy answer. It really boils down to education and training. I think that SP 2010 збіраецца змяніць гульню крыху, і яно будзе гуляць па-іншаму і ў запаволеным тэмпе, як кампаніі выкаціць іх SP 2010 рашэнняў на 2010 and beyond. In order to succeed, End Users will need to transform themselves and get a little IT religion. They’ll need to learn a little bit about proper requirements
analysis. They will need some design documentation that clearly identifies business process workflow, напрыклад. They need to understand fundamental concepts like CRUD (ствараць, абнаўлення і выдалення), Інтэрнэт Dev / Test / QA / прадуктаў асяроддзі і як выкарыстоўваць гэтую інфраструктуру для правільнага разгортвання рашэнняў, якія жывуць добра і доўга выгіб (не парушаць) ў адказ на змены ў арганізацыі.

У бліжэйшыя тыдні, Я планую, каб паспрабаваць забяспечыць некаторыя з маіх уласных новых ідэй, а таксама спасылка на вялікую работу, праведзеную многімі іншымі аўтарамі (на www.endusersharepoint.com і ў іншым месцы) so that interested End Users can learn that old time IT religion. Keep tuned.

</канец>

Падпісацца на мой блог.

Выконвайце за мной на Twitter у http://www.twitter.com/pagalvin

[Увага: Гэты артыкул Папярочны адпраўлены ў Канчатковага карыстальніка SharePoint тут: http://www.endusersharepoint.com/2009/09/09/sharepoint-a-case-study-in-ask-the-expert/]

Часам, калі вы працуеце ў якасці кансультанта (як прафесія, або ў кансультатыўнай ролі ў вашай кампаніі), you find yourself living in an Onion story. The Onion has a series of articles called “Ask an [эксперт] аб [некаторыя праблемы]". This follows the famous “Dear Abby” format where a concerned person is asking for personal advice. The onion’s “expert”, аднак, is so focused on his/her area of expertise and current problems that the expert ignores the question entirely and rambles on about his area of expertise. As consultants, we need to keep that in mind all the time and avoid falling into that trap. It’s classically described like this – “when you use a hammer all day long to solve your problems, everything starts to look like a nail.” We professional consultants are always on guard against that kind of thing, але мы ўступаем у кантакт з людзьмі, якія з'яўляюцца сур'ёзнымі прафесіяналамі ў сваёй уласнай ролі, but are not consultants. They don’t have the same need or training to do otherwise.

На мінулым тыдні, Я напісаў аб адным з кліентаў маёй кампаніі і ў цяперашні час праекце we have to enable high quality collaboration between various eye doctors in the US and Canada performing clinical research on rare disease. In addition to leveraging core SharePoint features to enable that collaboration, we’re also working an expense submission and approval process. It’s complicated because we have so many actors:

• Жменька людзей у практыку розных лекараў, якія могуць увайсці выдаткі на лініі.
  • Ёсць больш 40 лекараў практыкі.
  • У нейкі практыкі, Лекар выкарыстоўвае сістэму непасрэдна.
  • На шматлікіх практык, Супрацоўнікі лекара выкарыстоўвае сістэму непасрэдна.
• Фінансавага адміністратара (хто працуе на маіх прамых кліентаў) які разглядае выдаткі на дакладнасць і рэлевантнасць, зацвярджэнні або пазбаўляючы іх на арганізацыйным узроўні.
• A 3rd party accounts payable group. These people pay all of the bills for out client, not just bills coming out of the rare disease study.

The Accounts Payable group has been a challenge. Working with them yesterday reminded me of the Onion series. In my role as business consultant, Я растлумачыў неабходнасць крэдыторскай запазычанасці кампаніі:

• Клінічныя даследаванні сайтаў (лекараў практыкі) Даследаванне панесці выдаткі, звязаныя з.
• They log onto the “web site” and enter their expenses using an online form. У гэтым выпадку, the “web site” is hosted with SharePoint and the expenses are entered into an InfoPath form. Expense receipts are scanned, загружаны і мацуецца непасрэдна да форме.
• Аўтаматызаваны працэс працоўны працэс імкнецца узгодненымі з адпаведнымі фінансавымі адміністратарам.
• Вы, dear 3rd party AP company – please review and approve or deny this expense. I’ll send it to you any way that you want (у межах разумнага).На дадзены момант у абмеркаванні, I don’t really care how it needs to be bundled. I want to work with the AP group to understand what they need and want.

Калі я растлумачыў неабходнасць, 3. Партыі глыбока пагрузіцца ў іх унутраныя фетыш жаргоне аб працэсах зацвярджэння выдаткаў, Oracle коды, віцэ-прэзідэнты подпісы, 90 дзень сваю чаргу абыходныя, і г.д.. And panic. I shouldn’t forget about the panic. One of the bed rock requirements of the consulting profession is to learn how to communicate with people like that who are themselves not trained or necessarily feel a need to do the same. Among other things, it’s one of the best parts of being a consultant. You get to enter a world populated with business people with completely different perspectives. I imagine it’s a little bit like entering the mind of a serial killer, выключэннем таго, што вы не разбурана да жыцця пасля вопыту (though entering the mind of an AP manager isn’t a walk in the park 🙂 [гл. заўвагу ніжэй важнай ***] ).

One of the great things about our technical world as SharePoint people is that we have ready-made answers to many of the very valid concerns that people such as my AP contact have. Is it secure? How do I know that the expense was properly vetted? Can I, у якасці канчатковага плацельшчыка, убачыць усе дэталі расходу? How do I do that? What if I look at those details and don’t approve of them? Can I reject them? What happens if the organization changes and the original approver is no longer around? Can we easily change the process to reflect changes in the system? Ці магу я вярнуцца да гэтага выдаткі на год пазней, калі і калі я атрымліваю правераны і павінны абараняць аплаты?

Як людзі SharePoint, we can see how to answer those questions. In my client’s case, мы адказваем ім больш ці менш, як гэта:

• InfoPath формы для дазволу сайтам запісваць свае выдаткі і прадстаўляць іх на зацвярджэнне.
• Сайты могуць вярнуцца на сайт, каб паглядзець стан іх справаздачу аб выдатках у любы час.
• Як адбываюцца значныя падзеі (e.g. кошт зацверджаны і прадстаўлены да аплаце), Сістэма актыўна паведамляе іх па электроннай пошце.
• Сістэма паведамляе фінансавыя адміністратарам адзін раз, як справаздачу быў прадстаўлены на зацвярджэнне.
• Фінансавы адміністратар ўхваляе або адхіляе запыт.
• Пасля зацвярджэння, кошт захутаныя ў электронны ліст і адправілі ў трэцюю арганізацыю плацельшчыка партыі.
• 3. Партыі плацельшчыка мае ўсю інфармацыю, яны павінны азнаёміцца ​​рахунак і можа атрымаць доступ да асяроддзя SharePoint, каб паглыбіцца ў дэталі (у першую чаргу гісторыі аўдыту для праверкі «ісціна» выдаткаў).
• 3rd party payer can approve or reject the payment using their own internal process. They record that outcome back in the SharePoint site (які выклікае апавяшчэнне па электроннай пошце адпаведным людзям).
• У будучыні, было б нядрэнна, каб выразаць гэтую STILLY працэсу электроннай пошце і замест карміць за кошт інфармацыю непасрэдна ў іх сістэме.

У заключэнне, ёсць стыль жыцця тут, што я апісваю з пункту гледжання прафесійнага кансультанта гледжання, but which applies almost equally to full time employees in a BA and/or power user role. Work patiently with the experts in your company and extract the core business requirements as best you can. With a deep understanding of SharePoint features and functions to draw upon, амаль заўсёды, Вы зможаце адказаць на праблемы і прапанаваць шляхі паляпшэння працоўнага дня кожнага Узмацняючы асноўныя функцыі SharePoint.

***Важнае заўвага: I really don’t mean to compare AP people to serial killers. Аднак, I could probably name some AP pro’s who have probably wished they could get a restraining order against me stalking them and asking over and over again. “Where’s my check?” “Where’s my check?” “Where’s my check?"

</канец>

Падпісацца на мой блог.

Выконвайце за мной на Twitter у http://www.twitter.com/pagalvin

[Увага: this blog post is cross posted at Mark Miller’s site here: HTTP://www.endusersharepoint.com/?p=1897]

One of my company’s more unusual clients is a New York City doctor who is a leader in his particular field of medicine (eye care). Like many doctors, he has a strong interest in research. He wanted to do some research on a rare eye disorder that affects a relatively small number of people in the U.S. and Canada. I don’t know the number, but it’s really too small for a large pharmaceutical company to invest its own private funds with an eye toward eventual commercial success. I’m sure large pharma’s do some amount of research into rare diseases, but I believe that the U.S. government is probably the largest source of funding. Як і ўсе, resources are scarce. Many doctors across the country want to perform research and trials. У выніку, there’s more than a little competition for that government funding. This is where my company and SharePoint enter the picture.

The fundamental idea is that a master organization will recruit other doctors across the country and enlist those doctors’ practices in a particular research study. These individual practices must sign up with the master organization and then, subsequently, sign up for a particular study. The relationships look like this:

• One master organization.
• Many different doctor’s practices sign up with the master organization.
• The master organization obtains funding for individual studies. At the outset, there is just the one study on a specific rare eye disease although we’re already ramping up for another study.
• Individual doctors’ practices sign up for specific studies. A specific practice could sign up for one or multiple studies.

The master organization itself is broken down into groups:

• Executive committee
• Steering committee
• Individual study committees
• Адміністрацыя
• іншыя

У рэшце рэшт, when a specific doctor’s practice signs up to participate in a study, they need to provide professionals to fulfill a variety of roles:

• Investigators (including a primary investigator, normally a doctor, along with one or more additional investigators)
• Coordinators
• Technicians
• Grants administrators
• іншыя

The above roles have very specific and highly proscribed roles that vary by study. I won’t get into more detail here, but if you’re interested, leave a comment or напішыце мне.

And now I can answer the question, SharePoint – What’s it good for? The answer – it’s really good for this scenario.

This intro is already longer than I expected, so I’ll summarize the vital role that SharePoint plays in the solution and dive into details in a future article (if you can’t wait, напішыце мне or leave a comment and I’ll be happy to discuss and maybe even try to do a demo). We are leveraging a wide array of SharePoint features to support this concept:

• Sites for committees, individual roles (coordinator sites, investigator sites, і г.д.).
• Security to make sure that different practices don’t see other practices’ data.
• InfoPath forms services for online form entry. This is a particularly big win. Нармальна, these difficult forms are printed, mailed to the practices, filled out and mailed back. The advantages to the online forms are obvious. They do introduce some complexities (licensing and human) but that’s another story.
• Out of the box web parts, like announcements (when does committee [X] meet?) and meeting work spaces.
• Forms based authentication in combination with a CodePlex tool to provide self-registration and password forget features.
• Customized lists and list views for visibility into study activities which simply aren’t possible with pure paper and pencil approaches.

With the exception of the forms based authentication module and a handful of InfoPath forms, this project is using nearly all out of the box SharePoint functionality.

Before I wrap up this min-case study, I want to point out something very important – no on involved with this project (aside from my company of course) has any idea that a thing called “SharePoint” is playing such a fundamental technical role. Nearly all of my end users view this as “the web site.” Our client values us because we’re solving their business problem. SharePoint is a great technical blob of goodness, but done right, that’s irrelevant to end users. They need a problem solved, not a wonderful blob of technology.

</канец>

Падпісацца на мой блог.

Выконвайце за мной на Twitter у http://www.twitter.com/pagalvin

Ці гэта толькі ў мяне? I’ve received three or four calls at my house since late September looking for SharePoint work. I’m used to the email solicitations, but these phone calls are a little unnerving. I haven’t had an updated resume on a job site I(like Monster pr Dice) since almost two years ago exactly. And back then, my resume was all about BizTalk and MS CRM. That’s the only place my phone number appears on line anywhere, наколькі я ведаю.

</канец>

Падпісацца на мой блог.

Выконвайце за мной на Twitter у http://www.twitter.com/pagalvin

Заканчэнне думкі з гэтай нагоды інакш сумнай артыкула кажа на карысць таго, каб праблемы мы часта сутыкаемся ў тэхнічным супольнасці:

"Such dreary developments, Чакаецца з упэўненасцю, Неабходна мець філасофску."

This puts me in mind of one of the presentations I gave at the SharePoint Best Practices conference last month. I was describing how to get "great" бізнес-патрабаванні і хтосьці з залы спытаў, у рэчаіснасці, what to do if circumstances are such that it’s impossible to get great requirements. Напрыклад, культуру дадзенай кампаніі ставіць яго перад патрабаваннямі збіральнікаў / бізнес-аналітыка, preventing direct communication with end users. This is a serious impediment to obtaining great business requirements. My answer was "walk away." I’m not a big humorist, so I was surprised at how funny this was to the audience. Аднак, I’m serious about this. If you can’t get good requirements, you can be certain that a dreary outcome will result. Who wants that? I’m a consultant, так што гэта больш рэалістычна (Хоць жудасна балюча і рэзкае) for me to walk away. Аднак, калі вы замацаваліся ў кампаніі і не жадаюць, ці не можа, сыходзіць, Джордж (for once 🙂 ) паказвае шлях.

</канец>

Падпісацца на мой блог.

Выконвайце за мной на Twitter у http://www.twitter.com/pagalvin

Як часта гэта здарыцца з вамі? I’m sitting at my laptop, чытанне блогаў, рэагаванне на паведамленні на форумах, 2 копіі Visual Studio адкрыты і VPN'd да іншага сервера са сваім Visual Studio + 15 вокны браўзэра (Звычайны дзень) і хто-то імя Саманты (мая жонка, па-відаць) кажа мне,, "We have be there in 30 хвілін. Get dressed."

Я ўстаю ў здранцвенні, блукаць вакол дома збянтэжана, атрымаць у машыну і наступнае, што я ведаю,, Я на вечарыне з півам у руцэ і хто-то пытаецца мяне,, "So, Чым Вы зарабляеце сабе на жыццё?"

Гэтыя размовы не ідуць добра.

Мне: "Ahh … Я архітэктар рашэнняў для EMC."

Безназоўная твар: пусты выпарніка

Мне: "I work with a product called SharePoint … гэта ад Microsoft."

NP: "Aha! Я чуў, што кампанія! What is SharePoint?"

Мне: "Umm … гэта робіць супрацоўніцтва … людзі выкарыстоўваюць яго для абмену інфармацыяй … Гэта платформа для будаўніцтва Бізнес-Соль…"

NP: Вочы шклення.

Мне: "I’m a programmer."

NP: "Aha! I know people in my company that do programming! When I was in high school, Я гуляў з BASIC."

І з той часткай размовы па, мы звяртаемся да чаму-то лягчэй гаварыць пра, як і палітыка.

Любы сыход апісаць, як яны справіцца з гэтай?

</канец>

Падпісацца на мой блог.

Я быў у гэтых класах апошнія два тыдні, і адна рэч, якая мяне дзівіць тое, што ёсць шмат ўдумлівы, разумныя людзі, якія працуюць на SharePoint (ў якасці кансультантаў або ІТ-персанал) хто не блог, шчабятаць, таксама вядома пра грамадскія форумы, як MSDN форума або SharePoint універсітэта, падтрымліваць Facebook або LinkedIn профіляў, і г.д.. They are pure information consumers. Not bad, проста цікава.

</канец>

Падпісацца на мой блог.

Кучу гадоў таму, my boss asked me to train some users on a product called Results. Results is an end user reporting tool. It’s roughly analogous to SQL Server Reporting Service or Crystal. At the time, ён быў распрацаваны для працы на зялёнай трубы (e.g. Wyse 50 тэрмінал) connected to a Unix box via telnet.

My default answer to any question that starts with "Can you … " is "Yes" а вось дзе ўсе непрыемнасці пачаліся.

Кліент быў хімічная кампанія ў паўднёвай Каліфорніі і было прыкладна загорнуты маштабнае ўкараненне ERP на аснове Кампаніі QAD MFG/PRO. The implementation plan now called for training power end users on the Results product.

I wasn’t a big user of this tool and had certainly never trained anyone before. Аднак, Я правёў шэраг іншых навучальных класах і быў хуткі на нагах, so I was not too worried. Dennis, рэальны поўны працоўны дзень Вынікі інструктара, had given me his training material. Азіраючыся на гэта цяпер, it’s really quite absurd. I didn’t know the product well, had never been formally trained on it and had certainly never taught it. What business did I have training anyone on it?

Усё ўскладняецца тэхнічна, I was asked to go and meet someone in Chicago as part of a pre-sales engagement along the way. The plan was to fly out of New Jersey, еду ў Чыкага, meet for an hour with prospect and then continue on to California.

Добра, I got to Chicago and the sales guy on my team had made some mistake and never confirmed the meeting. Так, I showed up and the prospect wasn’t there. Awesome. I pack up and leave and continue on to CA. Somewhere during this process, Я даведаўся, што кліент вучыцца менш 24 hours before my arrival that "Paul Galvin" вучыць класа, not Dennis. The client loves Dennis. They want to know "who is this Paul Galvin person?" "Why should we trust him?" "Why should we pay for him?" Dennis obviously didn’t subscribe to my "даюць дрэнныя навіны рана" philosophy. Awesome.

Я прыязджаю ў аэрапорт і па некаторых прычынах неверагодна дурное, I had checked my luggage. I made it to LAX but my luggage did not. Для мяне, страты багажу вельмі шмат, як перажывае сем стадый гора. Eventually I make it to the hotel, без багажу, які стаміўся, галодныя і насіць маю (да гэтага часу, вельмі скамечаны) business suit. It takes a long time to travel from Newark — to O’Hare — кліенту — Вярнуцца да О'Хейру — і, нарэшце, LAX.

Я, нарэшце, знайсці сябе седзячы ў гасцінічным нумары, жавалі бар Snickers, exhausted and trying to drum up the energy to scan through the training material again so that I won’t look like a complete ass in front of the class. This was a bit of a low point for me at the time.

Я прачнуўся на наступны дзень, did my best to smooth out my suit so that I didn’t look like Willy Loman on a bad day and headed on over to the client. As is so often the case, асабіста яна была добрая, polite and very pleasant. This stood in stark contrast to her extremely angry emails/voicemails from the previous day. She leads me about 3 miles through building after building to a sectioned off area in a giant chemical warehouse where we will conduct the class for the next three days. The 15 або 20 студэнты павольна збірацца, most them still expecting Dennis.

Я заўсёды пачынаю з майго навучальныя класы, уводзячы сябе, giving some background and writing my contact information on the white board. As I’m saying, "Good morning, my name is Paul Galvin", Я пішу маё імя, email and phone number up on the white board in big letters so that everyone can see it clearly. I address the fact that I’m replacing Dennis and I assure them that I am a suitable replacement, і г.д.. I have everyone briefly tell me their name and what they want to achieve out of the class so that I can tailor things to their specific requirements as I go along. The usual stuff.

We wrap that up and fire up the projector. I go to erase my contact info and … I had written it in permanent marker. I was so embarrassed. In my mind’s eye, гэта выглядала так: There is this "Paul Galvin" чалавек, last minute replacement for our beloved Dennis. He’s wearing a crumpled up business suit and unshaven. He has just written his name huge letters on our white board in перманентны маркер. What a sight!

Усё скончылася шчасліва, аднак. This was a chemical company, у рэшце рэшт. A grizzled veteran employee pulled something off the shelf and, верагодна, у парушэнне правілаў па ахове навакольнага асяроддзя, cleared the board. I managed to stay 1/2 day ahead of the class throughout the course and they gave me a good review in the end. This cemented my "pinch hitter" reputation at my company. My luggage arrived the first day, так што я быў нашмат больш прэзентабельна другі і трэці дні.

Паколькі я браў чырвоных вачэй дадому, I was contemplating "lessons learned". There was plenty to contemplate. Communication is key. Tell clients about changes in plan. Don’t ever check your luggage at the airport if you can possibly avoid it. Bring spare "stuff" in case you do check your luggage and it doens’t make it. I think the most important lesson I learned, аднак, гэта было: заўсёды правяраць маркер ў левым ніжнім куце дошкі, перш чым пісаць, вялізнымі літарамі, "Paul Galvin".

</канец>

Due to some oddball United Airlines flights I took in the mid 90’s, Я неяк трапіў з прапановай пераўтварыць "нявыкарыстаныя мілі" into about a dozen free magazine subscriptions. That is how I ended up subscribing to Scientific American magazine.

Паколькі праграмнае забеспячэнне / кансалтынг людзей, we encounter many difficult business requirements in our career. Most the time, мы любім задавальненне гэтых патрэбаў і на самай справе, it’s probably why we think this career is the best in the world. I occasionally wonder just what in the world would I have done with myself if I had been born at any other time in history. How terrible would it be to miss out on the kinds of work I get to do now, ў гэты час і месца ў сусветнай гісторыі? Я думаю, што: даволі жудасна.

На працягу многіх гадоў, some of the requirements I’ve faced have been extremely challenging to meet. Complex SharePoint stuff, Стварэнне вэб-апрацоўкі базы, заснаваныя на не-вэб-чыстыя тэхналогіі, complex BizTalk orchestrations and the like. We can all (з надзеяй) глядзім з гонарам таму на нашай кар'еры і сказаць, "yeah, гэта быў нялёгкі для вырашэння адной, але ў рэшце рэшт я забіваў, што сукін сын!" А яшчэ лепш, нават больш цікавым і вясёлым праблемы чакаюць.

Я асабіста думаю, што маё рэзюмэ, ў гэтых адносінах, даволі глыбокай, і я даволі ганаруся гэтым (хоць я ведаю, мая жонка ніколі не зразумее гэтага 1/20th). But this week, Я чытаў артыкул пра Вялікі адронны коллайдер in my Scientific American magazine and had one of those rare humbling moments where I realized that despite my "giant" статус у пэўных колах ці, як глыбока я думаю, што мой вопыт і, there are real giants in completely different worlds.

The people on the LHC team have some really thorny issues to manage. Consider the Moon. I don’t really think much about the Moon (хоць я быў вельмі падазроным пра гэта, так як я даведаўся, што гэта запаволенне кручэння Зямлі, якая не можа быць добрай рэччу для нас, людзей, у доўгатэрміновай перспектыве). Але, the LHC team does have to worry. LHC’s measuring devices are so sensitive that they are affected by the Moon’s (Зямля-запаволенне кручэння і ў канчатковым рахунку-забойства-ўсё-жыццё) gravity. That’s a heck of a requirement to meet — вырабляць правільныя вымярэння, нягледзячы на ​​ўмяшанне Месяца.

Я абдумваў гэтае пытанне, калі я прачытаў гэтую прапанову: "The first level will receive and analyze data from only a subset of all the detector’s components, from which it can pick out promising events based on isolated factors such as whether an energetic muon was spotted flying out at a large angle from the beam axis." Really … ? I don’t play in that kind of sandbox and never will.

У наступны раз я з некаторымі сябрамі, Я збіраюся падняць тост за добрых людзей, якія працуюць на LHC, hope they don’t successfully weigh the Higgs boson particle and curse the Moon. I suggest you do the same. It will be quite the toast 🙂

</канец>