Словарик айтишника или Что? Где? Куда? Часть 1
«Привет! Добро пожаловать! Спасибо, что приняла наш оффер. Пойдем знакомиться с твоей командой. У них как раз сейчас дейли. Ты вышла под конец спринта, поэтому пока работы для тебя не запланировали. Как стендап закончится, можешь почитать спеки, командные окиары и просмотреть бэклог на следующий спринт. По всем вопросам обращайся к своему пио.»
Язык айтишников
Каждый, кто работает в IT, непременно сталкивался с профессиональным жаргоном и компьютерным сленгом. Его можно любить или ненавидеть, принимать или терпеть, но непреложным остается факт — IT-жаргон существует и от него никуда не деться.
Когда приходишь в новую компанию, на тебя наваливается куча незнакомых слов. Кажется, их так много, что потребуется немало времени, чтобы понять и выучить их все. Многие слова ты уже знаешь, о смысле других догадываешься, часть из них является англицизмами, поэтому догадаться об их значении несложно Первая реакция — неприятие: «Зачем использовать английские слова в русский речи, когда есть достаточно русских альтернатив?» Потом ты пытаешься сохранить чистоту языка. В итоге, начинаешь говорить так же, как и все. Это неизбежно.
Профессиональный жаргон существует не для того, чтобы испортить русский язык. Он позволяет ускорить устное общение IT-специалистов и наладить их взаимопонимание. Обычно слова получаются короткими и емкими. Иногда одно слово заключает в себе целую фразу. Поэтому польза в них, на мой взгляд, есть.
Я послушала, как говорят разработчики в Wrike, и составила словарик из самых распространенных слов. Слова собраны по тематическим группам.
Scrum-терминология
Scrum — это методология по управлению проектами. Набор принципов, ценностей, политик, ритуалов для организации работы. В скраме полно терминов, но в ежедневный обиход попала и закрепилась только часть из них.
Бэклог
От англ. backlog (дословно — очередь работ) — еще не запланированный объем работы, который требуется выполнить команде. Каждая созданная задача вначале попадает в бэклог, а потом уже в спринт.
Как и в случае со спринтом, термин используется и в отрыве от скрама. Часто бэклогом называют отложенные задачи. Которые сделать нужно, но не сейчас.
Гол, голевой
От англ. goal (дословно — цель) — цель спринта (бывает одна или несколько), которую команда берется сделать. Цель состоит из ряда задач, которые нужно выполнить, чтобы его достигнуть.
Слово употребляется и как существительное, и как прилагательное. Может быть множественного числа.
Дейли
От англ. daily (дословно — ежедневно) — ежедневные короткие (от 5 до 30 минут) встречи команды с целью поделиться прогрессом по выполненным задачам за предыдущий день и озвучить план работ на текущий день. Также дейли могут называть стендапом (от daily standup), потому что обычно такие встречи происходят стоя — для большей эффективности.
Коммититься
Глагол от англ. существительного commitment (дословно — ответственность). Коммититься — значит обещать выполнить определенный объем работы в оговоренные сроки. Это не просто обещание, это сознательное обязательство перед собой и командой. Человек, который закоммитился, обязан сделать всё возможное, чтобы выполнить то, что сам и пообещал реализовать.
Спринт
От англ. sprint (дословно — бег на короткую дистанцию) — заданный отрезок времени, за который нужно выполнить запланированный объем работы, чтобы в конце этого отрезка был ожидаемый результат.
Термин используют не только те, кто работает по скраму, но и те, кто просто хочет организовать свою работу и сформировать ясные рамки, во время которых должны быть выполнены задачи.
Инструменты для работы
Технические, информационные и вспомогательные средства и приложения для работы.
Ветка
От англ. branch (дословно — ветка) — тот редкий случай, когда в ходу русский перевод термина. Веткой (термин git) называют полную копию проекта, в которой ведется разработка. В проекте может быть создано много веток, что позволяет работать одновременно с разными частями кода. Потом все ветки загружаются в мастер. Процесс «ответвления» иногда называют «бранчеванием», уже как раз от branch.
От англ. mock-up (дословно — эскиз) — макет с UX-дизайном для разработки. Несмотря на то, что слово дословно переводится как «эскиз» или «прототип», в Wrike моками называют готовые проработанные макеты с дизайном.
От англ. production (дословно — промышленная среда) — ветка с рабочей версией продукта, которую видят пользователи. Это окончательная точка куда попадает результат разработки. Иногда так же называют мастер.
От англ. reference (дословно — пример) — схожий функционал или внешний вид, который используется для ориентира. Он служит для сравнения.
Спека
От англ. specification (дословно — спецификация) — документ с подробным описанием требований, условий и технических характеристик, как должен работать разрабатываемый функционал.
Таска
От англ. task (дословно — задача) — задача, заведенная или планируемая на любого работника.
Разработка
Термины, употребляющиеся разработчиками при работе над задачами.
От англ. boost (дословно — ускорение) — процесс повышения производительности, ускорение загрузки.
Катить
Отправлять готовую работу в деплой, предпринимать шаги для подготовки ветки к мерджу в продуктовую ветку.
Комплитить
От англ. complete (дословно — заканчивать) — завершать задачу, закрывать задачу, когда она полностью готова.
Консистентность
От англ. consistency (дословно — системность) — общее единообразие во всех частях продукта.
Матчится
От англ. match (дословно — совпадать) — полное соответствие чего-либо с чем-либо. Процесс приведения к единообразию.
Пинать
Термин, подобный глаголу «пинать», который также имеет значение «делать» и «работать». Конкретное значение определяется по приставке. Подопнуть — сделать немного, допинать — доделать.
Ручка
От англ. handler (дословно — обработчик) — бэкэнд-термин, означающий ответ от сервера, в котором приходят данные.
Скоуп
От англ. scope (дословно — объем) — набор фич и частей продукта, закрепленных за отдельной командой.
От англ. feature (дословно — характеристика) — определенная часть или деталь от общего продукта, которая разрабатывается изолированно.
От англ. flow (дословно — течение) — порядок действий при работе над задачей. Например, вначале задача берётся в разработку, потом проходит ревью, далее тестируется и т.д.
Должности
Некоторые должности, названия которых вошли в обиход в виде сокращений с английского.
Девопс
От англ. DevOps, сокращенно от Developer Operations (дословно — интеграция разработки и эксплуатации) — специалист, занимающийся внедрением DevOps-методологии. Полное название должности — DevOps-инженер, но в речи вторую часть всегда отбрасывают.
От англ. PO, сокращенно от Product Owner (дословно — владелец продукта) — роль по скрам-методологии, человек, ответственный за проработку продукта и распределение бэклога. Он знает о требованиях пользователя и возможностях команды.
От англ. PM, сокращенно от Product Manager (дословно — менеджер продукта) — менеджер, который отвечает за продукт, его обязанности совпадают с обязанностями пио, отличие только в том, что это название должности, а не роли в скраме. Так же, как пио, пиэмов могут называть продакт.
Организационное
Термины, относящиеся к организации работы, а также термины, употребляющиеся в неформальной речи при обсуждении чего-либо.
Дейоф
От англ. day-off (дословно — выходной) — просто выходной.
Драйвер
От англ. driver (дословно — водитель) — человек, который берет на себя инициативу управления проектом/процессом/задачей. В его обязанности входит следить за тем, как протекает созданный им процесс, и руководить им. Он мотивирует других людей выполнять работу для достижения поставленных целей.
Консёрн
От англ. concern (дословно — тревога, участие) — в английском языке слово «консёрн» имеет много различных значений, при этом очень часто употребляется в русской речи. Какое именно значение вкладывает в него автор, известно только ему самому. Иногда — это смесь многих значений, таких как: особый интерес, беспокойство, цель, настороженность, опасение и т.д.
Окиары
От англ. OKR, сокращенно от Objectives and Key Results (дословно — цели и ключевые результаты) — система по постановке и достижению целей. Она нужна для синхронизации работы всех участников компании/отдела/команды, чтобы все двигались в одном направлении, с понятными приоритетами и постоянным ритмом. В отличие от KPI, это амбициозное целеполагание, достижение окиаров (окров) на 70-80% — отличный результат.
Оффер
От англ. offer (дословно — предложение) — предложение о работе / приглашение на работу.
Поинт
От англ. point (дословно — точка) — чаще всего употребляется в значении «точка зрения», сокращенно от point of view. Также в значениях: «суть», «смысл», «довод».
Техосмотр 2022: последние важные новости для автомобилистов
Госдума приняла в первом чтении законопроект об отмене обязательного техосмотра для автомобилистов еще в начале ноября. Авторы документа обещали, что до Нового года его примут во втором и третьем чтениях. Однако точных дат рассмотрения законопроекта по-прежнему нет. Разбираемся, что происходит на данный момент с этим документом, а также, какие изменения ожидают саму процедуру техосмотра.
Для кого техосмотр будет обязательным
В случае если законопроект получит окончательный «зеленый свет», автовладельцам разрешат обращаться за проведением техосмотра только по собственному желанию. Обязательной этой процедура останется только при постановке частных автомобилей и мотоциклов на учет — при смене собственника и только в случае, если машина старше четырех лет. Также техосмотр придется проходить при внесении изменений в конструкцию и замене основных агрегатов. По подсчетам властей, отмена обязательного техосмотра коснется примерно 50 млн транспортных средств — легковых автомобилей и мотоциклов, облегчив жизнь их владельцам.
Что ждет перевозчиков
Эта инициатива распространяется только на физических лиц — перевозчиков и коммерческого транспорта изменения не коснутся. Также в этот список попал личный автотранспорт, используемый в служебных целях.
Почему техосмотр больше не нужен
В пояснительной записке авторы законопроекта указали на обязанность владельца содержать свой автомобиль в исправном техническом состоянии и не выезжать на дороги при наличии проблем. Такие требования прописаны в ПДД: содержать транспортное средство исправным водитель должен вне зависимости от факта прохождения технического осмотра.
Также в записке приводится статистика участия в ДТП легковых автомобилей и мотоциклов с техническими неисправностями, но при этом имеющих действующие полисы ОСАГО и прошедших техосмотр. Учитывая количество зарегистрированного автотранспорта и аварий, в случае с легковыми автомобилями вероятность попасть в ДТП составляет 1,1%, в случае с мотоциклами — 0,7%, с автобусами — 5,6%, с грузовиками — 2,07%.
Почему документу потребовалась доработка
Изначально правительство страны дало положительный отзыв на внесенный законопроект об отмене обязательного техосмотра. При этом потребовало внести в документ доработки. Правда сам отзыв на данный момент звучит не очень понятно. Там подчеркивается, что в настоящее время в техническом регламенте Таможенного союза, проверка выполнения требований к транспортным средствам в случае изменения их конструкции осуществляется «в форме предварительной технической экспертизы конструкции на предмет возможности» ее изменения, последующей проверки безопасности конструкции и техосмотра транспорта. Чтобы привести этот пункт в соответствие с Договором о Евразийском экономическом союзе, его придется доработать. Внесли ли авторы законопроекта необходимые изменения в документ перед вторым и третьем чтением пока неизвестно.
Штрафы за отсутствие техосмотра могут вырасти
Сейчас за отсутствие техосмотра автомобилисту теоретически могут выписать штраф 500-800 руб. за отсутствие актуальной диагностической карты. Такие нормы содержатся в ч.1 ст. 12.1 «Управление транспортным средством, не зарегистрированным в установленном порядке» КоАП России. На деле это сделать проблематично: диагностическая карта не входит в перечень обязательных документов для проверки инспектором ГИБДД.
После принятия нового закона штрафовать за езду без диагностической карты будут владельцев только тех транспортных средств, для которых техосмотр останется обязательным. Причем наказание для недобросовестных водителей вырастут уже с марта следующего года, когда вступят в силу в силу поправки в Кодекс об административных правонарушениях (КоАП). Так, размер взыскания за езду без диагностической карты вырастет до 2000 рублей.
Требования к процедуре техосмотра ужесточат
Поимо ужесточения наказания за езду без диагностических карт, власти собираются изменить требования и к фотографированию автомобилей на пунктах техосмотра. Как объяснили в Министерстве транспорта России, такие меры необходимы для борьбы с мошенничеством. Сейчас во время процедуры прохождения техосмотра должны быть сделаны две фотографии: спереди и сзади автомобиля. Однако в ведомстве хотят изменить это требование. Так, на первом снимке должен быть запечатлен автомобиль в ракурсе спереди и сбоку, а рядом с ним в полный рост должен стоять технический эксперт. В аналогичной композиции должен быть сделан и второй снимок — сзади.
В Минтрансе такие требования объяснили тем, что «участились факты фальсификации» снимков, загружаемых в информационную систему техосмотра ЕАИСТО МВД. Нововведение должно заработать с марта следующего года.
Noveo
9 типичных ошибок в спеках
Около года назад мы уже писали о важности ТЗ и некоторых базовых принципах его написания. Однако эту тему смело можно отнести к вечным — сколько бы ни писали рекомендаций по написанию ТЗ, спеки писали, пишут и будут писать как попало. Не все, конечно… но многие :). Вот и Егору Бугаенко надоели очевидные недочеты в спеках, и он попытался просто и понятно объяснить, как избежать хотя бы самых основных. Предлагаем вашему вниманию перевод его статьи:
Есть прекрасная книга “Требования к ПО” авторства Карла Вигерса – собственно, о требованиях к ПО. Я считаю, что она обязательна к прочтению для каждого разработчика ПО. Не вижу необходимости повторять то, что там написано, но все же существует несколько очень простых и очень типичных ошибок, которые мы продолжаем допускать в наших спеках. Я вижу их в наших документах снова и снова, и поэтому решил дать краткий их обзор. Итак, вот они – самые критичные и типичные из них, с точки зрения программиста, читающего спецификацию.
Глава 4.3 известного стандарта IEEE 830-1998 гласит, что хорошая спецификация должна быть безошибочной, недвусмысленной, полной, логичной, упорядоченной, доказуемой, изменяемой и позволяющей отслеживать изменения. Итого 8 качеств. Затем стандарт объясняет их один за другим на очень доступном английском. Но разве у нас есть время читать эти скучные стандарты? Они для университетских профессоров и сертификационных комитетов. Мы же практики! Подождите, я шучу.
Неважно, насколько мал проект и до какой степени мы практики, всегда есть документ, объясняющий, что нужно сделать, и он может называться “спецификация требований к ПО”, или “спецификация”, или просто “спека”. Конечно, остается много места для творчества, но мы ведь инженеры, не артисты. Мы должны следовать правилам и стандартам, большей частью потому, что они делают наше общение проще.
Итак, я подхожу к сути. Спеки, которые я обычно вижу, нарушают, в общем-то, все 8 принципов, упомянутых ранее. Ниже – краткое изложение того, как именно они это делают. Кстати, все примеры взяты из настоящей документации к реальным коммерческим ПО-проектам.
1. Беспорядочная терминология или ее отсутствие
Как насчет чего-нибудь подобного:
UUID определен по нарастающей, чтобы убедиться, что нет двух пользователей с идентичным номером учетной записи.
В чем разница между UUID и номером учетной записи? Это одно и то же? Кажется так, верно? Или, может быть, они различаются… Было бы здорово знать, что же скрывается за сокращением UUID. Это «unique user ID» (уникальный идентификатор пользователя) – или, может быть, «unified user identity descriptor» (единая характеристика идентификатора пользователя)? Без понятия. Я в заблуждении и хочу найти автора этого текста и сделать с ним (или с ней) что-нибудь плохое.
Мы пишем, чтобы быть понятыми, а не впечатлить читателя
Я уже писал, что у самых плохих технических спецификаций нет словаря терминологии. По моему опыту, это самая большая проблема во всех документах с техническими требованиями. Это не художественная литература! Не любовное письмо! Это техническая документация. Мы не можем жонглировать словами просто для того, чтобы было весело. Мы не должны использовать спецификации по продукту просто для самовыражения. Мы пишем их, чтобы читатель нас понял, а не впечатлился. И здесь действует то же правило, что и с диаграммами: если я вас не понимаю, вы сами виноваты.
Вот как этот текст будет выглядеть после хорошего редактирования:
UUID – уникальный идентификатор пользователя, натуральное 4хбайтовое число.
UUID определен по нарастающей, чтобы убедиться, что нет двух пользователей с идентичным номером учетной записи.
Таким образом, первая и основная проблема – легкомысленное использование терминов и просто слов без предварительного определения их в словаре.
2. Вопросы, обсуждения, предложения, мнения
2. Вопросы, обсуждения, предложения, мненияВот такое я увидел совсем недавно в продуктовой спеке:
Я считаю, что нужно поддерживать несколько версий API. Какие у нас есть опции? Я бы предложил остановиться на варианте версионированных URL. Не стесняйтесь высказать здесь ваши мысли на этот счет.
Да, этот текст дословно существует в документе с требованиями. Во-первых, автор выражает свое персональное мнение. Во-вторых, автор спрашивает меня, какие в принципе возможности у нас здесь есть. А затем он предлагает, чтобы я рассмотрел что-то из этого, и следом приглашает меня к дискуссии.
Найдите ответы на все свои вопросы прежде, чем писать документ, именно за это вам платят
Впечатляет, не правда ли? Очевидно, автор – очень креативная личность. Но этого человека нужно держать как можно дальше от проектной документации. Это абсолютно не то, что ценится в документе с техническими требованиями. Нет, мы, конечно, ценим креативность, но все же есть 4 строго запрещенных вещи: вопросы, обсуждения, предложения и мнения.
Спецификации не должны содержать в себе никаких вопросов. Кому эти вопросы адресованы? Мне, программисту? Вы хотите, чтобы я реализовывал ПО или отвечал на ваши вопросы? Мне не интересен брейнсторминг с вами. Я ожидаю, что вы, автор требований, скажете мне, что нужно делать. Найдите ответы на все свои вопросы прежде, чем писать документ. Именно за это вам платят. Если у вас нет ответов, напишите там что-нибудь типа TBD («to be determined», “предстоит определить”). Но не задавайте вопросов. Это раздражает.
Документ с требованиями – не дискуссионный клуб. Как читатель спеки, я ожидаю увидеть, что именно должно быть сделано, безо всяких “может быть” или “мы можем сделать это и по-другому”. Конечно, вам нужно обсудить эти моменты, но сделайте это до того, как вы их задокументируете. Сделайте это где-нибудь в другом месте, в Скайпе, например, или в Слаке, или по электронной почте. Если вы действительно хотите обсуждения в документе, используйте Google Docs или Word с отслеживанием версий. Но когда дискуссия завершена, удалите ее историю из документа. Ее присутствие только вводит меня, программиста, в заблуждение.
Нет необходимости и в формулировании требований в виде предположений. Просто скажите, что должно быть сделано и как ПО должно работать, не бойтесь оказаться неправыми. Обычно люди прибегают к предположениям, когда они боятся высказать что-то прямо. Вместо того, чтобы сказать “приложение должно работать на устройствах с Android 3.x и выше», они говорят «Я бы предложил сделать приложение совместимым с Android 3.x и выше.» Чувствуете разницу? Во втором предложении автор пытается избежать личной ответственности. Он не говорит «однозначно Android 3.x», он всего лишь предлагает. Не будьте трусом, говорите прямо. Если вы ошибетесь, мы вас поправим.
И, конечно, мнения вообще не в почете. Это не письмо другу; это официальный документ, относящийся к проекту. Через несколько месяцев или недель вы можете покинуть проект, и кто-то другой будет работать с вашим документом. Спека – как контракт между инвестором проекта и проектной командой. Мнение автора документа не имеет здесь никакого значения. Вместо того, чтобы заметить, что “кажется, Java была бы быстрее” и предположить, что “нам следовало бы использовать ее”, скажите “Java быстрее, и мы должны использовать ее”. Очевидно, что вы говорите об этом здесь потому, что так думаете. Но когда это отражено в спеке, нам неважно, от кого пришла эта мысль и что вы думали по поводу этой проблемы. Подобная информация только запутала бы нас, так что опустите ее. Только факты, никаких мнений.
Не поймите меня превратно, я не против креативности как таковой. Программисты – не роботы, беззвучно реализующие все, что написано в документе. Но беспорядочный документ не имеет никакого отношения к креативности. Если вы хотите, чтобы я что-то скреативил, определите мне границы этой креативности и позвольте экспериментировать в этих рамках; например:
Должны быть поддержаны несколько версий API. Как именно это сделано, не имеет значения.
Так вы предлагаете мне быть креативным. Я понимаю, что у пользователя проекта нет предпочтений или ожиданий от механизма версионирования в API. Я свободен делать что угодно. Отлично, я сделаю это по-своему.
Но опять же, повторюсь: спецификация – не дискуссионный комитет.
3. Путать требования к функциональности и к качеству
Вот как это выглядит:
Пользователь должен иметь возможность проскроллить весь список изображений в профиле плавно и быстро.
Это типичная ошибка практически всех спек, которые я видел. Здесь мы мешаем в одну кучу функциональные требования (скроллить изображения) с требованиями вне функциональности (скроллинг плавный и быстрый). Почему это плохо? Ну, особой причины нет, но это демонстрирует недостаток организованности.
Подобное требование тяжело перепроверить или протестировать, тяжело отследить и тяжело реализовать. Как программист, я не знаю, что важнее: реализовать скроллинг или убедиться, что скроллинг быстр.
Также тяжело изменить подобное высказывание. Если завтра мы добавляем другое функциональное требование – скроллинг списка друзей, например, – мы захотим потребовать, чтобы этот скроллинг также был плавным и быстрым. Затем спустя несколько дней мы захотим сказать, что “быстро” означает время реакции менее 10 миллисекунд. Соответственно, нам нужно будет продублировать эту информацию в двух местах. Видите, каким беспорядочным наш документ может стать в будущем?
Поэтому я бы настоятельно рекомендовал всегда документировать функциональные и нефункциональные требования отдельно.
4. Путать требования и дополнительные документы
Это похоже на предыдущую проблему и выглядит следующим образом:
Пользователь может загрузить PDF-отчет с полным списком транзакций. Каждая транзакция имеет свой ID, дату, описание, счет и итоговую сумму. Отчет также содержит общий итог и ссылку на счет пользователя.
Очевидно, что в этом абзаце описаны две вещи. Первая – пользователь может загрузить PDF-отчет. Вторая – как этот отчет должен выглядеть. Первое – функциональное требование, а вот второе должно быть описано в дополнительном документе (или приложении).
Как правило, функциональные требования должны быть очень краткими: пользователь загружает, пользователь сохраняет, клиент запрашивает и получает и т.д. Если ваш текст становится длиннее, что-то пошло не так. Попробуйте перенести часть этого в дополнительный документ.
5. Неизмеряемые требования к качеству
Вот о чем я говорю:
Номера кредитных карт должны быть зашифрованы. Приложение должно запускаться менее чем за 2 секунды.
Каждая веб-страничка должна открываться быстрее, чем за 500 миллисекунд.
Каждый интерфейс должен быть респонсив.
Я могу найти множество примеров, просто открыв спеки с требованиями ко многим проектам, которые я видел за последние несколько лет. Они все выглядят одинаково. И проблема всегда одна и та же: очень сложно определить по-настоящему тестируемое и измеряемое нефункциональное требование.
Да, это сложно. Главным образом потому, что замешано много факторов. Возьмем, к примеру, вот эту строчку: “Приложение должно запускаться менее чем за 2 секунды”. На каком оборудовании? С каким количеством данных в профиле пользователя? Что означает “запускаться”; включает ли это в себя время загрузки профиля? Что, если есть проблемы при запуске? Они в счет? И есть еще много подобных вопросов.
Если мы отвечаем на все из них, текст с требованиями займет целую страницу. Никто этого не хочет, но неизмеряемые требования – еще большее зло.
Опять же, это непросто, но это необходимо. Попробуйте убедиться, что все требования к качеству сформулированы полностью и без двусмысленностей.
6. Инструкции по имплементации
Этот пример иллюстрирует очень частую типовую ошибку:
Пользователь авторизуется через кнопку “Войти” на Фейсбуке, и мы сохраняем имя пользователя, аватарку и email в базе данных.
Это микроменеджмент, и аналитик технических требований никогда не должен делать этого с программистом. Вы не должны говорить мне, как реализовать функциональность, которую вы хотите. Вы хотите дать пользователю возможность залогиниться через Фейсбук? Так и скажите. Вам действительно важно, будет это происходить по клику на кнопку или как-либо по-другому? Вам действительно важно, что я сохраняю в базу данных? А что, если я использую файлы вместо базы данных? Вам это важно? Я так не думаю. Это действительно имеет значение только в очень редких случаях. В большинстве случаев это просто микроменеджмент.
Спека должна требовать только то, что действительно важно для бизнеса. Все остальное предоставлено нам, программистам. Мы решаем, какую базу данных использовать, где поместить кнопку и какая информация будет сохраняться в базе данных.
Вы не должны говорить мне, как реализовать функциональность, которую вы хотите
Если вам это действительно важно, потому что есть определенные ограничения более высокого уровня, – так и скажите. Но опять же, не в виде инструкции по реализации для нас, программистов, но скорее как нефункциональное требование наподобие следующего:
Страница с логином должна выглядеть следующим образом (скриншот во вложении).
Мы должны сохранять email пользователя локально для последующих нужд.
Смысл в том, что я ничего не имею против требований, но я сильно против инструкций по реализации.
7. Недостаток перспективы деятеля
Текст может выглядеть следующим образом:
PDF-отчет генерируется по требованию. Отчет можно скачать или сохранить в своем профиле.
Здесь проблема в том, что не вовлечен “деятель”. Сама функциональность более-менее ясна, только непонятно, кто все это делает. Где пользователь? Это просто история о чем-то, что где-то происходит. Это не совсем то, что нужно разработчику для того, чтобы это имплементировать.
В хороших “пользовательских” требованиях всегда есть… Угадайте, кто. Пользователь
Лучший способ объяснить функциональность – это пользовательские требования. И в хороших пользовательских требованиях всегда есть… Угадайте, кто. Пользователь. Предложения всегда начинаются с “пользователь…”, за которым следует глагол. Пользователь загружает, пользователь сохраняет, пользователь кликает, печатает, удаляет, форматирует и т.д.
Совершенно необязательно, чтобы пользователь был человеком. Это может быть система, клиент RESTful API, база данных, да что угодно. Но всегда – кто-то. “Можно загрузить” – не пользовательское требование. Можно – кому?
8. Шум
Как насчет чего-нибудь такого:
Больше всего нас интересуют производительность и привлекательный пользовательский интерфейс.
Это шум. Я, читатель этого документа, – не инвестор и не пользователь. Я программист. Меня не волнует, что больше всего интересует вас в этом проекте. Моя задача – реализовать продукт в соответствии со спеками. Если вас больше всего интересует производительность, создайте мне требования, которые можно измерить и протестировать. Я обеспечу соответствие продукта этим требованиям. Если вы не можете создать требования, не засоряйте информационное пространство этими не имеющими значения сведениями.
Разве хороший программист не сообразит сам, что означает “хорошая производительность”?
Я не хочу делить с вами ваши заботы, верования или намерения. Это ваше дело. И вам платят за то, чтобы четко и недвусмысленно перевести все это в требования, которые можно измерить и протестировать. Если вы не можете этого сделать, это ваша проблема и ваша вина. Не пытайтесь переложить ее на меня.
Очень часто… Подождите. Очень-очень часто. Нет. Почти всегда. Опять не так. Всегда! Именно, спеки всегда полны шума. В некоторых его чуть поменьше, в других – побольше. Я считаю, что это симптом ленивого и непрофессионального автора документа. В большинстве случаев – просто ленивого.
Такие авторы не хотят думать и переводить свои заботы, идеи, мысли, намерения и цели в функциональное и нефункциональные требования. Они просто указывают их в документе и надеются, что программист как-нибудь найдет правильное решение. Ведь разве хороший программист не сообразит сам, что означает “хорошая производительность”? Давайте просто скажем ему, что нас интересует производительность, и он что-нибудь придумает.
Нет! Не делайте так. Делайте свою работу и предоставьте программистам заниматься своей. А мы, программисты, никогда не должны принимать подобные документы. Мы просто должны отказываться с ними работать и просить автора требований переработать их и убрать шум. Я бы рекомендовал даже не начинать работу над продуктом, если в его спеках полно шума.
9. Будет работать, должно работать
Вот еще одна очень типичная ошибка:
API будет поддерживать JSON и XML. Оба формата должны полностью поддерживать все информационные элементы. XML должен быть подтвержден XSD-схемой.
Видите, как беспорядочно это звучит? Три разных точки зрения, и ни одна из них не подходит для спецификации. Спека должна описывать продукт, как будто он уже существует. Спека должна звучать как руководство, инструкция, справка. Этот текст следует переписать, например, так:
API поддерживает JSON и XML. Оба формата
Полностью поддерживают все информационные элементы. XML подтвержден схемой XSD.
Видите разницу? Все эти словечки “должно” и “будет” только добавляют сомнений в документ. Для читателя такой спеки “API будет поддерживать” звучит как “когда-нибудь в будущем, может быть, в следующей версии, оно будет поддерживать”. Это не то, что автор имел в виду, верно? Не должно быть сомнений, двойных значений, возможности. API поддерживает. Вот и все.
Возможно, я и забыл что-то важное, но приведенные проблемы так очевидны и так раздражают… Я буду использовать этот пост в качестве простого руководства для наших системных аналитиков.
Мы выражаем огромную благодарность аккаунт-менеджеру Галине за вдумчивый перевод этой бесспорно полезной статьи! Надеемся, он поможет сделать жизнь многих русскоязычных техписателей (да и программистов) легче.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
