Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Главное Свежее   Проекты
SketchBuilder

Кирилл Рассказчиков

Подписаться Написать
25 мар 2015 в 06:41
Подробная информация
Проекты пользователя
SketchBuilder
SketchBuilder - онлайн-инструмент для счастливого дизайна
sketchbuilder.com
Комментарии
0
Видили какую полемику мы развели с товарищем Юрием выше, о методологиях разработки ПО?

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

НО. Есть ряд методологий, в которых бизнес-аналитик разрабатывает москап будущего интерфейса, отображая на нём всю функциональность, что должна быть в GUI. Затем этот москап передается Юзабилите эксперту, который уже "правильно" распологает все элементы интерфейса, задает им размер и т.д., что бы им было удобно пользоваться. И только после этого москап попадает к дизайнеру, который по сути только "раскрашивает" интерфейс, задавая цвета элементам, добавляя какие-то декаративные вещи. А размер, форму, расположение, механику взаимодействия GUI - всё это уже определили ДО дизайнера. Да и цвета с оформлением, очень часто делаются не по "дизайнерскому" вкусу, а по формальному брифу, в котором описаны цветовая гамма и требования к оформлению, которые составлены другим специалистом, на базе анализа предпочтений и вкусов целевой аудитории.
1 Декабря 2014
1
Ну не совсем, тут вы упустили такую сущность как Team Lead, который то же участвует в цепочке работ над ТЗ. В общем случаи, работа над ТЗ, по данным методологиям выглядит так:

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

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

3. Бизнес аналитик, часто совместно с техническим писателем, создают документацию с формальными требованиями, описанием процессов и сущностей системы. Всё это передается системному ахитектору и дизайнеру GUI.

4. Системный архитектор, на основе полученной документации проектирует архитектуру будущего программного решения. (Прорабатываю структуру БД, создает диаграмму классов и т.д.)

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

После чего всё это передается Тим Лиду.

5. Тим Лид анализирует: описание от бизнес-аналитика, диаграммы и схемы от системного архитектора, макеты интерфейсоф от дизайнера. После дополняет их техническими требованиями и спецификациями (выбором технологий и инструментов, на которых всё это будет реализовываться).

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

6. Далее это ТЗ Тим Лидом единолично или совместно с Проект Менеджером разбивается на отдельные таски (задачи для программистов). Готовый таск - это и кусок описание от бизнес аналитика и относящиеся к нему диаграммы и схемы от системного архитектора и дизайн-макеты интерфейсов от дизайнеров.

***
И вот после всего этого и изобрели XP, методологии разработки ПО вообще без создания документации, основываясь только на протатипах и прочий agile :)
1 Декабря 2014
0
Фронт-енд разработчика полностью заменить не удастся никогда, всегда останется что-то, что можно сделать только "руками". Но можно постараться максимально автоматизировать его работу, это и есть наша основная задача. Сможем автоматизировать создание прототипов\наглядных концепций - уже хорошо, сможем чуть больше - ещё лучше.

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

НО данная статья - это перевод, а автор оригинала работает на европейских рынках, там это как раз и будет в тренде уже в следующем году. Насколько мне известно, сущность "верстальщик" есть только в СНГ, во всём остальном мире дизайнер занимается как разработкой, так и версткой. А фронт-енд разработчик заведует только JS-кодингом и прочим интерактивом. Т.е. наш инструмент скорее направлен на европейских дизайнеров-верстальщиков, нежели на отечественных фрон-енд разработчиков. И на тренды для этих "забугорных" дизайнеров, а не на отечественных верстальщиков.
1 Декабря 2014
Показать следующие