Как стать автором
Обновить

Комментарии 18

С удовольствием читаю ваш журнал. «Цифра» была бы хорошим дополнением к «аналогу».
Ну, думаю, указание ваших требований в статье для полноты картинки не помешало бы.
На старте мы бы хотели видеть примерно вот это:

Гм. Ничего не реализуемого или фантастически сложного не вижу. Да, работы тут много, но всё это выполнимо. Или вы что-то недоговариваете о требованиях.
Хотя бы с этого начать, а дальше уже прикручивать различные фенечки.
На самом деле процесс поиска разработчика на столько затянулся, что мы готовы начать хотя бы с этого минимума, а в дальнейшем уже строить глобальные планы по развитию данного приложения.
В любом случае, я просто высказываю своё мнение о том, что увидел, как iOS-разработчик. Я не предлагаю взяться за работу :)
Стандартная ситуация: «Хочу как у Васи!!» А потом: «А почему вот это так, а не так?»
По сути здесь 2 вида работ:
— специализированная CMS, для ведения контента, верстки (с учетом спецэффектов) и собственно формирования и раздачи цифровых выпусков
— ну и собственно уже «рендер» для каждой из платформ / или универсальное решение (например HTML5+JS)
Если у вас есть требования к обоим подсистемам высылайте, сможем подготовить свои предложения.
К сожалению как таковое ТЗ не сформулировано на бумаге, есть некое понимание того, что мы хотим в итоге получить. В любом случае нужно обсуждать наши хотелки со специалистами, понять на сколько они реализуемы, после этого разрабатывать ТЗ силами исполнителя и переходить к разработке.
ТЗ мы напишем, это не проблема. Желательно получить что-то на входе, а именно требования с описанием системы с точки зрения каждой из ролей: издателя, читателя. Это описание вашего бизнес-процесса и вы его знаете и представляете намного лучше разработчиков. Т.е. представьте себе идеальный цифровой журнал и опишите как вы его будете верстать, Из чего состоит выпуск, из чего состоит статья, какие есть дополнительные элементы, как это удобно вносить и редактировать. Потом как это будет видеть читатель. Если вы это сформулируете для себя, то и с разработчиками будет намного проще общаться. Если мы включимся на этом этапе, то проект это явно не удешевит… а по сути наши специалисты просто запишут то что вы скажете…
Согласен не удешевит, но наличие достаточно полного ТЗ, позволит сделать оценку стоимости работа максимально приближенной к реальности.

Я думаю, что мы сейчас выберем компанию которая сможет сделать хорошее ТЗ на разработку приложения в сжаты сроки и минимальный бюджет, а дальше уже будем обсуждать со всеми заинтересованными компаниями сроки и стоимость реализации.
Ситуация напомнила клиента веб-студии. Это ваш проект, никому другому он так не важен как вам, напишите хотя бы то что хотите видеть, так как лучше вас этого никто не сделает. В процессе написания к вам придет понимание логики взаимодействия с учетом разных ролей и так далее. А с такой документацией гораздо проще найти исполнителя, так как скорее всего отказываются кандидаты потому, что не видят ТЗ и внятных требований. Ситуация когда сказали одно, а потом захотели другое всем знакома и представлять фронт работ нужно с первой встречи.
А оценить фронт работы из того видеоролика, который я указал разве нельзя?

К сожалению у нас нет необходимой экспертизы по написанию такого ТЗ, поэтому ищем подрядчика совместно с которым мы его напишем.
Вот представьте приходит клиент и говорит «мне мощный сервак надо, чтобы все мои проекты летали и про балансировщик не забудьте». Это ему может о чем-то говорит, а вам — нет.
Может вам нужны будут дефолтные контролы, а не один WebView или вдруг вы потом придумаете умное кеширование на клиенте. А так вы опишите логику хотя бы очень поверхностно, изложите требования и покажете макеты основных состояний.
Пугаться будут без ТЗ, я вот например так и делаю. Вариант с постоянными вялотекущими доработками, созданными бурным воображением заказчика по мере его просвещения, мне знаком. Чаще сей вариант без доплат и какой-либо мотивации.
Надеюсь уговорил вас описать свои хотелки и сделать это хоть немного структурированно? :)
Нет не убедили. По моему личному опыту, конечный заказчик в лучшем случаем может сформулировать функциональные требования к ПО и то процентов на 30-40%, большую часть он не опишет так, как не обладает необходимыми компетенциями. ТЗ должны писать квалифицированные люди со стороны исполнителя при активном участии заказчика. Но к сожалению даже в этом случае далеко не всегда потраченные силы и время на разработку ТЗ приводят к нужному результату.

Когда-то для разработки одного портала было написано ТЗ на 100 листов плюс скрины внутренних и внешних интерфейсов и потрачено уйма времени. Получив ТЗ разработчики сказали, что в нем очень много чего не учтено и нужно все более детально описывать. Прошел год, объем ТЗ вырос более чем в два раза в итоге при разработке портала, все взаимодействие происходило с МП заказчика, который консультировал по каждой мелочи исполнителей и рассказывал как это должно работать. Вот такая история.
А почему не взять уже готовую платформу для журналов?
например
www.mazdigital.com/
Мы бы хотели быть ограничены функциональностью какой-то из существующих платформ.
а быть ограниченым каким-то подрядчиком? По моим оценкам, разработка под конкретного клиента, с его пожеланиями, на несколько платформ, может стоить более 100К$
Зарегистрируйтесь на Хабре , чтобы оставить комментарий