Comments 6
Чтобы не тратить время на пустую суету по причине пункта 2 - в каждом случае для нового члена команды ставится первичная задача: вычитка документации и проверка ее корректности на основе анализа предоставленного прототипа.
Для каждого тезиса должна появиться обратная связь после ознакомления и перечень вопросов.
При правильном подходе - далее следует этап совместного обсуждения результатов и корректировка / уточнение документации.
Я по своей легкомысленности думал, что проект - это не для того, чтобы сделать (раз уж каракулей на салфетке достаточно), а для того, чтобы найти виновных в случае провала: когда все расписано, можно понять (ну или попытаться понять), где пошло не так, а в случае салфетки либо все справятся, либо концов не найдешь (или виновником станет автор салфетки, который плохо корябал, вот ничего и не вышло)
Конечно, заранее просмотреть 100 экранов и прочитать 70 страниц к ним, дело неблагодарное. Но думаю, что когда разработчик приступает к конкретному экрану, то он просто обязан прочитать соответствующую страницу, чтобы узнать/проверить все детали.
Вот она квинтэссенция:
все методы хороши в своих контекстах
и статья понравилась.
Три горьких правды о моей профессии
А что-ж тут «горького»? Всё достаточно естественно, какая система, такие и процессы.
Я уже двадцать лет проектирую интерфейсы.
Здорово! Жаль только, что никто на Хабре не говорит о разработке и использовании GUI для десктопных программ. Такое впечатление, что эта отрасль уже вымерла.
Одни только китайцы всерьез занимались этой темой. И даже наваяли свою библиотеку DuiLib и профессиональную программу DuiEditor, для редактирования перегружаемого интерфейса пользователя, описываемого в xml-формате. Зато у нас тишина…
Три горьких правды о моей профессии