Атлас трендов для бизнеса

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

Да, это его величество ТЗ (техническое задание) ну или RFP (request for proposal).

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

Заходим на сайт bing. com, выбираем притаившуюся вверху кнопку «Чат».
И попадаем к дружелюбному GPT-4.
Перед началом общения вам будет предложено выбрать из трех вариантов стилей ответов, от формальных и четких до творческих. Я предпочитаю работать в творческом режиме.

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

Допустим, у вас, как у заказчика, есть отличная идея.

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

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

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

Итак, задаем первую вводную.

Я попробую выполнить эту задачу.
Вот моя попытка написать техническое задание на разработку ПО для личного кабинета пользователя. ```markdown # Техническое задание на разработку ПО для личного кабинета пользователя
## 1. Введение
### 1.1. Назначение Цель данного документа - определить требования к разработке ПО для личного кабинета пользователя, который позволит просматривать бизнес-показатели компании в виде дашборда с графиками и диаграммами. Данный документ предназначен для заказчика и исполнителя проекта.
### 1.2. Область действия Данный документ описывает функциональные и нефункциональные требования к ПО для личного кабинета пользователя, а также ограничения и допущения, связанные с проектом.
### 1.3. Определения, акронимы и сокращения - ПО - программное обеспечение - ЛК - личный кабинет пользователя - Дашборд - интерактивная панель управления, отображающая ключевые бизнес-показатели компании в виде графиков и диаграмм - Эксель-файл - файл формата Microsoft Excel, содержащий данные для дашборда - Сайт - существующий веб-сайт компании, к которому должен быть подключен ЛК - Мобильное приложение - приложение для мобильных устройств на базе операционных систем iOS и android, реализующее функционал ЛК
### 1.4. Ссылки - Стандарты и шаблоны для ТЗ на разработку ПО ¹
### 1.5. Краткий обзор Данный документ состоит из следующих разделов: - Введение - содержит общую информацию о документе и проекте - Общее описание - содержит описание бизнес-потребностей заказчика, пользователей ПО, а также основных функций и характеристик ПО - Требования к ПО - содержит детальное описание функциональных и нефункциональных требований к ПО, а также ограничений и допущений, связанных с проектом - Приложения - содержат дополнительную информацию, необходимую для разработки ПО
## 2. Общее описание
### 2.1. Бизнес-потребности заказчика Заказчик является владельцем компании, занимающейся продажей товаров через интернет. Заказчик хочет иметь возможность просматривать ключевые бизнес-показатели своей компании в виде дашборда с графиками и диаграммами в любое время и с любого устройства. Заказчик также хочет иметь возможность загружать данные для дашборда из эксель-файлов, которые готовит его бухгалтер.
### 2.2. Пользователи ПО Пользователями ПО являются: - Заказчик - владелец компании, который х Источник: беседа с Bing, 20.04.2023 (1) https://habr.com/ru/articles/328822. https://habr.com/ru/articles/328822/.
Искусственный интеллект нужно подгонять – выдав страницу-другую текста, он останавливается. Можно его попросить продолжить стандартной фразой.
Хорошо, вот продолжение технического задания. ```markdown - Заказчик - владелец компании, который хочет просматривать бизнес-показатели своей компании в виде дашборда с графиками и диаграммами в любое время и с любого устройства. Заказчик также хочет иметь возможность загружать данные для дашборда из эксель-файлов, которые готовит его бухгалтер. - Бухгалтер - сотрудник компании, который готовит эксель-файлы с данными для дашборда. Бухгалтер не имеет доступа к ЛК, но может отправлять эксель-файлы заказчику по электронной почте или другим способом. \
### 2.3. Основные функции ПО ПО для личного кабинета пользователя должно обеспечивать следующие основные функции: - Авторизация пользователя на сайте и в мобильном приложении - Просмотр дашборда с бизнес-показателями компании в виде графиков и диаграмм - Выбор периода и типа данных для отображения на дашборде - Загрузка данных для дашборда из эксель-файлов - Обработка и валидация загруженных данных - Сохранение и обновление данных на сервере - Синхронизация данных между сайтом и мобильным приложением
### 2.4. Основные характеристики ПО ПО для личного кабинета пользователя должно обладать следующими основными характеристиками: - Простота и удобство использования - Надежность и безопасность данных - Совместимость с различными устройствами и браузерами - Адаптивность и отзывчивость интерфейса - Масштабируемость и производительность ## 3. Требования к ПО
### 3.1. Функциональные требования Функциональные требования описывают, что должно делать ПО для личного кабинета пользователя.
#### 3.1.1. Авторизация пользователя Пользователь должен иметь возможность авторизоваться на сайте и в мобильном приложении с помощью своего логина и пароля. Пользователь также должен иметь возможность выйти из своего аккаунта.
#### 3.1.2. Просмотр дашборда Пользователь должен иметь возможность просматривать дашборд с бизнес-показателями своей компании в виде графиков и диаграмм на сайте и в мобильном приложении. Дашборд должен отображать следующие показатели: - Выручка - Прибыль - Количество заказов - Средний чек - Конверсия - Отказы - Возвраты Графики и диаграммы должны быть интерактивными, то есть пользователь должен иметь возможность изменять масштаб, перемещаться по временной шкале, наводить курсор на точки данных и получать подробную информацию.
#### 3.1.3. Выбор периода и тип

И еще раз подпихнем робота, чтобы он не засыпал

Хорошо, вот продолжение технического задания.

```markdown

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

#### 3.1.6. Сохранение и обновление данных на сервере

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

#### 3.1.7. Синхронизация данных между сайтом и мобильным приложением

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

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

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

#### 3.2.1. Простота и удобство использования

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

#### 3.2.2. Надежность и безопасность данных

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

#### 3.2.3. Совместимость с различными устройствами и браузерами

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

- Windows 10 / Chrome / Firefox / Edge

- MacOS / Safari / Chrome / Firefox

- iOS / Safari / Chrome

- Android / Chrome / Firefox

ПО должно также адаптироваться под разрешение экрана и ориентацию устройства пользователя.

#### 3.2.4. Адаптивность и отзывчивость интерфейса

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

```markdown

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

#### 3.2.5. Масштабируемость и производительность

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

### 3.3. Ограничения и допущения

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

#### 3.3.1. Ограничения

- ПО должно быть разработано на основе существующего сайта компании заказчика, который использует следующие технологии: HTML, CSS, JavaScript, PHP, MySQL.

- ПО должно быть разработано в виде мобильного приложения для iOS и android с использованием следующих технологий: React Native, Firebase.

- ПО должно быть разработано в соответствии с бюджетом и сроками заказчика, которые составляют 500 000 рублей и 3 месяца соответственно.

#### 3.3.2. Допущения

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

- Заказчик не изменяет требования к ПО в процессе разработки без согласования с исполнителем.

- Заказчик обеспечивает доступ к своему сайту и серверу для разработки и тестирования ПО.

- Заказчик обеспечивает регистрацию и публикацию мобильного приложения в App Store и Google Play.

## 4. Приложения

### 4.1. Примеры эксель-файлов с данными для дашборда

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

| Выручка | Прибыль | Количество заказов | Средний чек | Конверсия | Отказы | Возвраты |

|---------|---------|--------------------|-------------|-----------|--------|----------|

| 1000000 | 200000 | 500 | 2000 | 5% | 10% | 2% |

| 1200000 | 250000 | 600 | 2000 | 6% | 9% | 1% |

| ... | ... | ... | ... | ... | ... | ... |

Это файл с абсолютными данными за месяц.

| Выручка | Прибыль | Количество заказов | Средний чек | Конверсия | Отказы | Возвраты |

|---------|---------|--------------------|-------------|-----------|--------|----------|

| +20%
Хорошо, вот продолжение технического задания.

```markdown

| +20% | +25% | +20% | 0% | +1% | -1% | -1% |

| +15% | +20% | +15% | 0% | +1% | -1% | -1% |

| ... | ... | ... | ... | ... | ... | ... |

Это файл с относительными данными за месяц.

| Выручка | Прибыль | Количество заказов | Средний чек | Конверсия | Отказы | Возвраты |

|---------|---------|--------------------|-------------|-----------|--------|----------|

| 1000000 | 200000 | 500 | 2000 | 5% | 10% | 2% |

| 1005000 | 201000 | 505 | 1990 | 5.1% | 9.8% | 1.9% |

| ... | ... | ... | ... | ... | ... | ... |

Это файл с динамическими данными за день.

### 4.2. Примеры графиков и диаграмм для дашборда

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

![Выручка и прибыль за месяц](https://i.imgur.com/6Y7wZlT.png)

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

![Количество заказов и средний чек за месяц](https://i.imgur.com/7yjQgXr.png)

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

![Конверсия, отказы и возвраты за месяц](https://i.imgur.com/8fRZx4M.png)

Это круговая диаграмма, которая показывает конверсию, отказы и возвраты компании за месяц в процентах.

![Выручка и прибыль в реальном времени](https://i.imgur.com/9p6vLgN.png)

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

```markdown

## 5. Заключение

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

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

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

## 6. Список литературы

: Стандарты и шаблоны для ТЗ на разработку ПО [https://habr.com/ru/articles/328822/](https://habr.com/ru/articles/328822/)

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

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

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