Как заказать и получить качественный программный продукт?

Автор: А. В. Спивак (руководитель проектов ООО «Петровайзер»)
Издание: «Бурение и нефть» №6 2011 г.

«Создавать продукт, опираясь на фокус – группы, по-настоящему трудно.
Чаще всего люди не понимают, что им на самом деле нужно, пока сам им этого не подскажешь».
Стивен Пол Джобс (Steven Paul Jobs),
американский инженер и предприниматель,
сооснователь и генеральный директор Aplle Inc.

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

Сегодня ни для кого не является секретом, что в современных условиях рынка, на первое место вышла борьба за качество услуг, в том числе за качество разрабатываемого программного обеспечения.

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

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

Функционал — как только потенциальный пользователь видит, что заявленный функционал не работает в любой своей части, он уже не будет обращать внимание на то, что все остальное работает как часы. Скорее всего, он начнет проводить анализ рынка и искать программное обеспечение, которое полностью удовлетворит его потребности.

Производительность — современные аппаратные средства предоставляют практически неограниченные (в разумных пределах) возможности. Не стоит пытаться объяснять пользователю, почему разработанная вами прожорливая программа заняла все ресурсы его компьютера и висит уже около часа. Вывод будет сделан не в вашу пользу.

Отказоустойчивость — любое программное обеспечение, каким бы хорошим оно не было, содержит ошибки. Это аксиома. Насколько полно обработаны возможные ошибки внутри вашей программы, будут ли понятны сообщения, которые будет выводить программа? Как часто пользователю придется прибегать к перезагрузке операционной системы, потому что программа ее заблокировала? Сможет ли программа корректно сохранить данные, которые пользователь заносил на протяжении нескольких часов или при повторном запуске ему придется повторить процедуру сначала? Не стоит думать, что наличие проблем с отказоустойчивостью не повлияет на лояльность пользователя.

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

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

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

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

В работе «No Silver Bullet: Essence and Accidents of Software Engineering» (1987 г.) Frederick Brooks написал: «Строжайшее и единственное правило построения систем ПО - решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно». И это правда.

В современных российских условиях абсолютно все государственные и муниципальные компании обязаны руководствоваться Федеральным Законом от 25 июля 2005 г. № 94-ФЗ «О размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд». Следом за ними и частные компании разработали положения, регулирующие эти отношения, причем, зачастую, за основу принимался именно 94-ФЗ с незначительными изменениями. Отличная идея о том, что при помощи проведения открытых конкурсов станет возможно экономить средства, получая при этом товары и услуги высокого качества, разбилась о камни российской действительности. Определение «тендер – публичное уведомление общественности о предстоящей в скором времени закупке у постоянного поставщика крупной партии товара по завышенной цене», можно воспринимать как шутку, но в каждой шутке есть доля правды.

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

Разработка программного обеспечения по требованиям заказчика является специфическим видом деятельности. Специфика состоит в том, что это не только и даже не столько процесс написания кода, как многие себе представляют, сколько исследовательская, а иногда и научно-исследовательская, организаторская, методическая и технологическая деятельность. Нельзя ставить в один ряд процесс закупки шариковых ручек, оклейку стен обоями и создание нового уникального программного продукта. Заказчик вполне может подготовить документацию на конкурс по закупке 1000 шариковых ручек, самостоятельно определить их характеристики. Ему просто это сделать. Он каждый день видит ручки самые разные, у него сформированы стойкие предпочтения, он точно определил для себя, что именно ему надо, какие свойства важны в первую очередь, какие менее важны, а какие совершенно безразличны. Следует отметить и тот факт, что материальным обеспечением компании, обычно занимаются специально назначенные и подготовленные для этого люди. С программным обеспечением все совсем не так.

Процесс подготовки ТЗ трудоемкий, а его объем на программный комплекс может исчисляться сотнями страниц. Для того чтобы заказчик и исполнитель могли представить готовый продукт, осознать, что нужно заказчику, спланировать последовательность выполнения работ, выполнить намеченное, а в последующем успешно провести приемочное испытание, ТЗ должно быть подготовлено профессионалами и таким образом, что бы обе стороны уже в процессе подготовки выработали единое мнение относительно того, что должно получиться в результате. Совершенно очевидно, что все исполнители разные и степень формализации требований, которая устраивает одного исполнителя совершенно не подходит для другого. Имеет ли смысл вообще заказчику самостоятельно браться за разработку технического задания? Опыт показывает, что в подавляющем большинстве случаев, ответ однозначный — нет. Техническое задание должен готовить разработчик, именно он должен помочь заказчику грамотно поставить цели и сформулировать задачи. Если цели не ясны, то должен проходить итеративный процесс написания — разработчик поэтапно формулирует цель в глазах заказчика. Это трудный и длительный процесс, но именно он поможет избежать двусмысленностей и непонимания в дальнейшем.

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

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

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

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

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

Насколько подробным должно быть ТЗ? Этот вопрос, часто, слышим со стороны заказчиков.

Существует мнение, что определенных рекомендаций по тому, что должно содержать техническое задание не существует. Это не так. В СССР, например, существовал ГОСТ 34.603-89 «Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Полемика о том, что стандарт принят в стране, которой уже нет, что он не учитывает современные реалии, носит, как правило, неконструктивный характер. Практика показывает, что основываясь на рекомендациях, заложенных в данном документе его разработчиками, и учитывая современные организационно-технические возможности, удается в заданные сроки и с хорошим качеством создавать технические задания, а затем реализовывать программные продукты. Сравнение данного стандарта и различных зарубежных аналогов, показывает, что основные моменты, которые должны быть отражены в задании, абсолютно идентичны. Те, кто категорически считают, что зарубежные стандарты лучше, могут использовать их. Понятно, что заказчик и исполнитель могут вообще прийти к соглашению и оформить ТЗ в какой-то иной, удобной для них форме, но минимальный перечень разделов (сведений), которые будут содержаться в задании должен быть соблюден.

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

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

Определенную опасность представляют явления стихийного разрастания требований пользователей и двойственность этих требований. Расставить все точки над «i» необходимо до того, как начнется процесс кодирования, а не в процессе. Иначе, программисты не смогут писать код, тестеры не смогут понять какое поведение продукта является нормой. Заказчики будут удивляться, почему требования не выполнены или выполнены не так, а разработчики тратить время и нервы на то, чтобы понять как и что им надо переделать, чтобы с одной стороны удовлетворить заказчиков, а с другой, уложиться в отведенные сроки.

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

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

Проблема интеграции — это в первую очередь проблема общения заказчика, разработчика или нескольких разработчиков, которые в разные годы разрабатывали и внедряли на объектах заказчика свое программное обеспечение. Тема настолько многогранна, что заслуживает отдельного рассмотрения. Однако следует заметить, что на этапе формирования требований, все вопросы, связанные с интеграцией должны быть решены. Это означает, что должны быть получены описания выполненных ранее решений, форматы хранения, обмена, вызовов и прочее. А для этого, необходимо, чтобы подобными данными захотел поделиться автор. Представьте, что произойдет, если выполнив какую-то часть работы, вы узнаете, что сотрудничества не будет, а то, что планировалось выполнить, вы не сможете сделать самостоятельно в отведенные сроки.

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

Следует отметить, что при подготовке требований важно сформулировать и согласовать методику проведения испытаний разработанного ПО, а так же предусмотреть набор тестов.

Отсутствие методики проведения испытаний может привести к тому, что в момент, когда разработанное программное обеспечение необходимо будет установить на объектах заказчика, устанавливать его будет некуда, ответственных за выполнение мероприятий не окажется. Для проверки будут выделены сотрудники, которые впервые услышат о новой разработке. Испытание будет для них дополнительной нагрузкой к основной работе, а как результат — исполнитель получит негативное заключение о разработанном программном обеспечении.

Полностью исключать дефектов (ошибок) в проекте невозможно, однако необходимо всячески способствовать снижению рисков их возникновения.

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

Таким образом, источников ошибок три: неправильное понимание задачи, неправильное решение задачи, неправильный перенос в код.

Опыт показывает, что наибольшую опасность представляют первые два источника, ибо третий является, почти в 100%, следствием первых двух.

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

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

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

Обязанность сотрудников юридических служб не только проверять наличие обязательных признаков, которые должны присутствовать в типовом договоре, но и контролировать те обязательства, которые изложены в техническом задании. Что прикажете делать, если все обязательства по договору выполнены, кроме одного, которое как-то случайно оказалось в ТЗ: «разработать модуль управления вечным двигателем»?

Любая «большая» или «маленькая» программа — это не просто код. Над программой работает множество людей, иногда удаленных друг от друга географически, работающих в разных компаниях. Их работа должна быть организована, программы нельзя писать «нахрапом». Создание программного продукта — искусство, связанное с организацией эффективной работы людей, приводящей к полезному результату.

Удачная разработка ПО — нахождение оптимального соотношения между затратами на разработку и качеством результата.