Удовлетворение, тем не менее, не приходило. Наоборот, к неработающим кнопкам перемотки добавились раздражающие паузы в воспроизведении музыки. Я уж начал было подумывать о покупке нового Bluetooth/USB-адаптера, софт к которому включал бы все необходимые для корректного общения с устройством профили (мое ПО, при попытке легального приобретения в онлайне, предупреждало о несовместимости с устройством и — отказывалось продаваться), но для очистки совести решил сперва переустановить имеющийся софт. Переустановка BlueSoleil начинается с удаления предыдущей версии и приглашения к перезагрузке. На сей раз, по какому-то наитию, я проверил, насколько «чисто» прошло удаление, и с удивлением обнаружил в списке устройств некое Bluetooth Audio-устройство, видимо, унаследованное от предыдущей версии BlueSoleil. После его удаления и переустановки софта все кнопки ожили, и раздражающие дефекты пропали. А я спросил себя, чего же не хватает в Bluetooth-медальоне? Ответ прост: мультисвязности, то есть одновременного нахождения «на связи» не только с компьютером, как сейчас, но и с сотовым телефоном. Тем более что места на медальоне — для переключения и отчетливой индикации режимов — с запасом!
КНИГИ:
Разом нас богато! Оранжевая и синяя книги об искусстве фотографии
Автор: Сергей Вильянов
Широкое распространение недорогих цифровых камер заставило очень многих людей почувствовать себя фотографами, и особенно хорошо это заметили девушки, разместившие анкеты на расплодившихся серверах онлайн-знакомств. По сведениям, полученным от моих знакомых дам, гениальные фотохудожники — третий по распространенности типаж на соответствующих сайтах, чаще которого встречаются только водители грузовиков турецкого происхождения и отечественные мачо, чей словарный запас исчерпывается фразами «привет, как дела?» и «пачиму не отвечаеш?».
Правда, при расспросах знакомящихся гениев цифрового фото очень быстро выясняется, что из техники у них только «мыльница» долларов за триста, а позировать они предлагают у них дома, на старом продавленном диване, накрытом несвежей простыней. И, разумеется, полностью обнаженной — ведь именно ради таких фотосессий и покупалась чудо-камера! И ничего, что за год владения ею согласилась на съемки только одна мамина подруга, да и та в итоге отказалась расстаться перед объективом с надетым «для антуражу» ватником…
Шутки шутками, но даже в такой небогатой стране, как наша, цифровиков разного уровня продается по полмиллиона в квартал, и продажи неуклонно растут. Соответственно появляется все больше людей, которым нужно чуть больше, чем просто фотографировать семейные торжества, методично забивая винчестер компьютера жуткими наборами из красных глаз, высветленных до неузнаваемости встроенной вспышкой лиц и «бочек», характерных для дешевого «цифромыла» даже на небольшом оптическом зуме. Наевшись всего этого, многие решают узнать о фотографии побольше — например, разобраться в ручных настройках камеры или освоить основы композиции. Да и в таинственном Photoshop’e неплохо бы научиться работать, ведь все вокруг говорят, что в нем можно «вытянуть» даже самый неудачный кадр! Человек кидается в книжный магазин и обмирает, потому что перед ним выстраиваются целые шеренги корешков с «вкусными» названиями, вроде «Самого полного самоучителя фотографа-профессионала» или «Библии цифровой фотографии»[Кстати, я на днях углядел в киоске около дома толстую книжку «Фотографируем мобильником». Надо будет в следующий раз не пожалеть 200 рублей и купить этот шедевр для коллекции]. И все бы хорошо, но ведь регулярно практикующему и действительно талантливому фотографу обычно некогда писать книжки. Да и пером он зачастую владеет хуже, чем объективом. Поэтому выбирать, как правило, приходится между «импортной» литературой, качество содержимого и перевода которой весьма разнородно, и отечественными продуктами, написанными якобы известными на весь мир фотографами, которых в приличных изданиях не пускали дальше курилки даже во времена пика карьеры, пришедшегося на годы хрущевского волюнтаризма. Очень весело читать этих бодрых старичков: нет-нет да и ввернут про неоспоримые преимущества пленочных камер, в сравнении с которыми все эти цифровые извращения ну словно плотник супротив столяра.
Зная это, я с большим подозрением взялся за «Оранжевую книгу цифровой фотографии» Дмитрия Рудакова, однако уже страниц через двадцать ваш покорный слуга расслабился и дочитал ее с интересом и не без удовольствия. И все потому, что автор, в отличие от многих коллег, не стал пытаться написать всеобъемлющий серьезный труд. В интервью, найденном на просторах Рунета, Рудаков клеймит бездарных переводчиков, превращающих даже лучшие западные учебники в унылое чтиво, и с горечью отмечает, что за последние годы отечественные авторы разучились писать хорошую учебную литературу. Поэтому, выбрав вольный и местами панибратский стиль, заставляющий вспомнить, к примеру, Андрея Белянина[Автор книжных сериалов «Тайный сыск царя Гороха», «Моя жена — ведьма» и др.], Дмитрий за год написал неплохое пособие, в котором субъективные высказывания общего характера неплохо сочетаются с массой полезных для «продолжающего» фотографа советов. Прочитав «Оранжевую книгу», вы действительно научитесь правильно компоновать кадр и читать гистограмму, оцените преимущества формата RAW над всеми остальными и овладеете основными приемами работы с «цифровыми негативами», поймете разницу между «цифромылом» и зеркалкой, и с помощью Photoshop’а научитесь устранять типичные недостатки любительских снимков, заодно подчеркивая их достоинства. Полезен и раздел, посвященный печати фотографий в домашних условиях, хотя несколько смущает нежелание автора познакомить нас со свежими моделями принтеров, упоминание только широкоформатных моделей (A3+) и откровенная приверженность брэнду Epson. Нет, никто не сомневается, что принтеры Epson прекрасно печатают фотографии, но, наверное, и в продуктовых линейках HP с Canon можно найти что-то достойное. А еще у всей троицы очень по-разному выглядит интерфейс драйверов, на чем стоило бы остановиться поподробнее… Заключительные разделы посвящены наложению разнообразных эффектов в Adobe Photoshop, и если вы уже отдали за эту полезную программу положенные $600, не пожалейте и 700 рублей на «Оранжевую книгу цифровой фотографии» — получите удовольствие.
По сути, у книги всего один серьезный недостаток: ее автор работает только на «макинтошах», так что скриншоты выглядят очень… непривычно. Нет, я, конечно, понимаю, что Adobe Photoshop CS2 для «маков» отличается от своей «писишной» реинкарнации гораздо меньше, чем, к примеру, Apple QuickTime, но вероятность небольших нестыковок исключать нельзя. Да и все видеоуроки на прилагаемом к книге CD записаны в упомянутом формате QuickTime, хотя дистрибутив последнего никто на диск положить не догадался. То-то обрадуются обладатели «писюков» без доступа в Интернет…
Но в целом, повторюсь, книга хороша, и если вас не смущает слегка завышенная цена, можете смело приобрести ее в личное пользование.
К написанию второй части этого обзора, посвященной книге «Фотография. Школа мастерства» петербуржца Александра Беленького, я не мог подступиться довольно долго. И все потому, что никак не мог найти в ней ярко выраженных недостатков — на глаза попадались сплошные достоинства. Книга-то, по сути, о том же самом и для той же аудитории «продолжающих», но «замах» у Беленького поменьше — в «Фотографии» вы не найдете ни уроков Photoshop’а, ни советов по выбору бумаги для печати. Зато обо всем остальном написано подробно, а главное — понятно. Начав с устройства фотоаппаратов (как цифровых, так и пленочных) и основных понятий фотографии, он постепенно переходит к выбору сюжета и композиции, установке света, многообразию объективов, наконец — к покупке вспышки и технике работы с ней. Разобравшись с азами, автор переходит к нюансам съемки портретов, пейзажей, турпоездок, спортивных мероприятий, ночных городов, спектаклей и концертов, а заканчивается все описанием способов надежно сохранить фотоархив и сделать его удобным как для зрителей, так и для самого фотографа.
«Ну и что особенного? — спросит читатель. — Почти все книги о фотографии строятся по тому же принципу!» Знаете, шашлык все тоже готовят по схожему рецепту, но только у одних он получается вкусным, а у других — несъедобным. Александру удалось не только соблюсти рецептуру, но и существенно ее улучшить. Во-первых, информация очень грамотно дозирована, а фотограф, переквалифицировавшийся на время в писатели, продемонстрировал недюжинный талант в новом для себя занятии. Книга легко читается, и, пока не дойдешь до последней страницы, не возникает желания отложить ее в сторонку, дабы «переварить» прочитанное. Во-вторых, автор свято следует пословице о преимуществе визуального восприятия над аудиальным, и везде, где это возможно, не рассказывает, а показывает, сопровождая иллюстрации коротким и доходчивым комментарием. К слову, иллюстрации выше всяких похвал, даже трудно представить — сколько времени потратил Александр на их подбор. Ведь для того, чтобы в книгу попали только самые «говорящие» снимки, автор не только перелопатил собственный фотоархив, но и воспользовался базами своих коллег. В-третьих, Беленький постоянно приводит примеры из собственного опыта[Уточню, что автор — профессиональный фотограф, в разное время сотрудничавший с крупнейшими отечественными и зарубежными газетами и журналами], подчеркивая тезис, высказанный в самом начале книги: доскональное знание правил и приемов вовсе не делает человека с камерой настоящим фотографом. Просто, не забывая о них и постоянно практикуясь, талантливый человек быстрее научится создавать нечто, выбивающееся из привычных рамок, и в результате станет мастером фотодела.
И вот еще что. Александр Беленький — человек, несомненно, опытный и компетентный, но он ни разу не позволил себе изложить мысли в стиле «Я д’Артаньян, а вы книгу уже купили, так что внимайте и не спорьте». Напротив, он очень тактичен и ни за что не станет навязывать собственное мнение, не подкрепив его убедительным доказательством и примером из практики. Это подкупает и вызывает желание не только научиться у Беленького искусству фотографии, но и подшлифовать кое-что в своем владении писательским ремеслом.
Жаль, конечно, что автор не стал рассказывать об обработке фотографий, но, с другой стороны, книг «про Фотошоп» выпущено немало, и при желании можно подобрать небольшое руководство по сходной цене. Что же до «Школы мастерства», то за нее просят около 640 рублей, и в данном случае у меня не повернется язык назвать цену завышенной. Право же, такой труд хочется хорошо оплачивать.
Широкое распространение недорогих цифровых камер заставило очень многих людей почувствовать себя фотографами, и особенно хорошо это заметили девушки, разместившие анкеты на расплодившихся серверах онлайн-знакомств. По сведениям, полученным от моих знакомых дам, гениальные фотохудожники — третий по распространенности типаж на соответствующих сайтах, чаще которого встречаются только водители грузовиков турецкого происхождения и отечественные мачо, чей словарный запас исчерпывается фразами «привет, как дела?» и «пачиму не отвечаеш?».
Шутки шутками, но даже в такой небогатой стране, как наша, цифровиков разного уровня продается по полмиллиона в квартал, и продажи неуклонно растут. Соответственно появляется все больше людей, которым нужно чуть больше, чем просто фотографировать семейные торжества, методично забивая винчестер компьютера жуткими наборами из красных глаз, высветленных до неузнаваемости встроенной вспышкой лиц и «бочек», характерных для дешевого «цифромыла» даже на небольшом оптическом зуме. Наевшись всего этого, многие решают узнать о фотографии побольше — например, разобраться в ручных настройках камеры или освоить основы композиции. Да и в таинственном Photoshop’e неплохо бы научиться работать, ведь все вокруг говорят, что в нем можно «вытянуть» даже самый неудачный кадр! Человек кидается в книжный магазин и обмирает, потому что перед ним выстраиваются целые шеренги корешков с «вкусными» названиями, вроде «Самого полного самоучителя фотографа-профессионала» или «Библии цифровой фотографии»[Кстати, я на днях углядел в киоске около дома толстую книжку «Фотографируем мобильником». Надо будет в следующий раз не пожалеть 200 рублей и купить этот шедевр для коллекции]. И все бы хорошо, но ведь регулярно практикующему и действительно талантливому фотографу обычно некогда писать книжки. Да и пером он зачастую владеет хуже, чем объективом. Поэтому выбирать, как правило, приходится между «импортной» литературой, качество содержимого и перевода которой весьма разнородно, и отечественными продуктами, написанными якобы известными на весь мир фотографами, которых в приличных изданиях не пускали дальше курилки даже во времена пика карьеры, пришедшегося на годы хрущевского волюнтаризма. Очень весело читать этих бодрых старичков: нет-нет да и ввернут про неоспоримые преимущества пленочных камер, в сравнении с которыми все эти цифровые извращения ну словно плотник супротив столяра.
Зная это, я с большим подозрением взялся за «Оранжевую книгу цифровой фотографии» Дмитрия Рудакова, однако уже страниц через двадцать ваш покорный слуга расслабился и дочитал ее с интересом и не без удовольствия. И все потому, что автор, в отличие от многих коллег, не стал пытаться написать всеобъемлющий серьезный труд. В интервью, найденном на просторах Рунета, Рудаков клеймит бездарных переводчиков, превращающих даже лучшие западные учебники в унылое чтиво, и с горечью отмечает, что за последние годы отечественные авторы разучились писать хорошую учебную литературу. Поэтому, выбрав вольный и местами панибратский стиль, заставляющий вспомнить, к примеру, Андрея Белянина[Автор книжных сериалов «Тайный сыск царя Гороха», «Моя жена — ведьма» и др.], Дмитрий за год написал неплохое пособие, в котором субъективные высказывания общего характера неплохо сочетаются с массой полезных для «продолжающего» фотографа советов. Прочитав «Оранжевую книгу», вы действительно научитесь правильно компоновать кадр и читать гистограмму, оцените преимущества формата RAW над всеми остальными и овладеете основными приемами работы с «цифровыми негативами», поймете разницу между «цифромылом» и зеркалкой, и с помощью Photoshop’а научитесь устранять типичные недостатки любительских снимков, заодно подчеркивая их достоинства. Полезен и раздел, посвященный печати фотографий в домашних условиях, хотя несколько смущает нежелание автора познакомить нас со свежими моделями принтеров, упоминание только широкоформатных моделей (A3+) и откровенная приверженность брэнду Epson. Нет, никто не сомневается, что принтеры Epson прекрасно печатают фотографии, но, наверное, и в продуктовых линейках HP с Canon можно найти что-то достойное. А еще у всей троицы очень по-разному выглядит интерфейс драйверов, на чем стоило бы остановиться поподробнее… Заключительные разделы посвящены наложению разнообразных эффектов в Adobe Photoshop, и если вы уже отдали за эту полезную программу положенные $600, не пожалейте и 700 рублей на «Оранжевую книгу цифровой фотографии» — получите удовольствие.
По сути, у книги всего один серьезный недостаток: ее автор работает только на «макинтошах», так что скриншоты выглядят очень… непривычно. Нет, я, конечно, понимаю, что Adobe Photoshop CS2 для «маков» отличается от своей «писишной» реинкарнации гораздо меньше, чем, к примеру, Apple QuickTime, но вероятность небольших нестыковок исключать нельзя. Да и все видеоуроки на прилагаемом к книге CD записаны в упомянутом формате QuickTime, хотя дистрибутив последнего никто на диск положить не догадался. То-то обрадуются обладатели «писюков» без доступа в Интернет…
Но в целом, повторюсь, книга хороша, и если вас не смущает слегка завышенная цена, можете смело приобрести ее в личное пользование.
«Ну и что особенного? — спросит читатель. — Почти все книги о фотографии строятся по тому же принципу!» Знаете, шашлык все тоже готовят по схожему рецепту, но только у одних он получается вкусным, а у других — несъедобным. Александру удалось не только соблюсти рецептуру, но и существенно ее улучшить. Во-первых, информация очень грамотно дозирована, а фотограф, переквалифицировавшийся на время в писатели, продемонстрировал недюжинный талант в новом для себя занятии. Книга легко читается, и, пока не дойдешь до последней страницы, не возникает желания отложить ее в сторонку, дабы «переварить» прочитанное. Во-вторых, автор свято следует пословице о преимуществе визуального восприятия над аудиальным, и везде, где это возможно, не рассказывает, а показывает, сопровождая иллюстрации коротким и доходчивым комментарием. К слову, иллюстрации выше всяких похвал, даже трудно представить — сколько времени потратил Александр на их подбор. Ведь для того, чтобы в книгу попали только самые «говорящие» снимки, автор не только перелопатил собственный фотоархив, но и воспользовался базами своих коллег. В-третьих, Беленький постоянно приводит примеры из собственного опыта[Уточню, что автор — профессиональный фотограф, в разное время сотрудничавший с крупнейшими отечественными и зарубежными газетами и журналами], подчеркивая тезис, высказанный в самом начале книги: доскональное знание правил и приемов вовсе не делает человека с камерой настоящим фотографом. Просто, не забывая о них и постоянно практикуясь, талантливый человек быстрее научится создавать нечто, выбивающееся из привычных рамок, и в результате станет мастером фотодела.
И вот еще что. Александр Беленький — человек, несомненно, опытный и компетентный, но он ни разу не позволил себе изложить мысли в стиле «Я д’Артаньян, а вы книгу уже купили, так что внимайте и не спорьте». Напротив, он очень тактичен и ни за что не станет навязывать собственное мнение, не подкрепив его убедительным доказательством и примером из практики. Это подкупает и вызывает желание не только научиться у Беленького искусству фотографии, но и подшлифовать кое-что в своем владении писательским ремеслом.
Жаль, конечно, что автор не стал рассказывать об обработке фотографий, но, с другой стороны, книг «про Фотошоп» выпущено немало, и при желании можно подобрать небольшое руководство по сходной цене. Что же до «Школы мастерства», то за нее просят около 640 рублей, и в данном случае у меня не повернется язык назвать цену завышенной. Право же, такой труд хочется хорошо оплачивать.
АНАЛИЗЫ: Требования и возможности
Автор: Сергей Длужневский
Зачем и как нужно разрабатывать требования к автоматизированной системе? Ответ на этот вопрос, столь очевидный для одних, совершенно не очевиден для других. Особенно для тех, кто по роду деятельности далек от того, что именуется IT-индустрией. А ведь именно таким людям приходится порой принимать непосредственное участие в разработке этих требований — как бизнес-пользователям будущей системы.
И если отсутствует понимание важности этой задачи (а оно, как правило, отсутствует), то результатом будет разочарование заказчиков системы, получивших совсем не тот продукт, который они ожидали увидеть, и досада разработчиков, осознавших, что все, над чем они трудились последние N (по закону Мерфи — p*N) месяцев, оказалось впустую.
В бытность свою консультантом, аналитиком, руководителем проектов и пр. мне столько раз приходилось «наступать на различные грабли», что если хотя бы одному человеку, прочитавшему эту статью, удастся какие-то из «граблей» миновать, я буду считать, что поставленной цели достиг.
В конфликтах обычно виноваты обе стороны. Заказчик, как правило, стремится сэкономить, где только возможно (с его точки зрения). Однако не понимает, что есть работы, экономия на которых неизбежно приведет к возникновению рисков, а их компенсация может потребовать существенного увеличения бюджета проекта. Это непонимание вполне объяснимо, учитывая, что большинство заказчиков не являются специалистами в IT (и к тому же плохо представляют процесс разработки ПО).
В такой ситуации задача специалистов исполнителя заключается в том, чтобы разъяснить все эти моменты. Понятно, что разъяснения не всегда бывают успешными, а значит, где-то надо поступать в строгом соответствии с оговоренными правилами сотрудничества. При этом должны оформляться такие-то документы, а порядок взаимодействия такой-то. И это не обсуждается. Можно привести массу примеров, когда проекты не только сопровождались конфликтными ситуациями, но и заканчивались полным провалом из-за того, что должным образом не были формализованы отношения.
Что же представляют собой требования к автоматизированной системе? Это некий документ. Именно документ, поскольку пожелания к будущей системе, сформулированные в процессе общения между экспертами предметной области и аналитиками, собирающими требования, таковыми по сути своей не являются, а остаются всего лишь пожеланиями и личными мнениями тех, кто эти пожелания сформулировал.
Заказчик, думая об информационной системе, способной повысить эффективность его бизнеса, имеет некоторое видение ее функциональных и технических характеристик, которое (при весьма четком понимании целей создания системы) порой является очень туманным. Хуже того, в подавляющем большинстве случаев высказываемые пожелания не могут быть использованы даже в качестве исходных данных для проектирования. Процесс разработки требований представляет собой попытку формализации пожеланий заказчика к проектируемой системе в терминах, понятных как заказчику, так и исполнителю.
Разработка требований является довольно трудоемким процессом, в реализацию которого вовлечены специалисты обеих сторон. Как правило, созданию документа предшествует очень сложная и ответственная работа сбора и анализа информации, позволяющей как можно точнее определить потребности заказчика в создаваемой системе и соответственно являющейся исходными данными для формулирования требований. Конечно, успех этой задачи во многом зависит от профессионализма аналитика, но не менее важно, каким образом он оформляет собранную информацию и подтверждает ее достоверность.
Строго говоря, на этапе разработки требований надо стараться документировать вообще все, что возможно и что имеет отношение к решаемой задаче. А именно: результаты интервью, совещаний, переговоров, промежуточные договоренности, телефонные звонки — все это может послужить бесценным источником информации, которая может быть безвозвратно утеряна. К сожалению, зачастую представители бизнеса неверно истолковывают желание педантично фиксировать, перепроверять и согласовывать полученную информацию, считая это излишним формализмом.
А между тем даже словосочетание «требования к системе» участники процесса зачастую понимают по-разному. Так, для разработчика — это часто скорее технические требования, частично определяющие, как это будет реализовано. А для бизнес-пользователей заказчика — это скорее совокупность задач (причем рассматриваемых в контексте бизнес-процессов). Поэтому крайне важно перед началом процесса разработки требований договориться как минимум о содержании итогового документа или документов, а также о форме представления информации, порядке согласования и утверждения. И не просто договориться, а заключить формальное соглашение, утвержденное и обязательное к исполнению всеми участниками проекта. Надо понимать, что это одинаково касается как крупной компании, занимающейся разработкой ПО на заказ, так и какого-нибудь Васи Пупкина, подвизавшегося набросать сайт-визитку для одногруппника.
Например, не стоит обсуждать рабочие вопросы с заказчиками, не включив диктофон (разумеется, предварительно договорившись об этом). Будь то рабочая встреча, обсуждение, совещание или же телефонные переговоры. Это требуется прежде всего для снижения риска потери информации (не успел записать, не обратил внимания и т. д.). Кроме того, массу полезной информации можно пропустить во время общения просто потому, что в данный момент аналитик сосредоточен на решении других, более узких задач. А информация, которая при разговоре показалось второстепенной и не запомнилась, может оказаться весьма важной при дальнейшей работе. Когда же имеется запись, то при повторном прослушивании она может быть восстановлена без вторичного привлечения экспертов и, следовательно, без лишнего беспокойства заказчика.
Однако зачастую представители заказчика просто отказываются говорить, узнав, что разговор записывается. Или требуют не включать диктофон. Из-за боязни, что их слова могут прозвучать недостаточно компетентно, что начальство, услышав записанное, может обвинить их в непрофессионализме.
Это предубеждение важно развеять максимально быстро и эффективно. Необходимо объяснять причины, которыми руководствуется аналитик, ведя аудиозапись разговора или обсуждения. Люди должны понять, что никто не собирается компрометировать их этим материалом. Пояснить, что главная цель — обеспечить больший КПД от одной встречи, снижая вероятность проведения повторных обсуждений и уменьшая трудозатраты заказчика.
Сделать это можно по-разному. Начиная от краткого мини-семинара с каждым интервьюируемым сотрудником компании-заказчика и заканчивая просьбой издать распорядительный документ на уровне всей его компании. В котором будет четко регламентирован процесс взаимодействия между специалистами заказчика и исполнителя на период разработки требований к системе. Зависит от объема задач, их сложности, политической ситуации и т. п.
Конечно, не стоит кривить душой и говорить, что такие аудиозаписи не могут применяться в качестве инструмента давления. Могут. И более того, применяются. Однако прибегать к нему следует только в самых крайних случаях. Поскольку за этим всегда следует осложнение отношений между заказчиком и исполнителем. Но уж если случилось… Если заказчик «на голубом глазу» заявляет, что-де он «такого не говорил, все это выдумки», обвиняет во всем исполнителя, вот тогда запись разговора, как некое вещественное доказательство, может оказаться вашей единственной защитой.
Не исключены случаи, когда люди действительно забывают, что они говорили несколько месяцев назад. В таком случае совместное прослушивание аудиозаписи поможет освежить в памяти старый разговор и исключить необходимость повторных согласований. К «давлению» это, конечно, не имеет никакого отношения.
Ясное понимание всеми членами рабочей группы целей создания информационной системы и важности проводимых мероприятий, четкое ориентирование на определенный конечный результат.
Рабочая группа должна разработать соглашения, определяющие:
— полномочия членов группы;
— шаблоны будущих документов;
— порядок взаимодействия между заказчиком и исполнителем;
— регламент согласования документов (включая состав согласующих и утверждающих лиц, временные ограничения на прохождение согласований).
Выделение одного или нескольких ответственных, в чьи функции будут входить:
— координация взаимодействия специалистов исполнителя с членами рабочей группы;
— решение потенциально возможных организационных и коммуникационных проблем;
— визирование промежуточных результатов работы, а также согласование и утверждение конечного документа.
Своевременное предоставление (в оговоренный срок) ответов на вопросы специалистов исполнителя. Нарушение этого правила с большой долей вероятности приведет к простаиванию специалистов исполнителя, что скажется на общих сроках и стоимости.
Все рабочие встречи, обсуждения, совещания, а также телефонные переговоры должны записываться на диктофон.
Обязательное протоколирование совещаний (заседаний рабочей группы, встреч, телефонных переговоров), во время которых принимаются решения, носящие критически важный характер. Прочие протоколы носят опциональный характер и готовятся по мере возможности. В протокол вносится информация об участниках совещания, вопросах для обсуждения и решениях по указанным вопросам. Протоколу присваивается номер и проставляется дата составления. Протокол составляется специалистами исполнителя и подписывается ответственными лицами со стороны заказчика.
Любые изменения в части требований к системе, влияющие на сроки и стоимость разработки системы, должны быть в обязательном порядке формализованы и согласованы между исполнителем и заказчиком.
Зачем и как нужно разрабатывать требования к автоматизированной системе? Ответ на этот вопрос, столь очевидный для одних, совершенно не очевиден для других. Особенно для тех, кто по роду деятельности далек от того, что именуется IT-индустрией. А ведь именно таким людям приходится порой принимать непосредственное участие в разработке этих требований — как бизнес-пользователям будущей системы.
И если отсутствует понимание важности этой задачи (а оно, как правило, отсутствует), то результатом будет разочарование заказчиков системы, получивших совсем не тот продукт, который они ожидали увидеть, и досада разработчиков, осознавших, что все, над чем они трудились последние N (по закону Мерфи — p*N) месяцев, оказалось впустую.
В бытность свою консультантом, аналитиком, руководителем проектов и пр. мне столько раз приходилось «наступать на различные грабли», что если хотя бы одному человеку, прочитавшему эту статью, удастся какие-то из «граблей» миновать, я буду считать, что поставленной цели достиг.
Когда формализм сродни искусству…
Работа «по жизни» и работа «как в книжке» отличаются, и порой очень сильно. Как-то в недавнем разговоре с одним специалистом, с которым проводилось собеседование при приеме на работу, я смоделировал очень нехорошую ситуацию, возникшую на проекте, и спросил, как он собирается из нее выкручиваться. В ответ услышал, что таких ситуаций быть не может, потому что это неправильно, противоречит тому, как все должно быть, и вообще, таких ситуаций у него еще не было. Тем не менее ситуация действительно имела место. А человек оказался не готов к такому повороту событий.В конфликтах обычно виноваты обе стороны. Заказчик, как правило, стремится сэкономить, где только возможно (с его точки зрения). Однако не понимает, что есть работы, экономия на которых неизбежно приведет к возникновению рисков, а их компенсация может потребовать существенного увеличения бюджета проекта. Это непонимание вполне объяснимо, учитывая, что большинство заказчиков не являются специалистами в IT (и к тому же плохо представляют процесс разработки ПО).
В такой ситуации задача специалистов исполнителя заключается в том, чтобы разъяснить все эти моменты. Понятно, что разъяснения не всегда бывают успешными, а значит, где-то надо поступать в строгом соответствии с оговоренными правилами сотрудничества. При этом должны оформляться такие-то документы, а порядок взаимодействия такой-то. И это не обсуждается. Можно привести массу примеров, когда проекты не только сопровождались конфликтными ситуациями, но и заканчивались полным провалом из-за того, что должным образом не были формализованы отношения.
Что же представляют собой требования к автоматизированной системе? Это некий документ. Именно документ, поскольку пожелания к будущей системе, сформулированные в процессе общения между экспертами предметной области и аналитиками, собирающими требования, таковыми по сути своей не являются, а остаются всего лишь пожеланиями и личными мнениями тех, кто эти пожелания сформулировал.
Заказчик, думая об информационной системе, способной повысить эффективность его бизнеса, имеет некоторое видение ее функциональных и технических характеристик, которое (при весьма четком понимании целей создания системы) порой является очень туманным. Хуже того, в подавляющем большинстве случаев высказываемые пожелания не могут быть использованы даже в качестве исходных данных для проектирования. Процесс разработки требований представляет собой попытку формализации пожеланий заказчика к проектируемой системе в терминах, понятных как заказчику, так и исполнителю.
Пример из практики
При работе над одним довольно крупным проектом по автоматизации деятельности компании заказчика был подготовлен и подписан документ требований. На его основании велась разработка системы. По окончании сборки первой версии системы один из разработчиков был командирован к заказчику (находящемуся в другом городе) с целью развертывания и тестирования системы реальными пользователями. Он провел несколько встреч с представителями бизнеса и в итоге полностью уяснил, что хотят пользователи и как это можно реализовать. И пообещал, что это будет сделано. Только вот одно «но». Их договоренности не были нигде и ни в каком виде зафиксированы. Вернувшись из командировки, разработчик действительно начал воплощать в жизнь свое обещание. Но, как обычно бывает, постепенно навалились другие заботы. А потом ему предложили более выгодную работу, и он уволился. Подошла пора сдавать проект. И вот тут-то и всплыли те самые, нигде не зафиксированные договоренности. Заказчик наотрез отказался принимать систему без необходимого ему функционала. А компания-разработчик отказалась этот функционал реализовывать. Поскольку ни сроки, ни стоимость этих работ не были заложены в бюджет проекта.Разбор перед полетом
Требования должны быть собраны, проанализированы, структурированы, формализованы и представлены в виде законченного, согласованного и утвержденного документа. Как со стороны тех, кто эти требования предъявляет (тем самым они выражают свое согласие с тем, что в документе представлено именно то, что им нужно), так и со стороны тех, кто будет разрабатывать систему (этим они подписываются под тем, что требования им понятны, реализуемы и достаточны для разработки системы).Разработка требований является довольно трудоемким процессом, в реализацию которого вовлечены специалисты обеих сторон. Как правило, созданию документа предшествует очень сложная и ответственная работа сбора и анализа информации, позволяющей как можно точнее определить потребности заказчика в создаваемой системе и соответственно являющейся исходными данными для формулирования требований. Конечно, успех этой задачи во многом зависит от профессионализма аналитика, но не менее важно, каким образом он оформляет собранную информацию и подтверждает ее достоверность.
Строго говоря, на этапе разработки требований надо стараться документировать вообще все, что возможно и что имеет отношение к решаемой задаче. А именно: результаты интервью, совещаний, переговоров, промежуточные договоренности, телефонные звонки — все это может послужить бесценным источником информации, которая может быть безвозвратно утеряна. К сожалению, зачастую представители бизнеса неверно истолковывают желание педантично фиксировать, перепроверять и согласовывать полученную информацию, считая это излишним формализмом.
А между тем даже словосочетание «требования к системе» участники процесса зачастую понимают по-разному. Так, для разработчика — это часто скорее технические требования, частично определяющие, как это будет реализовано. А для бизнес-пользователей заказчика — это скорее совокупность задач (причем рассматриваемых в контексте бизнес-процессов). Поэтому крайне важно перед началом процесса разработки требований договориться как минимум о содержании итогового документа или документов, а также о форме представления информации, порядке согласования и утверждения. И не просто договориться, а заключить формальное соглашение, утвержденное и обязательное к исполнению всеми участниками проекта. Надо понимать, что это одинаково касается как крупной компании, занимающейся разработкой ПО на заказ, так и какого-нибудь Васи Пупкина, подвизавшегося набросать сайт-визитку для одногруппника.
Пример из практики
На одном из проектов заказчик решил выполнять разработку системы собственными силами. Но у него отсутствовали квалифицированные аналитики для проведения анализа предметной области и разработки постановочных документов. С этой целью он заключил договор с внешней компанией, которая предоставила ресурсы для проведения необходимых работ. Соглашения о составе и структуре выходных документов заключено не было. По ряду причин проект продвигался тяжело. И на заключительной фазе был составлен очень жесткий график, где задачи были расписаны чуть ли не поминутно. Ни для чего незапланированного времени не оставалось. Внезапно заказчик потребовал, чтобы к предварительному перечню итоговых документов был добавлен еще один. Причем его подготовка требовала значительного времени, и в этом случае проект не укладывался в утвержденные сроки. При попытке объяснить это заказчику, от него был получен ответ, что состав и количество выходных документов формально оговорены не были, а значит, он может требовать то, что ему нужно. Сроки окончания проекта он также переносить не желает, поскольку они уже утверждены и подписаны обеими сторонами. Не желая портить отношения с заказчиком, руководство исполнителя приняло решение выполнять эту работу сверхурочно. Проект был успешно завершен, но и у заказчика, и у исполнителя остался неприятный осадок от совместной работы. Аналитик, проведший несколько бессонных ночей за клавиатурой, естественно, в восторге тоже не был…Как брать анализ
Помимо непонимания сути происходящего, существуют и другие причины, заставляющие некоторых бизнес-пользователей с опаской относиться к методам работы, используемым аналитиками.Например, не стоит обсуждать рабочие вопросы с заказчиками, не включив диктофон (разумеется, предварительно договорившись об этом). Будь то рабочая встреча, обсуждение, совещание или же телефонные переговоры. Это требуется прежде всего для снижения риска потери информации (не успел записать, не обратил внимания и т. д.). Кроме того, массу полезной информации можно пропустить во время общения просто потому, что в данный момент аналитик сосредоточен на решении других, более узких задач. А информация, которая при разговоре показалось второстепенной и не запомнилась, может оказаться весьма важной при дальнейшей работе. Когда же имеется запись, то при повторном прослушивании она может быть восстановлена без вторичного привлечения экспертов и, следовательно, без лишнего беспокойства заказчика.
Это предубеждение важно развеять максимально быстро и эффективно. Необходимо объяснять причины, которыми руководствуется аналитик, ведя аудиозапись разговора или обсуждения. Люди должны понять, что никто не собирается компрометировать их этим материалом. Пояснить, что главная цель — обеспечить больший КПД от одной встречи, снижая вероятность проведения повторных обсуждений и уменьшая трудозатраты заказчика.
Сделать это можно по-разному. Начиная от краткого мини-семинара с каждым интервьюируемым сотрудником компании-заказчика и заканчивая просьбой издать распорядительный документ на уровне всей его компании. В котором будет четко регламентирован процесс взаимодействия между специалистами заказчика и исполнителя на период разработки требований к системе. Зависит от объема задач, их сложности, политической ситуации и т. п.
Конечно, не стоит кривить душой и говорить, что такие аудиозаписи не могут применяться в качестве инструмента давления. Могут. И более того, применяются. Однако прибегать к нему следует только в самых крайних случаях. Поскольку за этим всегда следует осложнение отношений между заказчиком и исполнителем. Но уж если случилось… Если заказчик «на голубом глазу» заявляет, что-де он «такого не говорил, все это выдумки», обвиняет во всем исполнителя, вот тогда запись разговора, как некое вещественное доказательство, может оказаться вашей единственной защитой.
Не исключены случаи, когда люди действительно забывают, что они говорили несколько месяцев назад. В таком случае совместное прослушивание аудиозаписи поможет освежить в памяти старый разговор и исключить необходимость повторных согласований. К «давлению» это, конечно, не имеет никакого отношения.
Для успешного выполнения работ требуется:
Организация рабочей группы, в которую будут включены эксперты соответствующих предметных областей.Ясное понимание всеми членами рабочей группы целей создания информационной системы и важности проводимых мероприятий, четкое ориентирование на определенный конечный результат.
Рабочая группа должна разработать соглашения, определяющие:
— полномочия членов группы;
— шаблоны будущих документов;
— порядок взаимодействия между заказчиком и исполнителем;
— регламент согласования документов (включая состав согласующих и утверждающих лиц, временные ограничения на прохождение согласований).
Выделение одного или нескольких ответственных, в чьи функции будут входить:
— координация взаимодействия специалистов исполнителя с членами рабочей группы;
— решение потенциально возможных организационных и коммуникационных проблем;
— визирование промежуточных результатов работы, а также согласование и утверждение конечного документа.
Своевременное предоставление (в оговоренный срок) ответов на вопросы специалистов исполнителя. Нарушение этого правила с большой долей вероятности приведет к простаиванию специалистов исполнителя, что скажется на общих сроках и стоимости.
Все рабочие встречи, обсуждения, совещания, а также телефонные переговоры должны записываться на диктофон.
Обязательное протоколирование совещаний (заседаний рабочей группы, встреч, телефонных переговоров), во время которых принимаются решения, носящие критически важный характер. Прочие протоколы носят опциональный характер и готовятся по мере возможности. В протокол вносится информация об участниках совещания, вопросах для обсуждения и решениях по указанным вопросам. Протоколу присваивается номер и проставляется дата составления. Протокол составляется специалистами исполнителя и подписывается ответственными лицами со стороны заказчика.
Любые изменения в части требований к системе, влияющие на сроки и стоимость разработки системы, должны быть в обязательном порядке формализованы и согласованы между исполнителем и заказчиком.