Привет! Спасибо за полезный контент. Вопрос: ты пишешь, что спецификация «По итогу ускорят и удешевляет разработку». Если я правильно понял, то ФТ + спецификация позволяет очень точно оценить проект с точки зрения разработки, но по итогу над проектом же дизайнер будет еще работать и финальным артефактом, в который будет смотреть разработчики будет макет Figma, скорее всего. Получается, что в этом случае спецификация и прототип теряют (хоть и не полностью) свою актуальность?
Да, если дизайнер начнёт придумывать новые функции и менять расположение элементов из прототипа, то прототип и спецификация потеряют свою актуальность. Новые функции, придуманные дизайнером, необходимо будет декомпозировать и описывать (дизайнер вряд ли будет этим заниматься). Если такое происходит, то, скорее, по вине менеджера проекта, нежели дизайнера :) Финальный артефакт, в который будут смотреть разработчики, зависит от разработчиков. На моей практике те, что младше сеньоров, в принципе не читают документацию и берутся за работу, должным образом её не оценив. Тут всё упирается в управление проектом, в команду, а также в методики проектирования и разработки. У каждого свой подход. Я делюсь своим.
Привет, Егор! Спасибо, очень интересно. Вопрос. Используешь ли в своих документах диаграммы (например UML), блок-схемы и т.п.? Мне кажется они добавляют наглядности и способствуют лучшему пониманию клиентом, разработчиком.
Привет, Егор! Полезное видео! ФС для описания поведения мобильной версии ты выносишь в отдельный документ или делаешь всё в одном? Если последний вариант, какие-либо отличия мобилки от десктопа выносишь на уровень тезисов?
В последний раз я проектировал мобильную версию информационной системы ещё в те времена, когда не писал функциональных спецификаций. Сейчас это либо мобильные приложения, либо адаптивные версии. А при адаптации интерфейсов набор их функций не теряется. Поэтому функциональная спецификация вообще не затрагивает этого момента. Все различия максимально очевидны в дизайн-макетах для разных точек слома.
Это даже не бизнес-логика, а текстовое описание работы пользовательской части интерфейса. А внутреннее описание работы всех задействованных систем, то, как они обмениваются данными, где эти данные хранятся и в каком виде, все это выходит за рамки компетенций проектировщика и делается обычно системным аналитиком. Ну и это документ не на 40 страниц будет, а чуть побольше.
Хороший вопрос. Я действительно заплатил эту сумму самому себе. В том конкретном случае у меня был выбор - потратить своё время, эквивалентное этой сумме, на написание ФС, либо заняться чем-то другим. У меня была роль ПО (product owner) и задач хватало. И вот в одном случае я махнул рукой, мол «и так справятся». А в другом я сел и потратил свои часы на документ. Количество денег я посчитал исходя из того, сколько инвестор платил в месяц за мою часть работы. А позже я уже поручал это дело своему штатному проектировщику.
Кажется, что имея интерактивный прототип и такой документ у дизайнеров и разработчиков уже нет шанса сделать что-то не правильно, это так? Или есть ещё серые области?
Шансов сделать что-нибудь неправильно всё ещё полно. Но мы в любом случае значительно их уменьшаем. А самая серая область по моему опыту заключается в том, что редкий дизайнер решится прочитать даже 40-страничный документ и будет работать по прототипу и наитию. И ещё более редкий разработчик прочитает этот документ и будет оценивать работу по дизайну и примерному представлению о том, сколько у него ресурсов в прошлом заняло сделать подобный проект :)
@@Ekamelev Звучит не очень. Может быть, тогда стоит придумать другой инструмент? Типа СФ в форме тик-ток видео по музыку, что бы и полезно и интересно ;-)
@@jean_peres Да не, всё нормально. Я описал распространённую практику. В своих проектах и в проектах, которые под моим авторским надзором, я слежу за тем, чтобы исполнители не брались за работу наобум и там документация здорово помогает. А остальные меня мало волнуют :)
Ура! Егор Камелев снова в деле! С возвращением!
Спасибо за поддержку!
Привет! Спасибо за полезный контент. Вопрос: ты пишешь, что спецификация «По итогу ускорят и удешевляет разработку». Если я правильно понял, то ФТ + спецификация позволяет очень точно оценить проект с точки зрения разработки, но по итогу над проектом же дизайнер будет еще работать и финальным артефактом, в который будет смотреть разработчики будет макет Figma, скорее всего. Получается, что в этом случае спецификация и прототип теряют (хоть и не полностью) свою актуальность?
Да, если дизайнер начнёт придумывать новые функции и менять расположение элементов из прототипа, то прототип и спецификация потеряют свою актуальность. Новые функции, придуманные дизайнером, необходимо будет декомпозировать и описывать (дизайнер вряд ли будет этим заниматься). Если такое происходит, то, скорее, по вине менеджера проекта, нежели дизайнера :) Финальный артефакт, в который будут смотреть разработчики, зависит от разработчиков. На моей практике те, что младше сеньоров, в принципе не читают документацию и берутся за работу, должным образом её не оценив. Тут всё упирается в управление проектом, в команду, а также в методики проектирования и разработки. У каждого свой подход. Я делюсь своим.
Привет, Егор! Спасибо, очень интересно.
Вопрос. Используешь ли в своих документах диаграммы (например UML), блок-схемы и т.п.? Мне кажется они добавляют наглядности и способствуют лучшему пониманию клиентом, разработчиком.
Нет, обычно не использую.
Привет, Егор! Полезное видео!
ФС для описания поведения мобильной версии ты выносишь в отдельный документ или делаешь всё в одном? Если последний вариант, какие-либо отличия мобилки от десктопа выносишь на уровень тезисов?
В последний раз я проектировал мобильную версию информационной системы ещё в те времена, когда не писал функциональных спецификаций. Сейчас это либо мобильные приложения, либо адаптивные версии. А при адаптации интерфейсов набор их функций не теряется. Поэтому функциональная спецификация вообще не затрагивает этого момента. Все различия максимально очевидны в дизайн-макетах для разных точек слома.
А ссылку на документ для ознакомления ?
Это же просто бизнес-логика. А где системная часть?
Думаю, что смогу ответить на ваш вопрос, если вы объясните, что такое «бизнес-логика» и что такое «системная часть».
Это даже не бизнес-логика, а текстовое описание работы пользовательской части интерфейса. А внутреннее описание работы всех задействованных систем, то, как они обмениваются данными, где эти данные хранятся и в каком виде, все это выходит за рамки компетенций проектировщика и делается обычно системным аналитиком. Ну и это документ не на 40 страниц будет, а чуть побольше.
@@НикитаНаджаров зачем тогда роль проектировщика, если есть аналитик и дизайнер?!
что то непонятно в видео говоришь что сам писал и тут же что за это заплатил 50т р кому? если её писал ты
Хороший вопрос. Я действительно заплатил эту сумму самому себе. В том конкретном случае у меня был выбор - потратить своё время, эквивалентное этой сумме, на написание ФС, либо заняться чем-то другим. У меня была роль ПО (product owner) и задач хватало. И вот в одном случае я махнул рукой, мол «и так справятся». А в другом я сел и потратил свои часы на документ. Количество денег я посчитал исходя из того, сколько инвестор платил в месяц за мою часть работы.
А позже я уже поручал это дело своему штатному проектировщику.
Кажется, что имея интерактивный прототип и такой документ у дизайнеров и разработчиков уже нет шанса сделать что-то не правильно, это так? Или есть ещё серые области?
Шансов сделать что-нибудь неправильно всё ещё полно. Но мы в любом случае значительно их уменьшаем. А самая серая область по моему опыту заключается в том, что редкий дизайнер решится прочитать даже 40-страничный документ и будет работать по прототипу и наитию. И ещё более редкий разработчик прочитает этот документ и будет оценивать работу по дизайну и примерному представлению о том, сколько у него ресурсов в прошлом заняло сделать подобный проект :)
@@Ekamelev Звучит не очень. Может быть, тогда стоит придумать другой инструмент? Типа СФ в форме тик-ток видео по музыку, что бы и полезно и интересно ;-)
@@jean_peres Да не, всё нормально. Я описал распространённую практику. В своих проектах и в проектах, которые под моим авторским надзором, я слежу за тем, чтобы исполнители не брались за работу наобум и там документация здорово помогает. А остальные меня мало волнуют :)