исходный код программы требовал доработки
Исходный код программы требовал доработки
Проблемы регулирования модификации программного обеспечения
«Журнал Суда по интеллектуальным правам», № 2 (28), июнь 2020 г., с. 20-26
Подверженность компьютерных программ постоянным изменениям является одним из важнейших их отличий от литературных произведений и иных классических объектов авторского права: в однажды выпущенный фильм уже не будут внесены правки, главу из изданного романа уже не удалить. В то же время компьютерные программы эволюционируют на протяжении всего своего жизненного цикла – разработчики постоянно ведут работу по исправлению недостатков, совершенствуют программы для ЭВМ. В первую очередь это связано с назначением компьютерных программ, которые, в отличие от иных объектов авторского права (за исключением аналогичных по своей природе баз данных), удовлетворяют обычно не эстетические, а утилитарные потребности человека.
В соответствии с подп. 9 п. 2 ст. 1270 Гражданского кодекса РФ (далее – ГК РФ) под переработкой понимается создание производного произведения. Согласно п. 4 ст. 1260 ГК РФ автор модифицированной программы для ЭВМ обладает исключительным правом на производную программу для ЭВМ как на самостоятельное произведение, независимо от охраны прав авторов использованных произведений. При этом в качестве примеров переработки Гражданский кодекс приводит перевод, обработку, экранизацию, аранжировку, инсценировку – то есть процессы, в результате которых создается качественно новый результат интеллектуальной деятельности. Из созданной одним автором книги другой автор создает кинофильм, из созданного одним автором романа на английском языке другой автор создает текст романа на русском языке и т.д.
«Право на неприкосновенность произведения (абзац первый пункта 1 статьи 1266 ГК РФ) касается таких изменений произведения, которые не связаны с созданием нового произведения на основе имеющегося».
Исходя из этого для иных объектов авторского права использование произведений, в которые внесены изменения, не связанные с созданием нового произведения, как, например, дополнение стихотворения новым четверостишием или удаление главы из романа без согласия автора, будут являться нарушением права на неприкосновенность, а не противозаконной переработкой.
Совсем иные требования предъявляются к переработке программы для ЭВМ. Подпункт 9 п. 2 ст. 1270 ГК РФ под модификацией программы для ЭВМ понимает любое изменение программы кроме адаптации. При этом каких-либо качественных критериев для модификации Гражданский кодекс не содержит. В этом проявляются первые существенные противоречия с основными положениями авторского права.
Одно из таких противоречий состоит в отсутствии у авторов программ для ЭВМ права на неприкосновенность произведения, несмотря на отнесение самих программ для ЭВМ под защиту авторского права. Под переработкой программ для ЭВМ (модификацией) понимается как раз то, что для любого другого объекта авторских прав было бы расценено как покушение на неприкосновенность произведения. При этом в ст. 1266 ГК РФ «Право на неприкосновенность произведения и защита произведения от искажений» никаких исключений для компьютерных программ, в отличие от статьи 1269 ГК РФ «Право на отзыв», не сделано.
Если отсутствие права на неприкосновенность произведения при отсутствии соответствующего исключения в ст. 1266 ГК РФ можно посчитать недостатком юридической техники, то второе противоречие позволяет говорить о несоответствии модификации компьютерных программ переработке классических объектов авторского права и недопустимости одинакового регулирования двух явлений. Дело в том, что единственный критерий охраноспособности произведения механизмами авторского права, упомянутый в ст. 1257 ГК РФ, гласит, что «автором произведения … признается гражданин, творческим трудом которого оно создано».
Совсем иной критерий охраноспособности к модифицированному, а, следовательно, и самостоятельному производному произведению предъявляет подп. 9 п. 2 ст. 1270 ГК РФ: «Под переработкой (модификацией) программы для ЭВМ или базы данных понимаются любые их изменения». Нет никаких объяснений, почему программ для ЭВМ установлены иные, более мягкие по отношению ко всем объектам авторского права критерии создания и охраны такого производного произведения.
Особенно интересно эта норма ГК РФ смотрится с учетом следующих положений.
Пунктом 88 вышеупомянутого Постановления Пленума установлено, что для использования производного произведения необходимо получение от правообладателя права на переработку. При этом отдельного разрешения на использование, включая распространение, этого производного произведения от правообладателя использованного произведения не требуется.
Гражданский кодекс содержит следующее указание на связь производного и использованного произведения в п. 3 ст. 1260 ГК РФ: автор производного произведения осуществляет свои авторские права при условии соблюдения авторских прав авторов использованных произведений. К авторским правам согласно ст. 1255 ГК РФ относятся:
исключительное право на произведение;
право автора на имя;
право на неприкосновенность произведения;
право на обнародование произведения.
Так как статья 1260 ГК РФ указывает именно на соблюдение авторских прав авторов, из этого можно сделать вывод, что указанная норма направлена на защиту личных неимущественных прав авторов, а также исключительных, но только в том случае, если автор и является правообладателем. Так, например, переводчик в ходе создания производного произведения – перевода – обязан соблюдать право автора на неприкосновенность используемого произведения. Также при переработке ГК РФ требует соблюдать право авторства и права автора на имя и отзыв. Право на обнародование произведения предполагается использованным до того, как третье лицо получило возможность использовать произведение при создании производного.
Таким образом, для подавляющего числа программ для ЭВМ ст. 1260 ГК РФ будет применяться только в части права авторства и права автора на имя. Это связано с тем, что исключительное право на большинство программ, участвующих в гражданском обороте, принадлежит юридическим лицам. Прав на неприкосновенность и на отзыв произведения, как было сказано выше, авторы программы для ЭВМ лишены.
Исходя из буквального прочтения норм Гражданского кодекса и Постановления Пленума Верховного Суда, можно заключить, что получив разрешение от правообладателя на модификацию программы для ЭВМ и дополнив исходный текст программы для ЭВМ любым символом, «автор модификации» вправе распоряжаться программой как новым произведением, заявляя, что именно он и является правообладателем всей программы. Единственное требование для такого автора модифицированной программы будет заключаться в указании авторов использованной программы.
Предоставляя разрешение на модификацию программы для ЭВМ – явление совершенно естественное для любой компьютерной программы на протяжении всего жизненного цикла – правообладатель должен закрепить в договоре, что права на модифицированное программное обеспечение принадлежат именно ему, так как в противном случае разрешение на осуществление модификации влечет за собой возникновение исключительного права на программу, даже незначительно отличающуюся от первоначальной. Это имеет для правообладателя эффект дублирования принадлежащей ему программы, потерю полного контроля над ней и возникновение на рынке конкурента, который на законных основаниях распространяет модифицированную программу.
Такой подход является релевантным для литературных произведений, где в результате переработки образуется принципиально новый объект интеллектуальной собственности: автор литературного романа единожды дает свое согласие на экранизацию, после чего правообладателями фильма становятся авторы производного произведения. Но почему такой же подход должен применяться и к программам для ЭВМ, если в результате переработки программы для ЭВМ она остается все той же программой, но в новой версии?
Другой вопрос, который возникает при прочтении подп. 9 п. 2 ст. 1270 ГК РФ, заключается в исключении, которое законодатель сделал для адаптации. Согласно норме закона «адаптация, то есть внесение изменений, осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя», не признается переработкой программы для ЭВМ. Пунктом 3 ст. 1280 ГК РФ пользователю, правомерно владеющему экземпляром программы для ЭВМ, предоставлено право на осуществление адаптации. Это объясняется тем, что законодатель считает адаптацию компьютерной программы способом, решением технической задачи, заключающейся в обеспечении совместимости программы для ЭВМ с конкретным оборудованием или конкретной программой, под управлением которой эта программа должна работать. Однако остаётся неясным, почему законодатель в принципе не признает адаптацию модификацией программы для ЭВМ? Гораздо более логичным было бы сказать, что адаптация – это разрешенный для пользователя вид модификации.
Также вызывает удивление, что буквально перед исключением из модификации адаптации ГК РФ особенно подчеркивает «в том числе перевод такой программы или такой базы данных с одного языка на другой язык». Следует отметить, что перевод компьютерной программы с одного языка на другой – не то же самое, что перевод литературного произведения. В отличие от литературного перевода перевод с одного языка программирования на другой не требует лингвистической подготовки, творческих способностей, чувства языка, а является, как и адаптация, решением технической задачи, направленной на обеспечение совместимости программы для ЭВМ с конкретным оборудованием или конкретной программой, под управлением которой эта программа должна работать.
Кроме того, признание модифицированной программы для ЭВМ новым производным произведением на практике приводит к тому, что пользователь компьютерной программы при выпуске нового обновления, даже если это обновление было выпущено самим правообладателем, вынужден заключать новый лицензионный договор уже на новое произведение, что создает необоснованные сложности для рынка программ для ЭВМ.
Таким образом, буквально каждое слово нормы, регулирующей модификацию программы для ЭВМ, может быть подвергнуто критике как с точки зрения природы явления, так и с точки зрения доктрины авторского права и требований рынка. Это создает предпосылки для внесения изменений в существующее регулирование модификации компьютерных программ.
Сегодня законопроект предлагает удобное решение проблемы, связанной с необходимостью заключать новый лицензионный договор после каждого обновления.
Вторым изменением, связанным с модификацией, в предлагаемом законопроекте является нововведение о степени изменений компьютерной программы, необходимой для признания таких изменений созданием нового результата интеллектуальной деятельности. В соответствии с предлагаемой редакцией ГК РФ, стороны договора на создание модифицированной версии программного обеспечения вправе сами установить степень изменений, при которых результат модификации компьютерной программы или базы данных будет представлять собой новый самостоятельный объект авторского права.
Если же изменение исходного текста программы совершено без санкции правообладателя, то переработкой программы для ЭВМ законопроект продолжает считать любое изменение компьютерной программы. Важно отметить, что законопроект предлагает считать модификацию переработкой в любом случае, но по договоренности сторон результат модификации может не признаваться самостоятельным производным произведением. То есть возможна ситуация, при которой автор модифицированной программы не признаётся таковым несмотря на то, что модификация было произведена, и творческий вклад авторов модифицированной версии никем не оспаривается.
Из пояснительной записки к законопроекту следует, что такое размытие термина «модификация» предлагается «для определенности в отношении наличия у них [пользователей] прав на те или иные варианты программы или базы».
Это пояснение неоднозначно.
Если между сторонами заключен договор на выполнение работ по модификации, то по умолчанию в силу ст. 1296 ГК РФ исключительное право на программное обеспечение принадлежит заказчику. Если же стороны с этим не согласны, то у них должно быть и техническое задание, в котором предусмотрен объём изменений, вносимых в компьютерную программу, и условия договора о распределении прав на модифицированную программу. Возможность определять степень, при которой модифицированная программа не является производным произведением, ясности не вносит, а вызывает дополнительные вопросы.
Если же правообладатель предоставил лицензиату право переработки программы для ЭВМ, то вопросов возникает ещё больше. Почему автор модификации не получает даже таких личных неимущественных прав на производное произведение, как право авторства и право автора на имя?
Есть ли какая-то минимальная степень изменений, которая вне зависимости от договоренностей будет порождать создание новой программы, или стороны могут договориться о том, что только при изменении 99% исходного текста будет создана производная программа, а при изменении 98% программа все ещё старая? При таком регулировании автор модификации, произведенной без согласия правообладателя, получает больше прав, чем автор модификации, санкционированной правообладателем, – по крайней мере, он признается автором нового объекта прав, и получает авторские права, в том числе исключительные, хотя и не может использовать их.
Можно заключить, что рассматриваемый законопроект предлагает удачные положения о версиях программ для ЭВМ и делает шаг в сторону более удобного регулирования модификации компьютерных программ, но некоторые его положения достаточно спорны, а большая часть действующих норм ГК РФ, регулирующих модификацию, останутся нетронутыми.
Статью 1266 ГК РФ «Право на неприкосновенность произведения и защита произведения от искажений» необходимо дополнить нормой, аналогичной пункту 2 ст. 1269 ГК РФ «Право на отзыв»: «Правила настоящей статьи не применяются к программам для ЭВМ».
Наиболее существенное изменение должно коснуться ст. 1280 ГК РФ, которая должна предоставлять лицу, правомерно владеющему экземпляром программы для ЭВМ, право вносить в такой экземпляр любые изменения, необходимые для удовлетворения нужд пользователя (вне зависимости от того, является пользователь физическим или юридическим лицом), без права дальнейшего распространения своей версии программы без разрешения правообладателя. Также пользователю должно быть предоставлено право привлекать третьих лиц для внесения таких изменений, а третьи лица, соответственно, должны быть вправе предлагать к продаже свои работы по модификации программного обеспечения, правообладателем которых они не являются. Исключение может быть сделано для ситуации, когда внесение изменений в программу для ЭВМ может повлиять на работу других пользователей этой же программы. В таком случае внесение изменения в программное обеспечение пользователем может влиять на качество продукта, что может повлечь негативные последствия для правообладателя. Также следует отметить, что если пользователь вносит собственные изменения в исходный текст программы, любые гарантийные обязательства правообладателя, которые были даны пользователю, должны быть прекращены.
В текущей редакции указанной статьи пользователю частично предоставлено право осуществлять адаптацию используемой программы. Частично – потому что согласно ст. 1270 ГК РФ под адаптацией понимается внесение изменений в программу, «осуществляемых исключительно в целях функционирования программы для ЭВМ или базы данных на конкретных технических средствах пользователя или под управлением конкретных программ пользователя». В то же время подп. 1 п. 1 ст. 1280 ГК РФ позволяет пользователю вносить изменения в программу в целях её функционирования на технических средствах пользователя (то есть это положение частично разрешает адаптацию программы для ЭВМ) и исправление явных ошибок (то есть частично разрешена и модификация).
Вероятно, здесь допущена техническая ошибка, в противном случае между подп. 9 п. 2 ст. 1270 и подп. 1 п. 1 ст. 1280 ГК РФ имеется противоречие: для чего потребовалось делать исключение для адаптации в ст. 1270 ГК РФ, если далее в ст. 1280 ГК РФ законодатель разрешил её лишь частично.
Возвращаясь к вопросу о том, следует ли предоставить правомерно владеющему пользователю программы для ЭВМ право изменять её под собственные нужды, необходимо вновь обратить внимание на сущность компьютерных программ. Как уже говорилось, программы для ЭВМ в большинстве своем имеют утилитарную цель: они используются на производстве, в банковской деятельности, для организации процессов и хранения данных в любых отраслях экономики, на государственной службе и т.д. В этом смысле компьютерная программа является технологией, что роднит её скорее с изобретением, чем с литературным произведением. При этом ни в случае с зависимым патентом, ни с модифицированной программой не создается принципиально нового объекта, как с переработкой объекта авторского права. Но осуществляется развитие уже существовавшего, в связи с чем конкретно в рассматриваемом вопросе именно институты патентного права больше подходят для регулирования модификации программы для ЭВМ, чем средства авторско-правовой защиты. Если пользователь изобретения, уплачивающий правообладателю роялти, имеет полное право осуществлять любые изменения с запатентованным решением и даже вправе получить патент на зависимое изобретение (ст. 1358.1 ГК РФ), то почему аналогичного права лишен пользователь программы для ЭВМ?
Ответ очевиден: модифицированная программа признается производным, а значит новым произведением. Но если попробовать отказаться от этого подхода?
Безусловно, правообладатель программы для ЭВМ должен получить эксклюзивное право пожинать плоды осуществленного им труда, подобно тому, как аналогичное право предоставляется патентообладателю. Но в то же время патентообладателям не предоставляется исключительное право производить улучшения своих изобретений. Любое лицо, правомерно использующее запатентованное изобретение, имеет право его улучшать. Почему же правообладатели программ для ЭВМ должны иметь настолько сильную защиту, что внесение любых, даже самых минорных изменений в правомерно используемую технологию должно рассматриваться как нарушение исключительного права?
Открытие рынка модификации (без предоставления пользователю права дальнейшей реализации модифицированных программ), в конечном итоге было бы на пользу всем участникам оборота программного обеспечения: и пользователю, который сможет самостоятельно доработать программу под себя и не должен будет платить и ждать, пока правообладатель внесет нужные ему изменения в компьютерную программу, и самому правообладателю, на развитие продукта которого отныне будет работать не только штат его сотрудников; но и все пользователи программного обеспечения и третьи лица, которым пользователи поручат такую модификацию. Более того, такое решение ускорило бы технический прогресс, так как лишившись монополии на будущие обновления, правообладатель будет вынужден конкурировать с иными разработчиками, которые также будут осуществлять улучшения лицензируемой программы. Конечно, правообладатель как лицо, более глубоко знающее механизмы работы программы, будет иметь явное преимущество, но сам факт наличия конкуренции, станет дополнительным стимулом для развития рынка программ для ЭВМ в целом.
Исходный код программы требовал доработки
В одном из приведённых ниже предложений НЕВЕРНО употреблено выделенное слово. Исправьте лексическую ошибку, подобрав к выделенному слову пароним. Запишите подобранное слово.
Его ИЗОБРЕТАТЕЛЬСКИЙ ум и способности позволяли безбедно существовать и ему самому, и семье: кажется, у Ивана было врождённое чувство быть в нужном месте с нужной идеей.
После работы просыпался, как говорят, ЗВЕРСКИЙ аппетит, и он, этот аппетит, требовал котлет или хотя бы колбасы.
Фигурки шахмат были КОСТЯНЫМИ, очень дорогими, то ли из слоновой кости, то ли из самого мамонта, и Костя очень дорожил ими.
ИСХОДНЫЙ код программы требовал доработки.
Из окна многоэтажки был виден ЛЕСНОЙ массив: это было фантастически необыкновенно и почти невероятно.
Пояснение (см. также Правило ниже).
Ошибка допущена в предложении Его ИЗОБРЕТАТЕЛЬСКИЙ ум и способности позволяли безбедно существовать и ему самому, и семье: кажется, у Ивана было врождённое чувство быть в нужном месте с нужной идеей.
Здесь необходимо слово ИЗОБРЕТАТЕЛЬНЫЙ (находчивый, быстрый на выдумки, способный изобретать).
Паронимы — это слова, близкие по звучанию, но различающиеся (частично или полностью) значением.
Иногда в нашей речи встречаются слова, похожие по звучанию, но различающиеся оттенками значения или вовсе разные по семантике. Среди лексических ошибок, вызванных незнанием точного значения слова, наиболее часто встречаются ошибки, связанные с неразграничением, или смешением паронимов.
Паронимами можно назвать как однокоренные, так и близкие по звучанию слова, которые при всей своей похожести всё же различаются оттенками значения или обозначают разные реалии действительности.
В «Методических рекомендаций ФИПИ» отмечается:
«Анализ выполнения задания 5 показал, что сложность для 40% испытуемых составляет не только распознавание ошибки, допущенной при употреблении паронимов, но и подбор соответствующего контексту паронима для редактирования примера с ошибкой, что обнаруживает узость словарного запаса экзаменуемых.» В помощь учащимся в подборе слов-паронимов ежегодно издаётся «Словарик паронимов». Он не зря называется именно «словариком», так как «Словари» содержат тысячи слов-паронимов. Включённый в состав словарика минимум будет использоваться в КИМах, но ведь выучить паронимы для задания 5 — это не самоцель. Эти знания позволят избежать многочисленных речевых ошибок в письменных работах.
Обращаем внимание на то, что в заданиях РЕШУЕГЭ есть задания прошлых лет, и в них встречаются слова не из этого списка.
Записывайте слово в той форме, что требуется в предложении. Это требование основано на том, что в правилах заполнения бланков указано: если кратким ответом должно быть слово, пропущенное в некотором предложении, то это слово нужно писать в той форме (род, число, падеж и т. п.), в которой оно должно стоять в предложении.
Словарик паронимов ЕГЭ. Русский язык. 2019 год. ФИПИ.
Техническое задание на доработку: 10 правил и немного занудства
Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.
Грани взаимодействия
Прежде, чем приступить к препарации процесса создания технического задания, поговорим о четырёхугольнике, в который попадают исполнитель и заказчик, приступая к проекту.
Требования — желаемое поведение системы, описанное заказчиком или холдером процесса, подлежащее реализации. Как правило, требования формируются на основании опыта работы, представления правильного поведения программы. Это ключевая информация для разработчика (вендора), однако именно на этапе сбора требований возникает самое большое число коллизий, ошибок, излишних запросов и проч.
Ресурсы — люди, машины, инвентарь, среда разработки, время и деньги, которые должны использоваться в процессе реализации требований. Ресурсы требуют чёткого планирования и оценки на этапе согласования технического задания. Грамотная расстановка приоритетов со стороны заказчика и распределение трудовых ресурсов со стороны вендора позволяют избежать срыва сроков и минимизировать иные риски.
Возможности — если кратко, то это то, что реально может сделать вендор (исполнитель). Рассмотрим на примере нашей RegionSoft CRM. Клиент покупает систему и составляет техническое задание на доработку: нужно создать интеграцию с сайтом и привязку событий в CRM к номеру заказа интернет-магазина. Это реально исполнимое требование, у нас есть ресурс и возможность сделать это. А ещё нужно разработать и прикрутить к CRM CMS, систему управления контентом сайта. Теоретически мы это можем, но у нас нет возможности это сделать дёшево, а у клиента нет возможности заплатить нам столько, чтобы мы перекинули на задачу человеческие и временные ресурсы. В итоге от этого требования заказчик отказывается — да и CMS ему не особо нужна, всё и так хорошо. Но о «жадности» ТЗ— позже.
Ограничения — набор препятствий, которые делают выполнение задач из ТЗ затруднительным или невозможным: бюджет, стек технологий, лицензионные проблемы, законодательные запреты, аппаратные конфигурации и проч.
Таким образом, все четыре сущности тесно переплетаются между собой и определяют успех проекта в целом. Рассмотрим каждый элемент и попробуем выделить критические моменты, которые нужно иметь ввиду, работая над техническим заданием.
Сбор и анализ требований
Это очень важный внутрикорпоративный процесс, в ходе которого выясняется, чего хотят от программы (здесь и далее возьмём CRM, но методы работают и с другими типами софта) потенциальные пользователи. Если вы обратитесь к крупному вендору типа SAP или системному интегратору, то с высокой долей вероятности вам предложат воспользоваться услугами бизнес-консультанта (он же персональный менеджер, он же аккаунт-менеджер, он же «теперь ваш представитель в нашей компании»). На самом деле, в большинстве случаев это обычный вышколенный продажник, у которого две задачи: накрутить стоимость проекта и не дать вам сорваться с крючка.
Он находится здесь уже целый час и даже не притронулся к белой маркерной доске. Он не настоящий системный аналитик
Лучше, чем вы и ваши сотрудники, вашу компанию не знает никто. А значит, сбор и анализ требований — исключительно ваша задача, в которой вендор может помочь и направить, но ни в коем случае не вмешаться в процесс. Расспросите разработчика о подобных внедрениях, уточните, на что обратить внимание и приступайте. Кстати, неплохим помощником может быть ваш сотрудник, который хорошо разбирается в профильной теме и примерно представляет архитектуру ПО и знаком с процессом разработки — он может выступить в роли аналитика и внутреннего эксперта, замкнуть на себе процесс создания ТЗ и общения с вендором.
Есть очень простая схема сбора требований.
Анатомия технического задания
Если говорить о процессе создания технического задания, то существует несколько этапов. Их последовательное прохождение и приводит заказчика к желаемой доработке. Вот они.
Уровень бизнеса — самый глобальный уровень, на котором решаются сложные и приоритетные задачи. К этому уровню можно отнести интеграции, доработки и моделирование бизнес-процессов, разработку новых функциональных модулей. Как правило, это ресурсоёмкая разработка, с серьёзными консультациями и тесной совместной работой с заказчиком. Например, в своё время в RegionSoft CRM такой заказной доработкой были складской учёт, касса и производство. Постепенно изменения вошли в релиз, а позже позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов — RegionSoft Retail.
Уровень пользователя или группы пользователей. На этом уровне реализуются задачи по доработке существующего интерфейса. Например, пользователь может захотеть, чтобы при наведении курсора на клиента появлялось окошко со номером и статусом последнего заказа или существовал кастомный отчёт с особой группировкой данных. Доработки на этом уровне занимают меньше времени, но их может быть много — например, несколько требований от отдела маркетинга, логистики и технической поддержки.
Уровень функциональности. Зачастую его трудно отделить от предыдущего, здесь работает формальный критерий — доработка не на уровне отображения чего-либо в интерфейсе, а на уровне доработки логики системы. Сюда можно отнести требования к различного рода сортировкам, интеграциям с чатом, возможностям телефонии.
Уровень сервиса — на самом деле, требования этого уровня должны первыми попадать в новые сборки с фиксами. Это задачи по скорости отклика системы, работе под высокой нагрузкой, безопасности. В идеальном варианте у вендора не должно быть таких доработок — корпоративный софт не должен тормозить, терять данные, схлопывать формы и раздавать права доступа одного уровня. Но если требование появилось, и оно не связано с персональной паранойей заказчика или проблемами на стороне аппаратного обеспечения, стоит уделить ему повышенное внимание.
Уровень технологии — последний в списке, но по важности и сложности опережающий остальные. Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS. Очень здорово, если такие требования постепенно перерастут в релизы, но иметь их фиксы обязательно. Именно из запросов клиентов на этом уровне мы сделали сборку RegionSoft CRM под MacOS и добавили удалённый доступ по технологии TRM как временное решение редкого, но существующего запроса мобильной версии.
Анатомия технического задания проста, во всяком случае в виде скелета. Обязательные части технического задания помогают заказчику сосредоточиться на проблеме и сформулировать задачу правильно, а исполнителю — понять, что же от него хотят. Кстати, о понимании. Конечно, в начале поста мы немного слукавили, отрицая бизнес-консультантов как класс. Дело вот в чём: каждый вендор работает на рынке по несколько лет (мы сейчас не о CRM-однодневках), а то и десятков лет, а значит имеет набор кейсов практически по каждой отрасли. Соответственно, и инженеры, и программисты, и продажники знакомы со спецификой внедрения в каждом типе компании. Но опять-таки, важно ориентироваться именно на свой бизнес.
Для кого? В этом разделе нужно описать, кто будет конечным пользователем доработки, какие задачи и с какой периодичность планируется решать.
Приведу пример. В одной компании внедряли CRM, предполагалась работа на довольно большом массиве данных (несколько десятков миллионов записей в месяц, несколько сотен тысяч записей в день). Начальник отдела продаж запросил отчёт по выгрузке этих записей с периодичностью «ежедневно». Естественно, что такой отчёт при одновременной работе сотни пользователей нагружал систему — были найдены решения по оптимизации процесса. Уже в ходе работы выяснилось, что продажник перестраховался и отчёт нужен ему только по итогам месяца, и то его можно запускать по расписанию ночью. Стоит ли говорить, что время и деньги были потрачены зря.
Зачем? Обоснование необходимости доработки и его место в бизнес-процессе. Этот пункт больше нужен самому заказчику, но и вендору нелишне знать, какие ещё процессы будут затронуты. Иногда это помогает найти альтернативное решение.
Что должно делать? Самый информативный блок — в нём описываются требования, ожидания от системы. И вот тут случаются тем самые перлы, чудеса и коллизии, которые впору отправлять на башорг, и которые ну очень усложняют жизнь. Причина одна — пользователь не знает, чего он хочет, что нужно сделать. Есть ещё маленькая подпричина — пользователь не может сформулировать требования. И тут задача разработчика (рабочей группы, аналитика, если он есть) помочь сформулировать потребность верно, выбрать целесообразное требование, вписать задачу в контекст работы системы. В этом же блоке нужно упомянуть ожидаемый результат.
Параметры технического задания — сроки, этапы реализации, ответственные от всех сторон, необходимые контакты и проч. Фактически это совокупность важных формальных вещей, делающих документ техническим заданием. Техническое задание обязательно должно быть согласовано и подписано сторонами во избежание многочисленных изменений по ходу разработки (они всё равно будут, но в меньшем объёме).
В идеальном варианте техническое задание составляется при активном участии вендора, и его итог представляет собой примерно такую структуру:
10 правил, написанных слезами разработчика
Техническое задание на доработку должно быть ТЗ на доработку, а не 300-страничным описанием CRM, которая необходима клиенту. Перед составлением требований следует внимательно ознакомиться с интерфейсом системы, её возможностями, документацией — скорее всего, большая часть «хотелок» уже есть в базовой поставке. Вторым шагом я бы рекомендовал обратить внимание на встроенные инструменты доработки (дизайнеры отчётов, конфигураторы и проч.) — возможно, нужные изменения сможет внести штатный программист (во многих компаниях они есть).
Техническое задание не должно быть жадным. Нередко бизнес переоценивает свои возможности или желает получить «всё и сразу». Такой подход не оправдан ни с точки зрения денег, ни с точки зрения бизнеса. Вендор, как правило, существует не пару недель (в случае RegionSoft — 15 лет), и к нему можно обратиться и через некоторое время, когда вы уже реально поймёте, чего в CRM не хватает.
Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы?
Например, RegionSoft CRM — десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же — в общем случае требование невыполнимое.
Не нужно путать с ситуацией, когда речь идёт о заказной разработке и в корне меняется идея и логика работы приложения, фактически спонсируется создание нового программного обеспечения «под себя». Но это другая история.
Техническое задание должно быть подробным. Нужно указать все значимые детали будущего проекта: от периодичности использования программы до пожеланий по интерфейсу. Чем подробнее будут изложен требования, тем проще и быстрее пройдут реализация и тестирование. Особо стоит уделить внимание деталям, если вы работаете в специфичной отрасли (медицина, страхование, банки) — подробное изложение нюансов взаимодействия бизнеса и программы обеспечит понимание задачи вендором и быструю адаптацию системы к вашей компании.
Обязательно обратите внимание на форматы чисел, названия полей, наличие или отсутствие выпадающих списков, поведение кнопок и хинтов, типы данных. Если заказчик использует собственные формулы, которые необходимо заложить в логику работы CRM (например, расчёт дилерских бонусов), эти формулы должны быть прописаны с полной расшифровкой их обозначений и логики расчёта.
Да, корпоративный софт выглядит примерно так, и в нём много важных мелочей
Техническое задание должно быть однозначным и точным. Расплывчатые формулировки, варианты реализации, нечёткие требования — всё это путь в тупик. Бывает, что клиент из благих намерений пишет в ТЗ несколько вариантов поведения системы, близких, но не равнозначных. В этом случае он уверен, что помогает, подсказывает программисту, но на самом деле благими намерениями устлана дорога в ад разработчик должен понимать, что именно нужно, а как это сделать он выберет сам, исходя из особенностей системы и стека используемых технологий.
В этом году ты можешь снова загадать одно желание. Только, прошу, не трать его на то, что даже я не смогу выполнить, типа понятных бизнес-требований!
Техническое задание должно быть написано на человеческом языке. И это важно, нет, ВАЖНО. Выделю две ситуации, когда проблемы с языком приводят к затягиванию реализации проекта.
Техническое задание не должно быть жалобной книгой. Нужно решать проблему, а не описывать её, уделяя внимание шрифтам и забывая об описании требований. ТЗ должно содержать не только саму проблему, но и её решение на уровне осмысления — далее разработчик уже решит её на уровне кода. Сравните «отдел продаж плохо планирует, теряет цифры, уже год боремся» и «необходимо создать отчёт, который будет сохранять значения плана и факта продаж ежемесячно, в разрезе групп номенклатуры».
Техническое задание должно уметь смотреть в будущее. Ну не совсем оно, а люди, стоящие за ним. Если известно, что в скором времени будут происходить изменения в бизнес-процессах, это нужно обязательно учитывать, чтобы не платить за доработку дважды.
Техническое задание не должно быть бюрократичным. Если вы хоть раз составляли этот документ, то наверняка ощущали, как тяжело избежать соблазна скатиться в бюрократию, наворотить вводных слов, строгих оборотов и описать каждый пункт как статью Уголовного кодекса (желательно с наказанием всем за нарушение). Бюрократические формулировки маскируют неполное понимание целей создания ТЗ. Ответственность вендора прописана в договоре, там же написан бюджет. Не стоит переносить эти моменты в техническое задание.
Техническое задание должно быть техническим заданием. Звучит парадоксально, но часто вместо ТЗ мы читаем письма, жалобы, договоры, заново написанную инструкцию к CRM или протокол совещания. Конечно, работать по такому документу невозможно. Для того, чтобы не уйти от формы и содержания, воспользуйтесь старой школьной уловкой: рассмотрите термин по словам. Техническое — значит, диктует доработку, технику, направлено на решение задачи посредством изменения ПО. Вот о задаче в контексте ПО и нужно говорить. Задание — значит, постановка вопроса, проблемы, без советов, подсказок и предварительных оценок. Просто формулировка задачи.
Заповеди закончились, теперь отповедь
Кроме перечисленных правил, есть ещё несколько вещей, о которых стоит рассказать. Речь идёт о целях, планах и ожиданиях — всех тех оставляющих, которые делают проект успешным, а отношения вендора и клиента почти дружескими.
Техническое задание нужно писать быстро, даже если перед вами стоит задача автоматизации процессов сотового оператора или крупного гипермаркета. Это связано с тем, что технологии развиваются с огромной скоростью и даже та система, которую вы внедряете, за полгода-год может пережить мажорный релиз (а иногда и два), получить новую функциональность. Возможно, придётся пересмотреть необходимость доработок и начать процесс заново.
Наконец он нашёл время закончить ТЗ. Но, увы, вокруг не осталось разработчиков, чтобы его реализовать.
Клиент не знает о стеке и технических ограничениях. И знать не должен — это задача вендора, именно он оценивает работы после составления технического задания. Заказчику не стоит углубляться в технологии и на каждой запятой спрашивать, сможет ли вендор сделать ту или иную вещь. Составьте комплексное ТЗ и разработчик выберет подходящую архитектуру — нередко даже лучшую, чем вы могли подумать.
Оценить бюджет и избежать неприятных сюрпризов — едва ли не совместная задача номер один. Не стоит дёргать вендора и требовать от него примерной оценки работ (ну хоть приблизительно, навскидку, на глазок, а как у других, ну в проектах такого типа, а по опыту, ну так, в пределах погрешности). Полная оценка бюджета возможна только после прочтения, анализа и окончательного утверждения технического задания. Если ваш разработчик поступает иначе — готовьтесь к тому, что доработка обойдётся минимум в два раза дороже.
Исходите из объективной необходимости изменений и расширений — выше я писал, что разработчик не исчезает и готов внести изменения и дополнения по вашим требованиям в любой момент. Поэтому не пытайтесь создать CRM/ERP мечты сразу, не требуйте от вендора кнопку «Всё работает, пока я пью кофе» — поработайте в системе, определите критичные для вас замечания и приступайте к сбору требований и составлению ТЗ.
Ну а если вам нужна CRM-система (с доработкой или без), то заходите на наш сайт, там много о CRM, её преимуществах и прочем корпоративном софте.