Как составить тех задания для it отдела

Или как же избежать траты времени и бессмысленного слива денег на неудачные внедрения 1С?

Основываясь на 23-х летнем опыте работы в бизнесе ИТ- компании, я четко могу сказать что в 90% случаев всех обращений клиентов за внедрением 1С, разработкой или автоматизацией нет четко сформулированной задачи и критериев результата. Это приводит к недопониманию целей и процесса реализации, к неожиданным объемам работ и нехватки выделяемого бюджета.

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

Все вышеперечисленное совершенно не говорит о том, что заказчик не знает что ему нужно. Это значит, что он не может донести свою мысль, свою идею до собственной ИТ- службы или компании — разработчика.

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

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

При других вариантах – даже если программист 1С вам озвучит что да, он все понял, имейте ввиду, что понял настолько, насколько он понимает ваш процесс и вашу специфику.

Рассмотрим кейс одной компании «Не идет баланс»:

Звонок бухгалтера программисту 1С: «Вадим, мне срочно нужно исправить баланс, он не идет на 5000 рублей!» Мысли программиста 1С: «Не идет актив с пассивом, сейчас открою форму отчета через конфигуратор, и допишу в формуле пассива «-5000» и делов то!» Выполняет задание, проходит 10 минут, программист сообщает бухгалтеру что все выполнено, пусть проверяет.

Бухгалтер счастлива, какой с ней замечательный специалист работает, берет дешево, делает быстро, просто волшебник!

А теперь давайте разберем этот кейс с помощью следующих вопросов:

· Правильно ли понял ее специалист?

· Соответствует ли решение истиному запросу бухгалтера?

· Устраивает ли полученный результат работы специалиста бухгалтера?

· По каким критериям проводится приемка работ?

Предположим что у нас опытный главный бухгалтер, который имеет представление о принципах двойной записи в учете. А вот программист 1С – умеет программировать, но не знает бухгалтерского учета, но не говорит об этом бухгалтеру.

· При постановке задачи «не идет баланс» она озвучила ожидаемый результат, что в итоге она хочет решить, но не обозначила что хочет знать в чем конкретно причина отклонения;

· Разработчик 1С понял задачу ровно так, как ее поставили, если не идут две колонки отчета их нужно уравнять в формуле расчета этих колонок.

· Метод решения направлен не на исправление и поиск ошибки в учете, а на механику формирования отчета.

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

· Главное, какой критерии приемки работ ожидается бухгалтером, механика отчета или поиск причины выявленного отклонения и ее исправление.

Кейс от компании «У нас процессы согласования как у всех»:

Запрос от директора производственного предприятия по внедрению внутреннего электронного документооборота в компании.

Целью озвучено «автоматизация процесса согласования рассмотрения договоров от поставщиков». Сейчас на предприятии процесс происходит на протяжении 2-3 недель, потому что очень много ответственных в листе согласования.

Запрос: «Рассчитайте нам стоимость внедрения 1С Документооборота, и побыстрее, процессы у нас такие же как во всех предприятиях. Ждем от вас предложение, выбираем по цене конечно, же. Где дешевле, там нам выгоднее».

Вопрос от специалиста 1С для осуществления расчета трудозатрат по внедрению 1С: «Можете ли предоставить зафиксированный процесс согласования, существующий сейчас в зависимости от вида документа? Есть ли какие либо особенности, например по договорам до 100 тысяч рублей, или более 100 тысяч рублей?

Ответ со стороны заказчика: «Вы же профессионалы, вам виднее, вы сами все должны знать. Ждем предложение по внедрению 1С»

Результат таких запросов очень часто бывает следующим:

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

· подготавливается коммерческое предложение по внедрению программы, в которое закладываются существенные возможные риски (те кто уже попадал в первый вариант развития событий) и снова провал, стороны не договорились, потому что цены слишком высокие и непонятно из чего взяты для расчета;

Как же избежать траты времени и бессмысленного слива денег на неудачные проекты? Возвращаемся к нашим вопросам:

• Четко ли поставлена задача? – конечно нет

• Правильно ли понял ее специалист 1С? – понял из своего опыта (заложил риски своих неудач)

• Соответствует ли решение истиyному запросу директора? – я бы сформулировала цель следующим образом: «Сейчас компания теряет… . тыс. рублей из-за длительных сроков согласования внутри компании, во сколько нам обойдется внедрение этого процесса, чтобы ускорить процесс до 2-4 часов»

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

• По каким критериям проводится приемка работ? – критерии не были озвучены

Так что же делать?

В кейсах, уже есть наводка на вектор направления для решения. Но немаловажным фактором является фиксация информации и закрепление ее с двух сторон на старте внедрения 1С.

Одним из эффективных источников фиксации информации является составление технического задания.

Давайте рассмотрим структуру технического задания со стороны заказчика:

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

Например: создание дублирующего справочника «причины отказа клиентов» от заказа клиента, или дублирование «Сегмента номенклатуры».

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

Эти данные необходимы для уточнения и согласования деталей по задаче. Иногда ответственным назначают человека, до которого очень сложно достучаться из-за его высокой загруженности, или он отсутствует на предприятии продолжительное время (отпуск, больничный, командировки). А от этого будут зависеть сроки приемки и тестирования работ;

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

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

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

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

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

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

От ответа на этот пункт зависит включается ли в объем работ время на загрузку и выгрузку копий для разработки, на организацию бэкапов этой базы, в случае объемных работ.

Очень важно сформулировать задачу правильно и четко.

Не корректный вариант: создайте обработку по замене сырья в спецификациях.

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

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

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

Технолог получает задачу от директора по производству заменить наименование импортного сырья на российский аналог с 01.04.2022 года.

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

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

Пример что хотим: Технолог, получив задание от начальника производства формируем журнал спецификаций в базе 1С:ERP (1С:Управление производственным предприятием). Через отбор выбирает сырье, которое необходимо заменить, проставляет на какое сырье требуется заменить. При этой манипуляции старые спецификации сохраняются по сроку действия, так как они уже запущены и участвуют в выпуске продукции. А новые спецификации с российским аналогом сырья начинают действовать с определенной даты и будут задействованы при оформлении нового заказа в производство. Технолог должен успевать в срок до 1 дня по исполнению задачи по замене сырья в спецификациях, при этом списание сырья при выпуске продукции должно производится по действующей спецификации на момент запуска заказа в производство.

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

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

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

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

Пример: Технолог заходит под своим пользователем в 1С:ERP, открывает раздел АРМ Технолога, выбирает импортное сырье и осуществляет отбор спецификаций со статусом «действующая». Выбираем позицию для замены из российского сырья, проставляет коэффициент списания по сравнению с импортным сырьем и запускает обработку. Фиксируем время выполнения – тайминг.

Начальник производства заходит под своим пользователем в 1С:ERP, производит тестовый запуск нового заказа на производство, делаем тестовый выпуск продукции и проверяем по каким спецификациям списалось сырье на выпуск.

Если обнаруживаются отклонения – фиксируем его в протокол тестирования для дальнейшей отработки с разработчиками.

Заходим в 1С:ERP под пользователем бухгалтер, пробуем изменить спецификацию. Если обнаруживаются отклонения, снова фиксируем в протокол тестирования.

Важно прописать измеримые и понятные показатели. Например:

· технолог на замену спецификаций должен потратить не более 4 часов;

· корректность данные проверяется сопоставлением с отчетом «Ведомость по остаткам на складах» по графе списание за день;

· оформление заказа клиента у менеджера должно занимать не более 5 секунд при звонке постоянного клиента с подбором истории продаж;

· списание сырья на основании выпуска из производства должно соответствовать количеству в действующей спецификации на дату запуска заказа;

Расчет экономического эффекта важен для понимания сколько средств вы сэкономили для компании, сопоставив их с объемом средств по разработке/ внедрению 1С в процессы компании. Исходя из этих данных и формируется понимание эффективного сотрудничества с ИТ специалистами.

Например: перевод диспетчерской службы 7 подразделений Хлебозавода на 1С:ERP сэкономила компании более 776 400 рублей ежемесячно.

Расчет до внедрения: 7 заводов в каждом на приеме заказов работало по 3 диспетчера в смене при минимальной зарплате 12 000, график сутки через двое. Получаем сумму: 7 производственных площадок * 3 смены * 3 диспетчера * 12 000 (зп) = 756 000 ежемесячно + 24% налоги с ФОТ = 937 440 рублей ежемесячно.

Расчет после внедрения: централизовали диспетчерскую службу, перевели ее в управляющую компанию. В центральную диспетчерскую перевели 5 сотрудников, график работы Пн. -Пт., дежурства Сб, Вс не полным составом. Максимально автоматизировали прием заказов от торговых сетей без участия диспетчеров, прием заказов по телефону не более 5 сек. на заказ, при звонке через АТС программа сама определяет клиента и сразу выводит на экран диспетчеру заказ клиента в открытом виде с подобранными товарами которые они брали за последние 7 дней, цена уже стоит в заказе, диспетчеру осталось только количество внести со слов клиента. Средний чек по заказу вырос, так как программа автоматически подсказывает что еще клиент может заказать к Пасхе например. Итог: 5 человек * 26 000 рублей + 24% налоги с ФОТ = 161 000 рублей ежемесячно.

Экономия в результате автоматизации 776 400 рублей! Стоимость проекта на 2020 год по этому этапу составила 2,5 млн. рублей включая оборудование по IP телефонии. Затраты по проекту окупили себя за 3,5 месяца!

Когда подводится экономический эффект от внедрения, приходит понимание, что это того стоило.

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

Наша компания Soft+ 5 апреля 2022 года провела закрытую экспериментальную мастерскую «Напиши техническое заданием сам», направленную на подготовку пользователей 1С самостоятельно составлять технические задания как своим ИТ службам, так и ИТ компаниям.

В Мастерской приняли участие 18 представителей, среди которых наши клиенты, методисты и разработчики компании Soft+. Посмотрели на материал со всех заинтересованных сторон, определили как лучше отработать формат.

Эксперимент признали удачным, и мы готовы выпустить формат данной мастерской в общедоступный режим. Узнать подробнее вы можете на нашем сайте Витрина вебинаров Soft+ (soft-plus. ru)

Мария Эсмонтова, Управляющий партнер ИТ компании Soft+; Сертифицированный практик бизнес-ТРИЗ 2 уровня; +79272713948,

Структура ТЗ

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

Определение цели проекта

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

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

Полный бюджет проекта

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

Перечень необходимых работ

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

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

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

Тщательно описывается готовый продукт

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

Оценивание результата проекта

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

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

Сроки выполнения работ

Не может быть ТЗ без срока выполнения заказа. Да, бывают ситуации, когда изначально очень тяжело определить весь фронт работ. Или по мере выполнения штатных задач над проектом появляются форс-мажорные обстоятельства, которые вынуждают сдвигать конечные сроки выполнения работы. Но, в любом случае, хотя бы предварительное время работы над проектом должно быть.

Исполнителям срок исполнения заказа позволяет уже на начальном этапе объективно оценить свои потребности в ресурсах и трудозатраты (часы работы). Для заказчика – полное ориентирование в сроках работы, что позволяет планировать все свои остальные проекты. Часто бывает, что работа для данного ТЗ является только составной частью какого-то большого проекта. И он не может дальше продвигаться, пока не будет выполнена эта конкретная работа.

Будущее обслуживание проекта

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

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

Выявление проблем

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

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

Пример ТЗ для программиста

Приведем реальный пример технического задания для веб-разработчика на тему: «Доработка полей в CMS». Это ТЗ содержит следующие пункты с заданием:

• Цель проекта: доработать поля в CMS.
• Исходная информация. Произошла путаница с тем какое поле за что отвечает, в каком шаблоне, какой функционал. В итоге, слетела оптимизация этих элементов. Далее подробнее.
• Описание. Есть 2 типа страниц: записи и страницы. 

Ликбез по техническому заданию

Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.

Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).

Время чтения: 7 минут.

Отправная точка — требования

Хочу пирожное, потом морожное!
Вовка в тридевятом царстве

Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.

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

Жутко правда? Бюджет уже потрачен и срок истек.

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

Удобный вид требований — ТЗ

Замесить и нарубить!
Вовка в тридевятом царстве

Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.

Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.

Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.

Рецепт грамотного ТЗ

Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:

• Концептуальная модель
• Функциональная карта
• Путь пользователя
• Пользовательский интерфейс
• Программные интерфейсы
• Нефункциональные требования

Последние 2 пункта специфичны, советую на них обратить внимание читателям близким к разработке.

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

Концептуальная модель

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

Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.

Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.

Стоит рассказать о типах пользователей и их ключевых отличиях.

Например: “В приложении должны быть обычные пользователи и модераторы, которые получают жалобы от пользователей на контент или профили. Модераторы могут просматривать чат обычных пользователей после жалобы и заблокировать в сервисе нарушающий правила аккаунт”.

И в завершении расскажите о компонентах вашего продукта.

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

Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.

Функциональная карта

Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.

Очень важно отразить в функциональной карте все пользовательские особенности. В первом приближении это просто набор функций продукта.

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

Путь пользователя

Так называемый user flow или путь пользователя, это последовательный список действий или экранов, по которым может переходить пользователь в процессе взаимодействия с продуктом. Опишите, как в вашем представлении будет взаимодействовать с продуктом пользователь. Очень удобно это можно сделать также майнд картой или просто списком действий.

Например: “Пользователь заходит в приложение, чтобы познакомиться с сверстниками. Он заполняет свой профиль данными и загружает фото и видео. Затем пользователь заходит в ленту и фильтрует ее по каким-либо критериям. В качестве результата он получает список релевантных профилей, может посмотреть их и написать другому пользователю в чате.

Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.

Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.

Пользовательский интерфейс

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

• ukraine.craigslist.org
• www.theworldsworstwebsiteever.com (предупреждение, если вы страдаете приступами эпилепсии то не переходите по ссылке
• www.art.yale.edu

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

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

Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.

Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.

Программные интерфейсы

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

Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.

Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).

Нефункциональные требования

Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.

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

Советы

1. Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
2. Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
3. Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
4. Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
5. Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
6. Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.

Есть заказчик, идея, исполнитель, осталось передать требования к создаваемому продукту, чтобы обе стороны были довольны результатом. В таком случае понадобится техническое задание (ТЗ) — документ, в котором будет содержаться описание и характеристики итогового проекта. Чем тщательнее составлен этот документ, чем больше деталей там учтено, тем выше удовлетворенность результатом у заказчика и исполнителя. ТЗ — связующее звено между клиентом и разработчиком, необходимое, чтобы стороны разговаривали на одном языке.

Вещи, которые по началу кажутся сложными, мы лучше понимаем на простых примерах.

Например, вы хотите, чтобы все данные с заявок на сайте автоматически попадали в список рассылки «Заказы с сайта». Давайте посмотрим, как ставить такие задачи программисту без необходимости хоть что-то понимать в программировании.

3 способа связать сайт с сервисом рассылок

Прежде всего, нужно решить, как связать сервис email-рассылок с вашим или CRM-системой.

Вы можете использовать:

1. Готовые интеграции. Например, сервис UniSender интегрируется с популярными CRM-системами ,  CMS-системами и интернет-магазинами.
2. Интеграции с помощью Zapier – специального сервиса, который позволяет связывать разные системы не привлекая программиста. Как связывать сервисы через Zapier.
3. Интеграции по API.

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

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

Что за зверь такой – API?

По сути, это «язык», с помощью которого две системы (например, сайт и система рассылки) могут понимать друг друга и обмениваться данными.

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

Для того чтобы программист понял, что именно вы от него хотите, ему нужно это максимально детально объяснять.

Я в работе использую такую схему:

Пример работы этой схемы легко понять на известном меме:

А теперь разберём первую схему детальнее.

Что проработать в техническом задании. 5 элементов

1. Источник

Источник – это система, откуда мы берём данные.

Например, какой-либо сайт example.com или ваша CRM-система.

2. Триггер

Триггер – это событие, по которому данные должны передаваться.

Например, могут быть такие триггеры:

• посетитель на сайте заполнил и отправил форму «N»;
• пользователь зарегистрировался на сайте;
• авторизированный пользователь обновил данные о себе в личном кабинете, отписался от рассылки или изменил условия её получения;
• менеджер обновил статус клиента в CRM-системе на «N»;
• пользователь совершил заказ.

То есть, триггеры зависят от возможных действий пользователя на сайте или смены статусов в CRM-системе.

3. Данные

Какую именно информацию о пользователе мы передадим в систему рассылки, когда сработает триггер.

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

Например, на сайте есть форма заявки с такими полями:

• Ваше имя.
• Ваш email.
• Телефон.
• Город.

И мы хотим, чтобы данные автоматически попадали в группу «Заявки».

В системе рассылки поля «имя», «email» и «телефон» уже существуют по умолчанию. А вот поле «Город» нам некуда передавать, поэтому для начала его нужно создать в системе рассылки.

В сервисе UniSender это делается так: