Документирование в разработке ПО
Добрый день, уважаемое сообщество.
Позвольте представиться. Я бизнес-аналитик, уже десять лет работаю в области разработки заказного программного обеспечения, в последнее время совмещаю роли аналитика и руководителя проектов.
Одним из болезненных вопросов в разработке ПО всегда был и остаётся процесс документирования этой самой разработки. Вам доводилось приходить на проект, который делают уже пару лет, но, при этом, вы никак не можете с ним разобраться, потому что из документов есть одно техническое задание, да и то написано в самом начале и не отражает и половины функционала системы? Мне доводилось. И это, честно говоря, очень печальное и байтораздирающее зрелище.
Поэтому на всех своих проектах я стараюсь изначально построить процесс так, чтобы неопознанного и неописанного функционала не было, все члены команды вовремя получали актуальную информацию и вообще был мир во всём
Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.
1. Документация обеспечивает «общее пространство» проекта. Любой участник в любой момент времени может получить необходимую информацию как по конкретной задаче, так и по общему направлению работы.
2. Команда говорит «на одном языке» — ведь гораздо проще понять человека, сообщающего «об ошибке в функции, описанной в Use Case №12», чем «о стрёмном баге в той фигне, которую Вася месяц назад делал».
3. Документирование позволяет четко разграничить зоны ответственности между участниками проекта.
4. Только тщательно описанные требования могут быть проверены на полноту и непротиворечивость. «Наколенные записки» — прямой и очень быстрый путь к тому, что границы проекта расползутся резвыми тараканами, а функционал, задуманный вначале, не будет монтироваться с возникающими в процессе «хотелками» заказчика.
Для себя я выработала набор базовых правил, которые позволяют эффективно документировать, планировать и контролировать разработку в комфортных для всех участников условиях.
1. Документация не должна быть избыточной и объемной. Мы пишем документы не за-ради приятного процесса постукивания по клавишам, а для того, чтобы их использовать в работе. Избыточное количество текста – раздражает и затрудняет восприятие.
2. Вся схема документирования проекта должна быть взаимоувязанной и логичной. Если в схеме существует документ, который не связан ссылкой с каким бы то ни было другим документом, то его можно безболезненно из схемы исключить.
3. Вся оценка трудозатрат должна производиться только на основании описанных атомарных задач. Сложно оценить разработку «функционала подсистемы ввода данных», гораздо проще оценить задачи «разработка формы ввода данных марсиан» и «разработка фильтра списка марсиан». Чем мельче оцениваемый элемент – тем точнее будет агрегированная оценка.
4. Всегда необходимо формировать списки оповещения заинтересованных участников. Разработчик, узнающий о необходимости доработки за три дня до релиза – это зло и подлейшая подлость, аналитик, втихаря поменявший требования и не уведомивший всех заинтересованных участников о необходимости доработки – последняя свинья, а РП, допустивший такую ситуацию – чума, холера и неприятный человек, который не справляется со своими обязанностями.
Я предлагаю на суд уважаемого сообщества схему документирования, которая кажется мне удобной, логичной и правильной. И – да, это работает.
Итак, какие типы документов используются в схеме.
1. Техническое задание.
2. Частное техническое задание (опционально).
3. Сценарий использования (Use Case).
4. Сценарий тестирования (Test Case).
5. Отчет об ошибке (Bug Report).
6. Руководство пользователя.
7. Руководство администратора (опционально).
На рисунке ниже — схема связи между этими документами. 
Как это работает?
Изначально, при обследовании, формируется Большое Техническое задание.
Оно включает в себя:
• словарь терминов предметной области;
• описание предметной области;
• описание ролевой системы;
• описание функциональных требований;
• описание нефункциональных требований.
Описание требований в этом документе фиксируется на «верхнем уровне», то есть мы описываем не конкретные действия, а только необходимые функции. Требования оптимально разбивать на смысловые группы по подсистемам.
Например, мы описываем подсистему «Администрирование» с функциями «Создание карточки пользователя», «Удаление карточки пользователя», «Редактирование карточки пользователя». Это требования верхнего уровня, ниже в ТЗ опускаться смысла нет.
В случае, если система большая, разумно сделать Частные технические задания на каждую подсистему.
ЧТЗ должны содержать:
• ссылку на пункт ТЗ;
• максимально подробную информацию по каждой функции;
• список UseCases для функции.
Таким образом реализуется преемственность документов, что позволяет, во-первых, унифицировать их форму, во-вторых – частично реализовать повторное использование, то есть снизить затраты времени на «писанину».
Например, мы формируем ЧТЗ на всё ту же подсистему «Администрирование». Оно будет содержать описание функции: «Создание карточки. Необходимо реализовать следующий функционал: вызов карточки посредством кнопки «Создать», интерфейс карточки, содержащий следующий набор полей, сохранение карточки посредством кнопки «Сохранить», отмену сохранения посредством кнопки «Отмена»».
Use Case
Use Case — суть вариант использования, он описывает все действия, которые пользователь может произвести, и реакцию системы на эти действия.
Каждый Use Case должен быть привязан к пункту ЧТЗ.
Наиболее оптимальным, на мой взгляд, является формат описания, включающий в себя:
• Макет экрана. Макеты можно делать и сложные, «кликабельные», но, по опыту, хватает «проволочной диаграммы», сделанной с помощью Visio или аналогичного инструмента. Если на форме предполагается использование модальных окон, то они тоже должны быть прорисованы, нижеописанные таблицы для них должны дублироваться.
• Диаграмму действий экрана, в графическом виде описывающую алгоритм работы функции.
• Таблицу с описанием полей. В строке таблицы должны располагаться следующие данные: название поля, тип поля, ограничение на ввод данных (логические проверки и т.д.), роли пользователей, которым доступно чтение/редактирование поля. Если поле расчетное – то необходимо указывать формулу для расчета значения.
• Таблицу с описанием действия кнопок экрана. В строке таблицы должны содержаться данные о названии кнопки, описание действия при клике и путях перехода, если щелчок по кнопке предполагает переход на другой экран, роли пользователей, которым доступно действие.
Также возможно небольшое общее описание функционала но, как правило, оно просто не нужно.
Test Case
Test Case, что вполне самоочевидно, должен содержать описание тестовых сценариев.
В идеале, каждый такой документ привязывается к соответствующему Use Case, но бывает так, что логично объединить несколько Use Cases в один Test Case.
Оптимальным вариантом формата описания является таблица, содержащая в одном столбце описание атомарной операции, влекущей ответное действие системы, во втором – описание правильной реакции системы. Описывать, к примеру, процесс ввода текста в текстовое поле не нужно, а вот проверку валидности данных при сохранении (щелчке по кнопке «Сохранить») – обязательно.
Bug Report
Ещё немного побуду кэпом: Bug Report возникает в процессе тестирования системы как реакция тестировщика на ошибку. Каждый документ должен обязательно ссылаться на соответствующий Test Case.
Содержать документ должен:
• скриншот возникшей ошибки;
• описание предшествующих действий. Лучше всего разработать удобный для всех шаблон такого описания – это сильно экономит время разработчикам при воспроизведении бага;
• текстовое описание самой ошибки.
Руководство пользователя/Руководство администратора
Самые занудные в написании, но, тем не менее, жизненно необходимые документы.
По сути, их формирование можно даже автоматизировать, если все Test Cases и Use Cases были написаны с должным старанием и правильно оформлены.
Я не буду подробно на них останавливаться, если вдруг тема заинтересует – расскажу о том, как их составление можно автоматизировать.
Вредные советы опытного БА, часть 2: боли клиента важнее хотелок Заказчика – ТЗ и ЧТЗ
Сегодня разберем, чем Клиент отличается от Заказчика, чьи требования важнее и как их специфицировать в виде частного технического задания. Что такое ЧТЗ и как его составить: практические рекомендации для начинающих бизнес-аналитиков с примерами, а также ссылками на ГОСТ и BABOK®Guide.
Заказчик vs клиент: в чем разница и что говорит BABOK®Guide
В консалтинге и заказной ИТ-разработке некоторые проекты бывают достаточно долгими и направленными на решение стратегических задач. Например, разработка стратегии развития предприятия, создание программы цифровизации или научно-исследовательские работы. В таких случаях не всегда есть четкое видение конечного продукта, т.е. какой именно результат нужно получить. При этом договор на выполнение работ или оказание консалтинговых услуг заключен, а в качестве приложения к нему выступает техническое задание (ТЗ), оформленное по шаблону ГОСТ 34.602-2020 и 19.201-78.
Однако, несмотря на заполнение всех обозначенных в этих стандартах пунктов, запустить этот документ в реализацию невозможно, т.к. описанные в нем требования, ограничения и цели носят слишком абстрактный характер. Например, «графический интерфейс пользователя должен быть удобным и интуитивно понятным», «назначение системы – свести к минимуму число операций, выполняемых бизнес-пользователем вручную», «порядок обработки персональных данных должен соответствовать Законодательству» и т.д. и т.п. Такое ТЗ носит формальный характер и требует уточнения, которое обычно реализуется в виде ЧТЗ или частного технического задания. ГОСТ 34.602-2020 отмечает, что дополнительно могут быть разработаны ТЗ на части автоматизированной системы, включая ПО, которые будут уточнять первичные требования.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
Ближайшая дата курса
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.
На практике, особенно при работе с крупными государственными проектами, в разработке ТЗ чаще всего участвуют управленцы, а не аналитики и специалисты предметной области. Такая ситуация типична для открытых тендеров и конкурсов на выполнение научно-исследовательских работ. Поэтому первой задачей аналитика после получения подобного ТЗ с очень высоким уровнем абстракции становится его «приземление», т.е. выявление требований и их формулирование в виде ЧТЗ. Чаще всего здесь происходит смена ответственного стейкхолдера: на уровне «головного», т.е. первичного ТЗ мы имеем дело с Заказчиком, а на уровне ЧТЗ – с экспертами предметной области и конечными пользователями продукта.
Например, Заказчик красиво говорит про цифровизацию, единое информационное пространство, сквозную аналитику и 50%-ное повышение прибыли за счет роста производительности труда. А в первом же интервью с Клиентом выясняется, что нужна интеграция существующих информационных систем, регламенты выполнения бизнес-процессов, понятные дэшборды для отслеживания ключевых показателей управленческого учета и операционных метрик, а также автоматизация рутинных задач.
Таким образом, аналитик приходит к необходимости разделять Заказчика и Клиента, решая с первым формальные этапы приемки работы, а со вторым – особенности погружения в результат, включая уточнение требований. Такое разделение не отражается в BABOK®Guide, где под термином Customer обозначен стейкхолдер, использующий продукты или услуги предприятия, имея договорные или моральные права, которые оно обязано соблюдать. Это определение близко к понятию «Заказчик» из гражданского кодекса РФ, который применяет его к узкому кругу сделок на выполнение работ или оказание услуг. Например, договоры подряда, выполнение научно-исследовательских, опытно-конструкторских и технологических работ, поставка товаров, а также возмездное оказание услуг для государственных и муниципальных нужд.
В частности, Заказчиком в проекте разработки ПО может быть государственное предприятие или головной офис крупной корпорации. Заказчиком курса по бизнес-анализу может выступать физическое лицо, которое хочет подарить своему коллеге обучение. Потребителя услуг часто называют Клиентом – тот, кто принимает продукт и тот, чьи потребности он должен удовлетворять. Поэтому требованиям этих стейкхолдеров следует уделить особое внимание, о чем мы поговорим далее.
Управление бизнес-анализом — курс для руководителей
Код курса
Ближайшая дата курса
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.
Что такое ЧТЗ и как его составить
Если понимать под Заказчиком юридическое или физическое лицо, которое выражает пожелания, устанавливает сроки и платит деньги, а под Клиентом – того, кто формулирует требования к результату и принимает его, разделение зон ответственности становится понятнее. Например, в терминах RACI-матрицы Заказчик будет иметь роль Информируемый (Informed, I), а Клиент — Консультирующий (Consulted, C). Подробнее о том, что такое матрица ответственности (RACI) и чем она отличается от таблицы CRUD-операций, смотрите здесь.
Таким образом, в первичном (головном) ТЗ описываются требования Заказчика, которые являются скорее пожеланиями с высоким уровнем абстракции, а в ЧТЗ – непосредственные требования к решению (функциональные и нефункциональные), следующие из бизнес-потребностей и требований Клиента. Именно ЧТЗ чаще всего и представляет собой документ пользовательских требований в форме Use Case, а также описание системных ограничений, зависимостей, доменных сущностей и взаимоотношений между ними, включая UML-диаграммы и прототипы экранных форм, — т.е. все, что необходимо разработчикам для начала реализации. Такое частное техническое задание чаще всего строится по шаблону на основе SRS по ISO IEEE 29148-2018, который я приводила в этой статье.
Разумеется, в ЧТЗ следует сослаться на головное ТЗ. Обычно это делается в начале документа, например, в разделе Введение, пункт «Основание для разработки». Это можно сделать следующей формулировкой:
Основанием для развития является контракт/договор № от _______ года на выполнение работ по _____________________ (далее Контракт). Настоящее Частное техническое задание разработано в соответствии с требованиями Технического задания на выполнение работ по _____________________. Общие требования к системе должны соответствовать Техническому заданию на выполнение работ _______________ (Приложение №__ к Контракту). Специфические требования отражены в настоящем ЧТЗ.
В терминах продуктового подхода можно сказать, что ТЗ – это дорожная карта продукта (Product RoadMap), а ЧТЗ – это план релиза. Или еще одна всем понятная аналогия: ТЗ – это основной Закон (Конституция), а ЧТЗ – это законы Кодексов (Гражданский, Трудовой, Налоговой, Жилищный, Бюджетный, Уголовный и пр.).
В заключение отмечу, что полезно описать в ЧТЗ критерии приемки результатов согласно концепции определений (Definition of Done). Выявить их можно на этапе валидации требований в рамках совместной работы бизнес-аналитика с Клиентом – экспертом предметной области и конечным пользователем продукта. Как сделать это на практике, составить рабочее ТЗ и ЧТЗ, а также разобраться с видами и формами представления требований, вы узнаете на курсе «Разработка ТЗ на информационную систему» в нашей Школе прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве.
Что проверить, насколько хорошо вы усвоили материал этой статьи, мы предлагаем вам самостоятельно выполнить открытый интерактивный тест на знание стандартов разработки ТЗ и спецификации требований к ПО.
А детально разобраться с содержанием BABOK®Guide на практических примерах вам помогут курсы нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
Простой пример частного технического задания (ЧТЗ) для 1С-ника
Частное техническое задание (далее ЧТЗ) – это выделенный блок технического задания (ТЗ), в котором описана определенная часть разработок проекта. Как правило, Частное техническое задание описывает определенную небольшую функциональность и позволяет разделить работу по нескольким разработчикам, так чтобы они не «пересекались» в рамках функциональной области. По сути, ЧТЗ – это и есть ТЗ только на часть системы. Обязательный атрибут технического задания на внедрение системы на крупных проектах.
Зачем писать Частное техническое задание на «маленьких» проектах, где и так все понятно?
Практика показывает, что даже на небольших проектах, несогласованные представления исполнителя с ожиданиями заказчика приводят к дополнительным затратам на исправления, а порой и конфликтным ситуациям, поэтому правильно задокументированные задачи, являются залогом успешно сдачи работ.
В данной статье будут описаны самые необходимые аспекты разработки технического задания для 1С, взятые из практики внедрения не только на крупных, но и на небольших проектах. Здесь не будет описания ГОСТ-ов и прочих формальностей. Целью статьи является описание упрощенного формата документирования задания на разработку.
Структура представленного здесь примера технического задания для 1С состоит из следующих разделов:
1. Контекст задачи
В данном разделе идет описание в следующей последовательности
пользовательская история -> проблема или предложение -> ожидаемый результат
Этот раздел позволяет разработчику понять суть проблемы и спроектировать техническую часть (если он участвует в разработке структуры технического задания)
Заполняется Аналитиком и/или Заказчиком
2. Критерии результата
В этом разделе перечислены, основные критерии по которым можно проводить тестирование и проверять результат технического задания. Данные критерии будут являться основанием для того, чтобы работа считалась выполненной во время сдачи-приемки заказчику.
Заполняется Аналитиком и/или Заказчиком
3. Техническое описание
В разделе технического описания задания должен быть представлен результат архитектурного и функционального решения. Описаны структуры добавленных объектов, требования к поведению системы при наступлении определенных событий. Т.е. описан способ реализации поставленной задачи.
Можно использовать следующие подразделы:
— Интерфейс (формы ввода, расположение команд)
— Добавленные, измененные объекты (архитектура)
— Контрольные процедуры (проверка введенных пользователем данных)
— Алгоритмы автоматического заполнения
— Алгоритмы реагирования на события
— Алгоритмы реагирования на команды
— Формы вывода информации
Заполняется Архитектором или Программистом
4. Контактные лица
Список участников проекта в рамках данного Частного технического задания. Согласно данного списка разработчик может связаться с тем или иным участником для уточнения или согласования определенных действий. Для удобства сюда можно добавить контактные данные.
5. Трудоемкость
Оценка планируемых трудозатрат на выполнение данного ЧТЗ
Заполняется Архитектором или Программистом
В данном разделе описывается порядок выполнения необходимых действий после разработки функционала, но до его использования. Например, здесь можно указать необходимость установки определенных настроек информационной базы, или проведения регламентных операций, без которых работа с функционалом Частного технического задания невозможна. Для каждого пункта чек-листа необходимо указать ответственных. Это позволит координировать участников проекта и ускорит его внедрение.
Заполняется Архитектором или Программистом. По желанию, Аналитиком и Заказчиком
Пример технического задания в 1С
Хочется еще раз отметить, что ЧТЗ или ТЗ позволяют не только действовать согласованно всем участникам проекта, но и получить осознанное представление о ходе разработки и критериях успешной сдачи работ. Рассмотрим пример технического задания для 1С.
Учет личного автотранспорта
Контекст задачи
В организации существует необходимость ведения учета использования личного автотранспорта сотрудников. В данный момент учет ведется в файле «Личный автотранспорт.xls». В этот файл заносятся данные о марке транспортного средства и его госномер. У одного сотрудника может быть несколько единиц транспортных средств. Необходимо реализовать данный учет в информационной базе в карточке физического лица.
Критерии результата
- В карточке физического лица добавлена возможность ввода данных о работе на личном автотранспорте.
- Обеспечена возможность ввода и хранения названия марки автомобиля и госномера для каждой единицы личного транспорта человека.
- Можно ввести несколько единиц транспортных средств для одного физического лица.
- Данные о личном автотранспорте могут вводить только сотрудники кадровой службы. Сотрудники HR-отдела могут только просматривать эти данные. Для остальных сотрудников эти данные должны быть недоступны.
- Данные файла «Личный автотранспорт.xls» перенесены в информационную базу.
Техническое описание
Возможность ввода данных о личном автомобильном транспорте представлена в виде гиперссылки «Личный автотранспорт». При переходе по данной гиперссылки открывается список личного автотранспорта физического лица с возможностью добавления, удаления, редактирования данных списка.
Данные о личном автомобильном транспорте
Добавленные объекты
Измененные объекты
Автозаполнение:
При добавлении новой записи Личный автотранспорт автоматически устанавливать значение поля «Номер по порядку»
Трудоемкость
— Разработка – 1 ч.
— Перенос данных – 2 ч.
— Тестирование – 0,5 ч.
Чек-лист выполнения
1. Разработать функционал и загрузить результат в хранилище. Обновить тестовую базу из хранилища.
отв. Программист
2. Загрузить данные из файла «Личный автотранспорт.xls» в тестовую базу 1С.
отв. Программист
3. В тестовой базе: добавить в профиль Кадровой службы роль «Редактирование личный автотранспорт», добавить в профиль HR-отдела роль «Просмотр личный автотранспорт».
отв. Аналитик
4. Проверка и тестирование результата в тестовой базе 1С.
отв. Аналитик/Заказчик
5. Обновление рабочей базы 1С из хранилища.
отв. Администратор
6. Загрузка данных из файла «Личный автотранспорт.xls» в рабочую базу 1С.
отв. Программист
7. В рабочей базе: добавить в профиль Кадровой службы роль «Редактирование личный автотранспорт», добавить в профиль HR-отдела роль «Просмотр личный автотранспорт».
Не пишите ТЗ на проект 1С. Остановитесь!
Достаточно часто в нашей практике случается такая ситуация: клиент на каком-то шаге нашего знакомства говорит «я сейчас пришлю ТЗ на 1С», или посреди обсуждения будущего проекта берет таймаут со словами «я пошел писать ТЗ на 1С».Часто, эта работа, не очень помогает исполнителю понять потребности клиента, оценить сроки и бюджет и забирает у клиента очень много времени, сил и энергии, отбивает всё желание делать проект
Почему так получается? Зачем нужно ТЗ, кто и как его должен писать, и что вообще должно содержать ТЗ на 1С – на все эти вопросы мы решили ответить.
Начнем с ответа на вопрос «что такое ТЗ». ТЗ – буквально расшифровывается как Техническое Задание. Есть совершенно конкретные требования к документу Техническое задание, его составу, разделам. Эти требования регулируются гостами:
- ГОСТ 19.201
- ГОСТ 34.602
Давайте сразу решим, что про такие ТЗ (по ГОСТам) мы сейчас говорить не будем. Это для корпоративного заказчика, если вам в вашем проекте нужно именно такое «настоящее» ТЗ, вы наверняка знаете, что это, как оно пишется, и знаете где посмотреть ГОСТ и примеры ТЗ по ГОСТ.
В этой статье мы будем обсуждать упрощенное ТЗ, которое обычно пишут/запрашивают в 1С проектах, когда нужны доработки (иногда это называют так же ЧТЗ или «Частное техническое задание»). Почти никогда это не ТЗ по ГОСТу, но что же такое ТЗ содержит?
Упрощенное («частное») ТЗ, которое нужно программисту 1С, должно содержать:
- Список объектов конфигурации, в которых необходимы изменения (перечисления, регистры накопления и регистры сведений, справочники, документы, планы видов характеристик и так далее)
- Список новых объектов конфигурации, с детальным описанием типов данных, расположения реквизитов на форме, структуры интерфейса.
- Детальное описание алгоритмов системы – как система реагирует на нажатие пользователем кнопок, какие записи, в каких регистрах, делают документы, какие операции выполняются в регламентных заданиях.
- Юз-кейсы (пользовательские сценарии) – в них описан путь пользователя внутри системы, каким он должен быть для того чтобы пользователь решил свою задачу.
Для того, чтобы написать ТЗ – необходимо достаточно глубоко знать возможности платформы 1С, объекты, язык программирования. В принципе, нужно быть программистом, при том очень высокого уровня (архитектором).
Обычно ТЗ нужно для большой разработки. Если модуль пишется с нуля, или создается подсистема, или сложная интеграция, без ТЗ не обойтись.
Если речь идет про внедрение типовой системы 1С, или даже с доработками, ТЗ скорее всего не нужно. Какой документ вам понадобится, и какова его структура?
Мы уже обсудили, что ТЗ обычный человек (не айтишник, не программист), составить не сможет. Более того, с большой вероятностью он не сможет их и прочитать, и понять. В этом случае «согласованное ТЗ» имеет низкую ценность, заказчик «согласовал» ТЗ, потому что без этого нельзя двигаться дальше. Но он его не понял, не представил, как будет выглядеть и работать конечный результат. А значит вряд ли получит ожидаемое.
Если действительно нужна разработка на 1С, и необходимо описать свою задачу так, чтобы добиться единого понимания между Заказчиком и Исполнителем, рекомендуем писать ФТ.
Функциональные требования (ФТ) – это документ, на человеческом языке описывающий как будет выглядеть, взаимодействовать с пользователем, и работать программа. Прелесть документа ФТ по сравнению с ТЗ в том, что его не только может написать не технический специалист, но и понять его тоже можно.
Если вы сможете понять ФТ, согласованное с Исполнителем (и поправить его) высока вероятность что вы как Заказчик получите нужный вам результат.
ФТ может быть написано, например, так:
«Необходимо добавить на форму кнопку, при нажатии на которую пользователем будет происходить следующее:
- Открывается форма для выбора интервала дат. При вводе дат пользователем система проверяет, что дата 1 меньше чем дата 2, и обе они меньше сегодняшней даты.
- Еще на этой форме есть кнопка «Проверить отклонения». Пользователь нажимает на эту кнопку, если даты 1 и 2 заполнены
- Система выбирает документы типа «Заказ покупателя», находящиеся в интервале между датой 1 и 2, в которых цена реализации не совпадает с текущей на дату документа ценой по прайсу.
- Все эти документы система выводит в список, который …»
Согласитесь, текст понятный, не содержит сложных технических терминов («обортный регистр накопления», «план видов характеристик»…) Вы прочитали, и смогли себе представить, как будет работать описанная доработка (даже без погружения в контекст).
После прочтения нашей статьи, если вы – заказчик, возможно вы готовы засучить рукава и приняться писать Функциональные требования. Но постойте.
Сапоги должен тачать сапожник, а пироги печь – пирожник. Лучше, когда каждый занимается своим делом, вы развиваете свой бизнес, а описывает требования тот, для кого это – работа.
Есть подрядчики, которые пишут ФТ сами, сняв задачу голосом. Конечно они возьмут чуть больше денег, чем те, кто работает «только по готовому ТЗ». Зато вы сэкономите немало своего времени и нервов сначала на описании задачи, а потом на ее приемке. Поищите и найдете тех, кто ФТ пишет сам, отталкиваясь от задачи, поставленной устно. Конечно, Корада работает так – мы умеем снимать задачу с обычных пользователей и описывать ее
Но мы такие не одни, есть и другие бизнес-ориентированные компании. Вам тогда останется только прочитать, осознать и согласовать ФТ. Поверьте, это гораздо проще чем писать его.
А теперь поговорим про другие документы, которые помогут добиться понимания между заказчиком и исполнителем (и которые, в отличие от ТЗ, вы сможете сделать).
Для того, чтобы приступить к обсуждению вашей автоматизации, подрядчику нужно понять задачу. Хотя бы на самом верхнем уровне получить информацию о вашей компании, чем она занимается, какие процессы в ней есть, сколько людей работает и какие функции эти люди выполняют.
Чтобы вам было проще структировать свои мысли, идеи, планы и описание текущей ситуации в бизнесе – можно воспользоваться анкетой или опросником.
Например, вы можете скачать наш опросник, и заполнить его перед тем, как начать общение с потенциальными исполнителями и выбор компании с которой будете работать.
Цели проекта – это очень важно. Каждому клиенту мы говорим, что «внедрить 1С» это не цель. Согласитесь, если бы бизнес мог стабильно расти, развиваться, и ему не нужна была бы никакая система, никто не стал бы покупать ни желтые коробки, ни лицензии, ни дорогостоящие услуги консультантов и внедренцев.
Подумайте, зачем вы все это хотите начать? Запишите письменно эти цели. Обозначьте цели подрядчику, и спросите, как он будет их достигать. Правильный подрядчик – будет рад тому что у вас такое четкое видение проекта, и вы сразу станете у него любимым клиентом.
Хорошими формулировками целей может быть:
- Сейчас я получаю управленческую отчетность спустя месяц, после того как закрылся квартал. Хочу получать достоверную управленческую в моменте отчетность в любой день, за период с начала квартала по текущую дату.
- Сейчас выполнение заказа на производство занимает 10 дней. Хочу за счет согласованных усилий специалистов, и организованных закупок, сократить срок выполнения заказа до 5 дней.
- Сейчас мы пользуемся системой excel файлов на сервере, в которые заносят информацию сотрудники, при этом происходят ошибки, иногда файлы затираются, сотрудники путают версии, сбиваются ссылки. Хочу получать те же самые показатели, но из системы, полностью избавившись от всех excel файлов.
Мы взялись ответить на вопрос «как написать ТЗ на 1С проект», и надеюсь смогли разобраться, что:
- ТЗ бывает разное. «Большое» ТЗ – это техническое задание по ГОСТу, и вам оно врядли нужно.
- Есть «ЧТЗ» (частное техзадание) – это конкретный вид документа, нужный в разработке на 1С.
- ТЗ (если это действительно ТЗ) должны писать сильные технические специалисты, заказчик, если он не глубоко погружен в технологии, вряд ли сможет его написать, и не должен этого делать.
- Есть альтернатива, ФТ. Функциональные требования заказчик может написать, и может понять, что в них написано.
- Удобнее найти подрядчика, который напишет ФТ сам (сначала допросит вас, а потом напишет на человеческом языке как все будет выглядеть и работать). И не будет вас «загружать» с ТЗ и тем более требовать от вас этот документ.
- Для того, чтобы сформулировать свои мысли, ожидания от информационной системы, требования к ней, можно подумать и записать ваши цели, и заполнить опросник/бриф. Например, взяв за основу наш.
Буду рад, если статья оказалась вам полезной. И если вы задумаетесь о внедрении 1С, вы не станете тратить время и моральные силы, на попытки создать ТехЗадание. Оставьте лучше энергию на проект, там она вам точно пригодится.