Таким образом я поднял еще одну книгу по разработке программного обеспечения и начал читать. Я не был в состоянии закончить это, потому что это дает мне такую головную боль. Каждые несколько страниц я получаю непреодолимое убеждение хлопнуть мой лоб. По этой норме я собираюсь получить сотрясение главой три. Every few pages I get the irresistible urge to slap my forehead. At this rate, I'm going to get a concussion by chapter three.

Anyways, этот парень продолжает о требованиях: Как не наличие надлежащих требований вызывает проекты быть по бюджету и позади списка, как расползающийся эффект плохо написанного кода приводит к неуправляемому проектному списку и деморализованным разработчикам, yadda, yadda, yadda. Нет, действительно? No, really?

И его предписание - то, что кто - то выписывает требования и заставляет все заинтересованные лица заканчивать на них. Конечно, нет только одного вида требования - noooooo! - есть многие вид требований. Так же как пользовательские требования, там являются деловыми требованиями и проектируют требование и thingajig требования и.... Я не знаю, но много большого количества напуганных требований и черт возьми, если менеджер проектов получит все описанные требования и закончит всеми заинтересованными лицами, то Аллилуйя, это будет ОДНИМ проектом, который закончится вовремя и на бюджете. Если только те глупые менеджеры проектов могли бы описать хороший набор документов требования.... бьются! - there are many kind of requirements. As well as user requirements, there are business requirements and design requirement and thingajig requirements and .... I don't know, but lots of lots of funky requirements and gosh, if the project manager gets all the requirements written up and signed off by all the stakeholders, then hallelujah, this will be the ONE project that will finish on-time and on-budget. If only those stupid project managers could write up a good set of requirement documents....thump!

Жаль, который был моей головой, поражающей стол. Я думаю, что я потерял сознание в течение нескольких секунд.

Хорошо, давайте попытаемся опровергнуть эту точку зрения, которая, кажется, обычная мудрость с одним исключением, где бронированные письменные требования - правило: Встроенные системы. В основном, действительно трудно изменить чип после того, как это было разработано. Duh. Basically, it's really hard to change a chip after it's been designed. Duh.

Для в значительной степени всей другой работы разработки программного обеспечения это - хорошая идея записать ряд предварительных требований. И затем распечатайте их. Но распечатайте их на очень мягкой бумаге, которая может использоваться в наименьшей комнате дома. Поскольку в очень короткий период времени, это - единственная комната, куда тот листок бумаги собирается быть полезным. But print them out on very soft paper that can be used in the smallest room of the house. Because in a very short period of time, that's the only room where that piece of paper is going to be useful.

Есть две главных причины почему, одно очевидное & одно тонкое. Я начну с очевидного: давайте притворимся, что Вы - клиент. Вы подписали контракт с домом разработки программного обеспечения, чтобы построить изящную программу, которая делает кое-что. Вы согласились заплатить деньги. В большинстве случаев, Вы платите много денег. Вы поместили свою подпись на листке бумаги кое для чего, что не существует в подарке. Вы также крайне знаете, что то, когда эта часть программного обеспечения создана, если это, не оправдывает надежды Ваших заинтересованных лиц, они собираются сообщить об этом. И как времена выпуск программного обеспечения встречают 100 % ожиданий клиента? Let's pretend you are the customer. You have signed a contract with a software development house to build a nifty program that does something. You have agreed to pay money. In most cases, you are paying a lot of money. You have put your signature on a piece of paper for something that doesn't exist in the present. You are also painfully aware that when this piece of software is created, if it's does not meet the expectations of your stakeholders, they are going to let you know about it. And how times does a software release meet 100% of the customer's expectations?

Теперь, после подписания листка бумаги для того, что многие в Вашей организации рассматривают непристойной суммой денег, определенный промежуток времени протекает, и Вы заставляете другой листок бумаги читать, с названием, заявляя, что это - проект/пользователь case/business/whatever документ требований. Вы прочитываете документ. Это смотрит хорошо. Есть место для Вашей подписи. Возможно Вы подписываете это. Возможно Вы отсылаете высказывание электронной почты назад, что Вы подписали листок бумаги за энные миллионы долларов, и это - единственный листок бумаги, должен подписаться, когда-либо. Но давайте притворимся, что Вы заканчиваете на докторе требований. Это означает, что Вы, клиент, бросили право когда-либо связаться, сообщаете или ворчите развитие, подходят к новым особенностям и/или требованиям? It looks okay. There's a space for your signature. Maybe you sign it. Maybe you send back an e-mail saying you signed a piece of paper for umpteenth millions of dollars, and that's the only piece of paper need to sign, ever. But let's pretend you sign off on the requirements doc. Does this mean that you, the customer, have given up the right to ever contact, communicate or nag the development team with new features and/or requirements?

Нет. Никогда. Когда-либо. Нет никакого клиента, который когда-либо существовал с незапамятных времен, который не будет непрерывно приставать к развитию для новых особенностей прямо до момента выпуска и после. Добраться. Используемый. К. Это. Ever. There is no customer that has ever existed since the beginning of time that will not continually pester the development for new features right up to the moment of release and after. Get. Used. To. It.

Таким образом урок для любого менеджера проектов не, проводят слишком много времени при составлении докторов требования. Несомненно, ударьте по ним быстро, и я подразумеваю, ударяют по ним, но если, чудеса чудес, клиент отсылает назад хорошо и законченный документ, даже не думайте, что Ваша работа закончена. Забава только что началась. The fun has just started.

Это поднимает мой второй пункт о падении в ловушку требований документации: получение всех требований супертрудно. В большинстве случаев, это невозможно. Не даже клиент, и клиент клиента, могут дать Вам 100 % требований. In most cases, it's impossible. Not even the customer, and the customer of the customer, can give you 100% of the requirements.

Слушайте, это походит на движение к фан-клубу Джулии Робертс и высказывание: "Мы хотим сделать любовный роман с Джулией и Брэдом Питтом. Они влюбляются, они борются & распад, и затем они составляют и влюбляются снова. В конце кино, всех в аудитории, потому что кино было настолько замечательно. Вот подлинник кино. Вы можете уверить нас, что после наблюдения этого кино, Вы достигнете своего hankie?" They fall in love, they fight & break-up, and then they make up and fall in love again. At the end of the movie, everybody in the audience because the movie was so wonderful. Here is the script of the movie. Can you assure us that after seeing this movie, you'll reach for your hankie?"

Позвольте мне пересчитывать пример от реального мира (я изменил некоторые из деталей, чтобы защитить невинного): у Одного из клиента Крео было немного технологии печати, которая бежала с набором программного обеспечения, развитым в начале 1990-ых. У Крео есть некоторое программное обеспечение перед прессой, развитое приблизительно десятилетие спустя, который весьма выше. Однако, были некоторые характерные особенности, которые были необходимы, чтобы быть развитыми и добавленными к набору программного обеспечения Крео. Creo has some pre-press software developed about a decade later that is vastly superior. However, there were some unique features that were needed to be developed and added to Creo's software suite.

Руководство проектом для клиента координировалось из главного офиса в середине США, тогда как технология печати базировалась в заводской площадке около Западного побережья. Я полетел вниз на завод, чтобы хвастаться набором программного обеспечения Крео и требованиями захвата. Сделал представление, прилетел обратно к Ванкуверу. Несколько недель спустя, мы получаем дипломатическое сообщение от главного офиса, что возможно все требования не были захвачены. Таким образом я лечу вниз снова. Я также договариваюсь загрузить набор программного обеспечения Крео на сервере и отправленный к заводской площадке как loaner. На сей раз, во время представления, у них есть свой суперпользователь, свой администратор системы под рукой. Я удачлив, что клиент достаточно умен, чтобы вывести их пользователей к представлению, чтобы критиковать набор. Суперпользователь идет глубоко на мне. Это означает, что она бурит землю, много уровней к некоторым действительно затеняют (мне), но важный (для них) деловое требование, которое не находится в нашем наборе программного обеспечения. Я обещал развить те особенности с некоторыми из SMEs Крео (эксперты по предмету), когда я возвращаюсь к офису. Did the presentation, flew back to Vancouver. A couple of weeks later, we get the diplomatic message from head office that perhaps all the requirements have not been captured. So I fly down again. I also arrange to have Creo's software suite loaded on a server and shipped to the plant site as a loaner. This time, during the presentation, they have their super-user, their system administrator on hand. I am lucky that the customer is smart enough to get their users out to the presentation to critique the suite. The super-user goes deep on me. That means she drills down many levels to some really obscure (to me) but important (for them) business requirement that is not in our software suite. I promised to follow up on those features with some of Creo's SMEs (subject matter experts) when I get back to the office.

Тем временем, сервер с программным обеспечением Крео прибывает локальный с местной полевой репутацией, чтобы сделать, устанавливают и предварительное обучение. Я также принимаю меры, чтобы тренер добился локального посещения клиента неделю спустя. Я предварительно информирую тренера, чтобы наблюдать & сообщить для любых новых требований. Шесть недель спустя, я посылаю другого тренера. Приблизительно пять месяцев прошли начиная с моего первого посещения набора клиента. Наконец, суперпользователь в состоянии ясно сформулировать требования, чтобы завод нуждался представителю Крео, который является также SME в той специфической подтеме. Таким образом мы захватили требования, и мы передаем их команде развития, и мы получаем сообщение назад, что ни одно из требований не невозможно выполнить, потребуется приблизительно три месяца, чтобы проникнуть в следующую модернизацию. Конец истории. I pre-brief the trainer to watch & report for any new requirements. Six weeks later, I send another trainer. About five months have passed since my first visit to the customer suite. Finally, the super-user is able to articulate the requirements that the plant needs to the Creo representative who is also a SME in that particular sub-topic. So we get the requirements captured and we pass them on to the development team and we get the message back that none of the requirements are impossible to fulfill, it will take about three months to roll into the next upgrade. End of story.

Теперь, отметьте, что в этом случае учатся:
1. Клиент был искушенным, понимая, что мы должны были сделать, чтобы суперпользователь провел много времени, играя с нашим программным обеспечением, таким образом она могла обнаружить то, что отсутствовало.
2. У нас было много времени. Получение надлежащих требований заняло пять месяцев. Кодирование требований заняло две недели (административный груз вращения новых модернизаций в набор программного обеспечения, считавший в течение других 2.5 месяцев). Getting the proper requirements took five months. Coding the requirements took two weeks (the administrative load of rolling new upgrades into the software suite accounted for the other 2.5 months).
3. Это было модификацией существующего ранее набора программного обеспечения. Мы не дарили клиенту "чистый листок бумаги." We were not presenting the customer with a "blank piece of paper."
4. Бизнес стоил достаточно, чтобы послать loaner сервер с программным обеспечением на завод И иметь в общей сложности пять отдельных посещений завода (две поездки менеджером проектов, один местным представителем, и два тренерами).

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

Теговый как: 166, 186, 83 166, 186, 83