Но ведь можно зафиксировать требования хотя бы на первую итерацию/билд?
А потом уже править методом комплексного добавления/удаления опций :)
Всегда можно найти компромисс, если очень захотеть.
В моей практике. к сожалению, было мало продуктов, для которых требования бы не менялись вообще. Но все же такие случаи были и это великолепно сказалось на конечном продукте.
Если мы говорим об интерфейсах программных продуктов (не важно, веб., десктоп или клиент-сервер), то нужно думать не только о функционале и архитектуре, но и о сценариях использования.
Программист, разрабатывающий на основе API продукта, в определенном роде тоже пользователь и его потребности нужно учитывать.
При этом кнопочки и их местоположение не входят в это проектирование, они будут сделаны потом.
Недаром есть специально обученные люди, привлекаемые для проработки пользовательских сценариев еще на стадии проектирования.
А еще фокус-группы из потенциальных пользователей, благодаря которым можно учесть и исправить замечания и неудобности…
Проблема в том, что понимание необходимости этих действий есть далеко не у всех руководителей и далеко не на всех проектах.
Согласна, неоднозначно.
Но все же при проектировании архитектуры будущего продукта стоит уделить время основным элементам пользовательского интерфейса.
Чтобы не получился велосипед, который быстро едет, управляем, но элементы управления неудобны или неочевидны.
Согласитесь, переключать скорости руками под сиденьем неудобно :)
Если сразу заложить элементы управления=использования с учетом сценариев использования, то продукт будет удобен и неперегружен лишними настройками.
Очень печально использовать программные продукты и испытывать недовольство от кучи излишних параметров и необходимости делать 8 кликов для 1 простого и постоянно повторяемого действия.
Это я и понимаю под проектированием интерфейса одновременно с элементами системы.
А когда продукт разрастается без плана, почти всегда на выходе получаются перегруженные интерфейсы и недовольные пользователи.
А что касается API, то это тоже интерфейс. но для разработчика. И он тоже должен быть продуманным и удобным, а так же проектироваться на стадии общего проектирования. Добавлять в наспех придуманный API новые функции нехорошо.
Многое еще зависит от психотипа ключевых людей в команде. Кому-то комфортно в аврале, кому-то — при четком распараллеливании. Я не сталкивалась с исполнителями, которым нравится аврал. Руководители — да, любят нагнетать.
Для команды РП — представитель заказчика и действует в интересах заказчика, для заказчика — представитель компании (команды) и действует в интересах компании (команды).
Раплывчатое, мутное ТЗ — косяк РП.
Если ТЗ утверждено программистами и заказчиком, правки невозможны.
В формировке четкого ТЗ и заключается одна из основных задач РП.
В условиях бардака, даже когда топ-менеджмент активно и успешно его искореняет, невозможно на 100% полагаться на ресурсы и давать сроки по формулам.
Не так давно сменив работу, я ушла из перманентного застойного бардака в бардак позитивный, живой и очень этому рада. Я вижу конец этому бардаку. Да, работать мешает, но скоро кончится.
При этом я согласна быть готовой всегда готова к тому, что моего ключевого разработчика уведут на «очень надо, прямо сейчас», а я об этом узнаю поздно.
Как лекарство можно применить ходьбу ногами и многократные уточнения состоянием по ходу разработки/тестирования. Но далеко не все это любят, особенно тимлиды.
Вот именно для этого нужны предварительные оценки, «на глаз».
Без всякой пользы невозможно. Вы оценили, подумали, представили, создали черновик плана, еще что-нибудь. А заказчик ушел. Зато в следующий раз столкнувшись с подобным проектом Вы будете меньше и быстрее думать, по-другому будете говорить с заказчиком и он не уйдет.
А потом уже править методом комплексного добавления/удаления опций :)
Всегда можно найти компромисс, если очень захотеть.
В моей практике. к сожалению, было мало продуктов, для которых требования бы не менялись вообще. Но все же такие случаи были и это великолепно сказалось на конечном продукте.
Программист, разрабатывающий на основе API продукта, в определенном роде тоже пользователь и его потребности нужно учитывать.
При этом кнопочки и их местоположение не входят в это проектирование, они будут сделаны потом.
Недаром есть специально обученные люди, привлекаемые для проработки пользовательских сценариев еще на стадии проектирования.
А еще фокус-группы из потенциальных пользователей, благодаря которым можно учесть и исправить замечания и неудобности…
Проблема в том, что понимание необходимости этих действий есть далеко не у всех руководителей и далеко не на всех проектах.
Но все же при проектировании архитектуры будущего продукта стоит уделить время основным элементам пользовательского интерфейса.
Чтобы не получился велосипед, который быстро едет, управляем, но элементы управления неудобны или неочевидны.
Согласитесь, переключать скорости руками под сиденьем неудобно :)
Если сразу заложить элементы управления=использования с учетом сценариев использования, то продукт будет удобен и неперегружен лишними настройками.
Очень печально использовать программные продукты и испытывать недовольство от кучи излишних параметров и необходимости делать 8 кликов для 1 простого и постоянно повторяемого действия.
Это я и понимаю под проектированием интерфейса одновременно с элементами системы.
А когда продукт разрастается без плана, почти всегда на выходе получаются перегруженные интерфейсы и недовольные пользователи.
А что касается API, то это тоже интерфейс. но для разработчика. И он тоже должен быть продуманным и удобным, а так же проектироваться на стадии общего проектирования. Добавлять в наспех придуманный API новые функции нехорошо.
Существующий сейчас play.google.com/store/apps/details?id=net.meiolania.apps.habrahabr&feature=search_resultжутко неудобен.
Альтернативы так же не вдохновляют.
play.google.com/store/apps/details?id=ru.habrahabr.android&feature=search_result
Если ТЗ утверждено программистами и заказчиком, правки невозможны.
В формировке четкого ТЗ и заключается одна из основных задач РП.
Не так давно сменив работу, я ушла из перманентного застойного бардака в бардак позитивный, живой и очень этому рада. Я вижу конец этому бардаку. Да, работать мешает, но скоро кончится.
При этом я согласна быть готовой всегда готова к тому, что моего ключевого разработчика уведут на «очень надо, прямо сейчас», а я об этом узнаю поздно.
Как лекарство можно применить ходьбу ногами и многократные уточнения состоянием по ходу разработки/тестирования. Но далеко не все это любят, особенно тимлиды.
Без всякой пользы невозможно. Вы оценили, подумали, представили, создали черновик плана, еще что-нибудь. А заказчик ушел. Зато в следующий раз столкнувшись с подобным проектом Вы будете меньше и быстрее думать, по-другому будете говорить с заказчиком и он не уйдет.