И вот еще что. Александр Беленький – человек, несомненно, опытный и компетентный, но он ни разу не позволил себе изложить мысли в стиле «Я д’Артаньян, а вы книгу уже купили, так что внимайте и не спорьте». Напротив, он очень тактичен и ни за что не станет навязывать собственное мнение, не подкрепив его убедительным доказательством и примером из практики. Это подкупает и вызывает желание не только научиться у Беленького искусству фотографии, но и подшлифовать кое-что в своем владении писательским ремеслом.

Жаль, конечно, что автор не стал рассказывать об обработке фотографий, но, с другой стороны, книг «про Фотошоп» выпущено немало, и при желании можно подобрать небольшое руководство по сходной цене. Что же до «Школы мастерства», то за нее просят около 640 рублей, и в данном случае у меня не повернется язык назвать цену завышенной. Право же, такой труд хочется хорошо оплачивать.

АНАЛИЗЫ: Требования и возможности

Автор: Сергей Длужневский

Зачем и как нужно разрабатывать требования к автоматизированной системе? Ответ на этот вопрос, столь очевидный для одних, совершенно не очевиден для других. Особенно для тех, кто по роду деятельности далек от того, что именуется IT-индустрией. А ведь именно таким людям приходится порой принимать непосредственное участие в разработке этих требований – как бизнес-пользователям будущей системы.

И если отсутствует понимание важности этой задачи (а оно, как правило, отсутствует), то результатом будет разочарование заказчиков системы, получивших совсем не тот продукт, который они ожидали увидеть, и досада разработчиков, осознавших, что все, над чем они трудились последние N (по закону Мерфи – p*N) месяцев, оказалось впустую.

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

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

В конфликтах обычно виноваты обе стороны. Заказчик, как правило, стремится сэкономить, где только возможно (с его точки зрения). Однако не понимает, что есть работы, экономия на которых неизбежно приведет к возникновению рисков, а их компенсация может потребовать существенного увеличения бюджета проекта. Это непонимание вполне объяснимо, учитывая, что большинство заказчиков не являются специалистами в IT (и к тому же плохо представляют процесс разработки ПО).

В такой ситуации задача специалистов исполнителя заключается в том, чтобы разъяснить все эти моменты. Понятно, что разъяснения не всегда бывают успешными, а значит, где-то надо поступать в строгом соответствии с оговоренными правилами сотрудничества. При этом должны оформляться такие-то документы, а порядок взаимодействия такой-то. И это не обсуждается. Можно привести массу примеров, когда проекты не только сопровождались конфликтными ситуациями, но и заканчивались полным провалом из-за того, что должным образом не были формализованы отношения.

Что же представляют собой требования к автоматизированной системе? Это некий документ. Именно документ, поскольку пожелания к будущей системе, сформулированные в процессе общения между экспертами предметной области и аналитиками, собирающими требования, таковыми по сути своей не являются, а остаются всего лишь пожеланиями и личными мнениями тех, кто эти пожелания сформулировал.

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

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

Требования должны быть собраны, проанализированы, структурированы, формализованы и представлены в виде законченного, согласованного и утвержденного документа. Как со стороны тех, кто эти требования предъявляет (тем самым они выражают свое согласие с тем, что в документе представлено именно то, что им нужно), так и со стороны тех, кто будет разрабатывать систему (этим они подписываются под тем, что требования им понятны, реализуемы и достаточны для разработки системы).

Разработка требований является довольно трудоемким процессом, в реализацию которого вовлечены специалисты обеих сторон. Как правило, созданию документа предшествует очень сложная и ответственная работа сбора и анализа информации, позволяющей как можно точнее определить потребности заказчика в создаваемой системе и соответственно являющейся исходными данными для формулирования требований. Конечно, успех этой задачи во многом зависит от профессионализма аналитика, но не менее важно, каким образом он оформляет собранную информацию и подтверждает ее достоверность.

Строго говоря, на этапе разработки требований надо стараться документировать вообще все, что возможно и что имеет отношение к решаемой задаче. А именно: результаты интервью, совещаний, переговоров, промежуточные договоренности, телефонные звонки – все это может послужить бесценным источником информации, которая может быть безвозвратно утеряна. К сожалению, зачастую представители бизнеса неверно истолковывают желание педантично фиксировать, перепроверять и согласовывать полученную информацию, считая это излишним формализмом.

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