Комментарии 10
Не совсем понятно, зачем написали. Типа -привет, я Кэп. Я не против статьи, она правильная и написано нормально, только описываются совершенно очевидные вещи
Сорри за критицизм
Да не, нормальный коммент. Технически всё, о чём я пишу, — очевидно для меня. Поэтому, если бы меня это останавливало, то никаких обучающих материалов я бы не создавал.
Но в данном случае я личным опытом поделился, а не какими-то правилами. Возможно, в комментарии придут те, чей опыт отличается от моего, и мы все станем чуточку умнее.
Зачем написал? Чтобы те, кто расстраиваются от того, что их прототипы уходят «в стол», поменьше расстраивались :)
Эта статья интересна для таких как я - людей, которые совершенно не знают и не задумывались о том как заказывают проекты, что в итоге может быть. Просто интересно как это бывает в жизни :)
Agile, не?
ресурсов — выше крыши, а руки просто не доходят
Что тогда здесь понимается под "ресурсами"? Обычно ресурсы - это время, средства, люди (и иногда можно разбить средства на деньги и материалы, но не здесь). Ваша компания знакома с основами проектной деятельности (про треугольник как модель ресурсов)?
Но меня больше другое интересует.
Если требуется выполнить проект, то необходима его оценка. Оценка от и до. В которой участвуют все основные затратные ресурсы (с вашей стороны - дизайн).
Вопрос - зачем выполнять прототип вместо того, чтобы его оценить? Если следовать логике вашей работы, то делаем дизайн - оцениваем, делаем фронт - оцениваем...
А всего-то от вас требуется:
(прошу прощения, не ту кнопочку нажал, а отредактировать не могу)
Получить/сформулировать ФТ от заказчика
Оценить свою работу (без создания прототипа)
Выдать требования тем, кто должен реализовывать ваш дизайн.
И так по все пищевой цепочке.
Повторюсь, если каждый участник проекта будет изготавливать свой драфт (у вас - прототип), то оценка будет золотой.
На самом деле, насколько помню, вся эта процедура описана в разных проектных моделях, в т.ч. в ГОСТ
Я тот человек, к которому приходит клиент за формулированием функциональных требований к стартапам (и не только). Сформулированные функциональные требования — это не спроектированный проект. Проектирование — это процесс, результат которого сильно расплывчат (иначе это бы не называлось проектированием). Фишка в том, что даже если бы я был тем супермозгом, который по короткому описанию может смоделировать в голове сразу готовую систему (а ко мне иногда обращаются и за ERP-системами на несколько сотен экранов), то дальше мне всё равно пришлось бы проделать ооочень трудоёмкую работу, у которой две цели:
— Ознакомить клиента с моей моделью и согласовать её;
— Описать эту модель достаточно подробно, чтобы разработчики могли сделать оценку.
И вот только после того, как появится проектная документация, из которой всем становится ясно, что клиент собирается разрабатывать, можно сделать оценку разработки.
Почему каждый второй из наших прототипов для новых проектов уходит в стол, а не в продакшен?