Трибуна
Anton Breslavsky

Spec Projector — сервис по разработке технического задания на программные продукты

О том, как разработать техническое задание для вашего ИТ-продукта, навести порядок в процессах разработки и автоматически создавать описание задач для программистов.

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

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

Мы разрабатываем web-приложения на заказ, и в работе одновременно у одной команды на разных стадиях может быть 3-5 проектов (в т.ч. на поддержке). Разработчики могут получать задачи в разных проектах, и у них нет времени погружаться в проект — им нужно четко выполнить, что написано в задании.

Я часто работал одновременно как разработчик и как проджект-менеджер. Мне неоднократно приходилось писать ТЗ и каждый раз я «испытывал боль» — я читал ГОСТы, изучал UML, рисовал диаграммы и схемы в поиске идеальной модели данных и четких юзкейсов и т.д., но всегда сталкивался с несколькими проблемами:

  1. ГОСТы и UML хорошо, но в реальности мало кто умеет правильно этим пользоваться, понимать и интерпретировать.
  2. Отсутствие нормальных инструментов для рисования диаграмм и быстрого доступа к ним. Чаще всего редакторы — это обычные «рисовалки» без привязки в методологии и стандартам.
  3. Можно использовать PlantUML но исходный код диаграмм где-то нужно хранить, и публиковать рендеры. Было время, когда для этого я использовал Git с рендером через CI/DI. И все бы ничего, но как показывает практика, чем больше нужно сделать действий, тем меньше хочется куда-то идти и что-то править/актуализировать.
  4. В случае каких-либо ошибок, замеченных разработчиками в ТЗ в ходе разбора задач (даже мелких описок), менеджеру приходится идти править диаграммы, потом снова аттачить в задачи и т.д. — синдром перфекциониста.
  5. Проектная документация рано или поздно устаревает, отстает от исходного кода и это, пожалуй, главная причина, почему после первой итерации на поддержку документации уже забивают, а единственным местом знаний о системе становится код.

Среди всех испробованных вариантов лучшим местом для написания ТЗ оказался Google Docs:

  1. Все в облаке и по ссылке. В описании задач разработчикам предоставляются ссылки на соответствующие разделы ТЗ.
  2. Быстрый доступ и правки прямо на месте в случае ошибок или неточностей.
  3. Комментарии и предложения по правкам.
  4. Есть вся история изменений. Почти как GIT: -)
  5. Можно давать права на чтение и редактирование.

Чего не хватает:

  1. Жестких рамок по созданию ТЗ.
  2. Дополнительных инструментов типа: проектирование модели данных, описание пользовательских историй и т.д.
  3. Более удобной навигации.
  4. Возможности поддерживать ссылочную целостность. Например, переименовали поле в модели данных, а на него есть ссылка в GraphQL API или REST.
  5. Разделения прав, например, дизайнеру не нужно править API, а программисту — экраны дизайна. Разработчикам не нужно видеть стоимость фичей, по которым мы работаем с клиентом.

Конечно же, есть еще wiki или Confluence, но проблемы были аналогичные — отсутствие рамок и следования конкретному процессу.

Т.к. я люблю программировать и недавно «игрался» с PouchDB, вызов был принят :-)

Так появился
Spec Projector — место для хранения проектной документации для web-приложений.

По сути, это аналог Google Docs для ТЗ, где:

  1. Можно определить состав фичей приложения по актерам и эпикам.
  2. Написать пользовательские истории для каждой фичи.
  3. Определить необходимые ресурсы и стоимость фичи для клиента.
  4. Согласовать с клиентом стоимость фичей, итераций и всего проекта.
  5. Передать истории дизайнеру — он загрузит отрисованные экраны.
  6. Фронтенд-программист, смотря на истории, дизайн и прототип, спроектирует и опишет модель данных и API.
  7. Бекенд-программист реализует модель данных и API.
  8. Тестировщик закрепит чек-листы для проверки качества реализации фичей.

Немного скриншотов

Процесс более подробно

Менеджер проекта определяет функциональный состав в виде:

Актер X

  1. Фича 1 — Эпик A
  2. Фича 2 — Эпик B

Актер Y

  1. Фича 3 — Эпик B
  2. Фича 4 — Эпик C

Далее процесс по созданию каждой фичи:

1. Планирование

  1. Менеджер проекта пишет пользовательскую историю в режиме интервью с заказчиком в виде: я вижу, я могу.
  2. Дизайнер, используя историю, рисует дизайн интерфейса и собирает прототип фичи в Figma, закрепляя фреймы.
  3. Проджект-менеджер согласовывает дизайн и прототип с заказчиком.
  4. Проджект-менеджер ставит задачу лидеру фронтенд-разработки на проектирование API в GitLab.
  5. Лидер фронтенд распределяет задачи между своими разработчиками на проектирование API.
  6. Фронтенд-разработчики определяют данные, которые нужно отправить/получить на соответствующих экранах дизайна для работы фичи. В результате получаем модель данных и вызовы API: REST или GraphQL.
  7. Лидер команды фронтенд делает ревью спецификации и закрывает задачи.
  8. Тестировщик закрепляет чек-листы для проверки качества реализации.

2. Реализация

  1. Лидер команды фронтенд ставит задачи на реализацию фичи на мок-данных (API еще не готов) для своих разработчиков.
  2. Проджект-менеджер ставит задачу лидеру бекенд на разработку API.
  3. Лидер бэкенда распределяет задачи между своими разработчиками на реализацию API.
  4. Разработчики бэкенда реализуют API, пишут тесты.
  5. Лидер бэкенда делает ревью и принимает код.
  6. Фронтенд-разработчики переключаются с моков на API.
  7. Лидер фронта делает ревью и принимает код.
  8. Код деплоится, фича опубликована.

3. Тестирование

  1. Тестировщик проверяет фичу по чек-листам.
  2. Тестировщик находит баги и назначает задачи на лидера фронтенд.
  3. Лидер распределяет баги между разработчиками и принимает код.
  4. В случае ошибок в API фронтенд-разработчики создают задачи для бэкенд-разработчиков и ожидают фиксов.
  5. Тестировщик все еще раз проверяет и закрывает задачу.

4. Презентация

  1. Проджект-менеджер проводит контроль качества.
  2. Проджект-менеджер делает презентацию фичи клиенту.
  3. Клиент выдает замечания.

Планы на будущее

  1. Единый словарь терминов и синонимов c возможностью вставки в пользовательские истории, ассоциации с моделью данных, API и т.д. Например в ТЗ есть термин «Вакансия». Один разработчик к коде напишет class Vacancy другой class JobOffer. Так быть не должно.
  2. Валидация ТЗ.
  3. Экспорт модели данных, например, в Strapi или Django.
  4. Экспорт REST API в Swagger.
  5. Маркетплейс спецификаций, где можно взять/купить готовое ТЗ и адаптировать под свой проект.
  6. Маркетплейс команд, с возможностью получения оценок от разных компаний по реализации Вашего ТЗ.
  7. Интеграция с таск-трекерами. Все запланированные фичи можно экспортировать одной кнопкой с описанием задач и связями с ТЗ. Далее, отслеживая трек времени в задачах, можно сравнить разницу с оценками, т.е. насколько «вылетели».
  8. Возможности выставлять счета клиентам и согласовывать стоимость фичей прямо в системе.

Главный вопрос к Вам, друзья, — как думаете — полезный продукт? Хотели бы Вы попробовать этот сервис для ведения своих проектов?

Ну и для тех кто дочитал — как пример, ссылка на документацию одного из наших проектов Team Projector на примере описания одной из фичей (лучше пока открывать в десктопе).

P.S. Есть у кого опыт продаж IT-сервисов? Очень ищем в команду.

{ "author_name": "Anton Breslavsky", "author_type": "self", "tags": [], "comments": 81, "likes": 62, "favorites": 274, "is_advertisement": false, "subsite_label": "tribuna", "id": 199094, "is_wide": false, "is_ugc": true, "date": "Fri, 22 Jan 2021 09:48:32 +0300", "is_special": false }
0
81 комментарий
Популярные
По порядку
Написать комментарий...
13

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

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

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

Если посмотреть, что это значит для бизнеса, то это не инструмент улучшения производительности команды, а инструмент для увольнения дорогих разработчиков и замены их на более дешевых :) Которые не справляются на высоких уровнях абстракции, зато справятся на низких. Дальше им можно нарубить задачек, посадить в жесткие рамки и работать. См. микротаскинг имени Бугаенко. https://www.youtube.com/watch?v=VLaGrUsCbYo

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

PS Если реально получится инструмент для микротаскинга, то будет интересно попробовать. 

Ответить
1

Прям для совсем микротаскинга не могу не посоветовать свой pet-проект(бесплатный):
https://greentask.in/

Сделал уже лет 5 назад. Удобно быстро набросать ТЗ, и по ссылке дать.
Есть разные плюшки вроде комментов, доступов и тд.

Сорри если не совсем в тему, может кому пригодится

Ответить
0

а инструмент для увольнения дорогих разработчиков и замены их на более дешевых

Но это будет работать только с действительно опытными ПМ, аналитиком, дизайнером и техлидом. И то им следовало бы вырабатывать требования совместно, а не последовательно.

Ответить
0

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

Ответить
1

Тогда есть риск подписаться на невыполнимые требования. Неоднократно с таким сталкивался на практике. Это может привести к серьёзному срыву сроков, штрафам и судам. Проходили уже такое.

Ответить
1

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

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

Ответить
1

Именно про подобное я и говорю.

Ответить
0

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

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

Ответить
0

Это жёсткий водопад?

Ответить
0

Скорее да...

Ответить
7

Вы для чего-то перепридумали Gherkin и BDD. Но такие спеки это всегда overhead и описание функциональности можно донести в гораздо более в удобном и понятном виде.

По поводу схем, их главное назначение - это дополнительный контекст или новое представление требований для разработчика. Не нужно тупо следовать всем стандартам UML (для описания бизнес-процессов лучше смотрите в BPMN) просто чтобы было.

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

Ответить
2

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

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

Ответить
0

Не могу согласиться.

На фронтент. Написана пользовательская история, нарисован дизайн и кликабельный прототип, закреплены чек-листы для проверки типа: "После нажатия кнопки выполняющей запрос на сервер, система должна отобразить прогресс". Бери свой опыт, смотри описание и делай.

На бекенд. Есть описание данные которые отправляются на сервер и которые нужны. Описана модель данных, описана логика работы.

Где может быть проблема?

Ответить
5

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

PS Я ниже еще дал более развернутый комментарий - в целом подход имеет право на жизнь, если его правильно спозиционировать. 

Ответить
1

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

Spec Projector - это место работы для всей команды.

Ответить
0

Разработчики не будут добровольно делать модель данных, для них ведь это двойная работа. Зачем мне писать в каком-то еще сервисе "i see [widget] on [dashboard]", если я буквально то же самое могу написать в фронтовом коде своего приложения? 
Максимум на что меня хватит - задокументировать метод. 

Ваша нотация будет работать только в качестве интерфейса между разработчиками и кем-то еще. 

Ответить
0

Это пишет не разработчик, а Project Manager для отрисовки дизайна и прототипа дизайнером.

По сути работы PM сводится к правильному определению состава фичей и описания пользовательских историй и сценариев работы бизнес-логики. Все остальное заполнят сами разработчики. А будущих задачах у всех будут релевантные ссылки на части проектной документации.

Ответить
0

 Где может быть проблема?

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

Ответить
0

Конечно, главное что бы можно было быстро добавить их, описать и допланировать.

Ответить
1

Спасибо за развернутый отзыв. Как раз таки следующим этапом мы хотели внедрить описание сценариев на Gherkin для фичей с последующим экспортом их в GIT проекта.

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

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

Ответить
1

Лучше сделать нормальное описание, чем потом утонуть в уточнениях и "митинагах".

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

Ответить
0

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

Ответить
0

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

Ответить
1

Мне кажется это уже крайности :-)

Ответить
0

А у вас так по процессу получается. Задачи поступают к разработчикам уже после утверждения бизнес-процесса и отрисовки дизайна. Есть ли там какие-либо технические ограничения — никого не волнует.

Ответить
0

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

Ответить
0

Пользовательскому интерфейсу? Как раз таки в данном случае у нас user story с "я вижу", "я могу" описывает пользовательский интерфейс, а сценарии в Gherkin описывают логику работы системы (бекенд) - бизнес-требования.

Ответить
3

Спасибо! Очень интересный продут! 

Думаю, стоит попробовать :)

Ответить
1

Спасибо, отпишусь Вам в личку что бы сделать аккаунт.

Ответить
0

И мне тоже

Ответить
0

И мне

Ответить
2

Очень интересно. Я как проджект попробовал бы со своими командами.

Ответить
0

Разработчикам не нужно видеть стоимость фичей

Почему?

Ответить
5

Имеется ввиду разработчикам в штате. Компания продала фичу за 5000$ по ставке 40$ за разработчика, а платит разработчикам 20$. Все остальное это менеджмент, прибыль, развитие и т.д. Зачем видеть разработчику финансовые взаимоотношения компании с их клиентами.

Ответить
1

Справедливо. Незачем дизморалить галеры. 

Ответить
4

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

Ответить
0

 Организовать людей, выстроить процессы, найти клиентов, наверное тоже чего-то стоит?

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

Ответить
0

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

Ответить
1

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

А если не заработает?

У вас там что детский сад работает? Такое ощущение, будто вы считаете что разработчики - это не очень умные люди или вы набираете максимально дешевых специалистов.

Ответить
0

Не согласен с такой постановкой вопроса. У нас отличные специалисты с разным уровнем, что и образует команду. Я и сам разработчик и Тим Лид. И никто ни от кого ничего не прячет.

Ответить
0

Хорошо, что это не возможно, не к чему стремиться :)

Ответить
0

Инвайт плиз

Ответить
0

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

Ответить
0

Джира в данном случае это такс-менеджер. SP немного другое. Где Вы в джире планируете фичи (фича не задача, одна фича много задач)? Описываете историю? В каком формате? Как делаете описание для разработчиков?

Ответить
1

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

Ответить
0

Спасибо за поддержку диалога.
Предполагается, что один разработчик делает целую фичу? Куда аттачится дизайн по этой фиче? Что если есть фронтенд и бекенд, где им договориться о модели данных? Где описать API который будет реализован перед началом работы.

Ответить
0

Фича делится на стори масштаба, чтобы справился один разраб. Все (включая апи, бэк и фронт) описываются сторями

Ответить
0

Фулстек? Это очень дорогие и крутые разработчики. Но настоящих я не так много видел. Которые делают крутой фронт и при этом делают крутые и оптимальные запросы в ORM.

Ответить
0

Пишется junior, а не juniour

Ответить
0

Спасибо за замечание, но в этой статье не нашел "juniour"

Ответить
0

на втором скриншоте ;)

Ответить
0

Спасибо, поправим :-)

Ответить
0

1. Логотип не кликабельный
2. Авторизация через gitlab не работает. Как попробовать сервис?
3. UPD. В тестовом проекте комменты может добавлять незарегистрированный. Так и задумывалось?

Ответить
0

Сейчас это бета, забыли написать.

1. Спасибо, исправим.
2. Поправим.
3. В тестовом да, в качестве презентации. А так система прав еще в разработке.

Ответить
0

Идея интересная. Хотелось бы опробовать, как получить инвайт?

Ответить
0

 Написал в личку

Ответить
0

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

Ответить
0

Спасибо, отписал в личке.

Ответить
0

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

Ответить
0

Бинго, именно об этом мы и думали :-) Созвонимся? :-)

Ответить
0

Гербалайф продаете? или есть работа для такого гения как я?
На самом деле проблема есть с тем, что на фриланс биржах на каждый заказ вместо фрилансеров налетают неадекватные менеджеры студий, которые даже не читают ни описание, ни даже ТЗ, а просто кидают свои расценки безотносительно проекта, типа сделаем за 7000$ при том что в описании работы на 300 баксов

Ответить
0

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

Ответить
0

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

Ответить
0

Это все круто-классно! Но разве самый большой затык в инструменте, а не в том что заказчик хочет быстро и красиво, но не знает что именно?

Ответить
0

Это уже вопрос сбора требований. Общение с пользователи и т.д. 

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

Ответить
0

У меня один вопрос - эта штука пригодна для написания ТЗ клиентом? Поймет ли человек без бэка в ИТ, что куда писать?

Ответить
0

По идее да. Если Вы сможете написать историю в формате

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

То по сути этих данных уже хватит что бы отрисовать дизайн и прототип.

Ответить
0

Я бы попробовал с своей командой, а то сами уже в Gdocs сидим 4й год

Ответить
0

Любопытный продукт. Я для этого же использую jira с соотв. плагинами

Ответить
0

А можно если не сложно ссылки какие плагины? Будет очень полезно.

Ответить
0

Сложновато, еще учить заказчика пользоваться сервисом?

Ответить
0

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

Ответить
0

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

Такое "общение" с заказчиком предусмотрено?
И насколько просто оно устроено?

Я пока только "заблудился" в интерфейсе.
Хотелось бы видеть компактнее этапы работы и блоки модули.
Сложно ориентироваться, мне кажется...

Ответить
0

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

Ответить
0

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

Ответить
0

Отправил доступы в личку.

Ответить
0

Привет! Мы ваши "коллеги по ТЗ инструментам", представляем сервис по разработке ТЗ (spexfy.com). Было интересно ознакомиться с вашей презентацией и отзывами. Мы подходим к документу ТЗ немного под другим углом и с большей ориентацией на заказчика. Есть еще ряд отличительных моментов. Единственное, ваше видение "через ТЗ к фриланс площадке", мне кажется потерей времени и денег, хотя бы по той причине, что есть стоимость привлечения клиента и здесь вы будете жестко конкурировать с фриланс биржами.

Ответить
0

Интересный продукт, по типу квиза. У нас же задание именно на ПО.

По поводу фриланс площадки не совсем понял.

Ответить
0

Интересный продукт!
Однако, сломана авторизация через гитлаб (не заходит). Можно попросить учётку?

Ответить

Комментарии

null