Предпроектная документация: что это и почему она так важна?

    Среди моих знакомых нет ни одного, кто любил бы писать технические задания или что-то вроде этого. Чертить на салфетках планы захвата вселенной, собирать лэйауты из разноцветных стикеров, шлифовать концепцию в голове и на словах – это все любят и умеют делать, а вот сесть и как следует записать…
    Меня, например, любой шаблон серьезного документа погружает в глубочайшую тупку.

    У моих знакомых очень много хороших идей, но с таким подходом, слава богу, что дело редко доходит до производства. Почему? Плохо продуманные проекты редко бывают успешными. Либо команда по уши вязнет в тех работах, которые не были видны в начале, либо получается кривоватый, плохо приспособленный к жизни гоблин. Плохо масштабируемый к тому же.

    Необходимость формулировать, множество раз отвечать на вопрос “Что?” или “Для кого?” идут идее только на пользу. Эта работа позволяет избавиться от шелухи и проверить идею на прочность. Кроме того, предпроектная документация нужна для того, чтобы сэкономить время и деньги – чем тщательнее вы продумаете проект в начале, тем быстрее и качественнее он будет сделан.

    Существует огромное количество методик сбора и анализа данных, тьма методологий по разработке ПО, но нет пока ни одной, которую бы можно было без оглядки применять в веб-разработках. Да и черт бы с ней, с методологией! У хорошей предпроектной документации есть четыре составляющих – бизнес-концепция, анализ рынка и конкурентной среды, требования к продукту и макеты. Об этом и поговорим.

    Зачем вообще нужна предпроектная документация?


    Предпроектная документация нужна, в первую очередь, как точка опоры – нам нужно на что-то опираться при принятии решений. Здорово, когда эта опора объективна.

    Основная задача предпроектной документации – внести ясность. Ответить на вопрос «Что, для кого и каким образом мы делаем?» и получить данные, необходимые для ответа на вопрос «А стоит ли это вообще делать?».

    Удачная предпроектная документация служит отличной основой для написания функциональных требований, технического задания, пользовательской документации, стратегического плана, пресс-релизов; а также для согласования деталей проекта со смежными подразделениями и руководством.
    До начала расходования дорогостоящих програмистских человеко-часов, надо заметить!

    Кроме того, удачная предпроектная документация позволяет с очень высокой точностью предугадать масштаб бедствий – оценить затраты на разработку основного и дополнительного функционала, составить бюджет проекта.

    Каких проблем поможет избежать удачная предпроектная документация?


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


    Из чего состоит хорошая предпроектная документация?


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

    Рассмотрим более внимательно каждую составляющую.

    Бизнес-концепция

    Бизнес-концепция – самый важный документ. В этом документе рассматриваются следующие вопросы: суть и содержание бизнеса (что), аудитория/потребитель (для кого), бизнес-модель (где бабло) и конкурентные преимущества (почему именно наши слоны).

    Помимо этого, бизнес-концепция определяет предполагаемую нишу, стратегию завоевания рынка (выхода на рынок) и стратегию развития бизнеса.

    Удачная бизнес-концепция является прекрасной базой для написания пресс-релиза, руководства пользователя и для принятия самых разнообразных решений.

    Анализ рынка и конкурентной среды

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

    (Этот этап в некоторой степени идет параллельно с написанием бизнес-концепции; очевидно, что для написания раздела о конкурентных преимуществах необходимо изучить конкурентов)


    Требования к продукту (Функциональные требования)

    Функциональные требования – это документ, который дополняет и расширяет бизнес-концепцию. Он отвечает на вопрос «Каким образом?».

    Макеты

    Что такое макеты знают все, но не все знают, что это не просто картинки. Каждый графический макет – это результат анализа массы данных. Это точная наука.

    (Об этом я расскажу в среду в заметке “Дизайн – это не картинка, дизайн – это процесс”).

    У идеальной предпроектной документации есть и пятая составляющая – гайдлайн.

    Гайдлайн

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

    *
    Итак, удачная предпроектная документация позволяет внести ясность, служит точкой опоры для принятия решений, отвечает на вопросы “Что и для кого мы делаем?”, “Откуда берем деньги?”, “Кто эти люди, которые принесут нам бабло”, “Почему они понесут его именно нам?” и “Кто может помешать нашему обогащению?”.

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

    Кроме того:
    • это экономит ваше время и средства
    • вносит ясность
    • заставляет еще раз (много раз) обдумать идею
    • если у вас есть хорошая предпроектная документация, мир уже у ваших ног

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 52

      –1
      полезно, но про хабракат забывать не стоит)
        +3
        не справилась с управлением :)
          0
          Я лично считаю, что ТЗ важно для обоих сторон!

          Это как страховая грамота:
          для Заказчика будет уверенность, что сделают то, что он описал
          для Исполнителя будет уверенность, что проект не будет обрастать каждый день новыми рюшками…
            +1
            А вот смотря как оно написано!

            Как показывает практика заказчики плохо понимают о чем вы им толкуете на 60-ти листах и реагируют на ключевые слова вроде «Баннер 240x10 000» в левой колонке.

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

            А вообще, иногда уже в середине работы над предпроектной документацией выясняется, что идея-то… эээ… фигня…
              0
              Задача предпроектной документации (среди прочего) выяснить ключевые моменты бизнеса (чтобы не выяснилось после первой тестовой версии, что вообще было бы классно еще и каталог товаров), стратегических планов (чтобы каталог товаров, который нужно запустить через полгода, не стал сюрпризом для БДшника) ну и так далее.

                +1
                Хм, не понял почему оно отправилось, само по себе, после установки тегов

                Еще раз:

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

                А вообще, иногда уже в середине работы над предпроектной документацией выясняется, что идея-то… эээ… фигня…

                Если говорить, о собственных стартапах и идеях — то да, такое описание очень полезно.
                Если говорить о заказчике — то часто сайты разрабатываемые для них идеями вообще не блещут, даже если разработчик с низов пытается их внедрить — то очень часто клиент их замораживает.

                У меня неоднократно были случаи, когда ты идешь на встречу к заказчику полным идей и предложений, а заказчик все урезает до банальностей и с этим ничего не поделаешь.

                Но вообще то что вы описали очень полезно, для дружеских стартапов-сервисов, которые небольшими силами создаешь для души.

                Если честно говорить про какие-то бизнесс идеи например новостных проектов — даже не интересно, ну какие там бизнесс идеи? Либо все удачно — мы поставляем хороший контент, создаем хороший, удобный сайт и он работает и продает рекламу. Либо он превращается в еще один новостной сайт.

                А про сервесы — можно строить наполеоновские планы. Но на мой взгляд это лишнее, лучше реализовать для начала простые функции — посмотреть насколько это нужно/интересно людям, а потом уже зашивать-расширять. Конечно приблезительные области для расширения лучше изначально начертить, но бизнесс-модель, какая еще бизнесс-модель. Продажа рекламы или доступа к сервисам за смсочку, вот и бизнесс модель.

                  +1
                  Я с вами не соглашусь по всем пунктам.

                  Во-первых, про то, что клиент как правило замораживает классные идеи, которые выдвигают разработчики.
                  А давайте подумаем почему он это делает? Редиска? Дурак? Не понимает, что в этом классного?
                  Не понимает. Главное чего он не понимает – где тут бабло.
                  И не потому что редиска и дурак, а потому что вы ему не объяснили. Придумать идею – это 20% успеха, адаптировать под бизнес-нужды клиента 30% и продать идею клиенту 50%.

                  А то я ведь знаю как разработчики идею толкают "&*(*^^&#!!! AJAX!!! Везеде так!!! YouTube!!! Yahooo!!! Google!!! 500 человеко/часов!!!!". Ну кому она нужна такая?

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

                  В-третьих, про идеи для новостных проектов. Если вы воспринимаете новостной проект, как совокупность «хорошего контента, удобного интерфейса, который работает и продает рекламу», то на рекламе вы как раз ни хрена и не заработаете, потому что тут нет ответа на вопрос «Почему пользователь будет читать именно наши новости?».

                  В-пятых, про сервисы и наполеоновские планы. Хорошая идея, как правило, либо идеальна в своей простоте, либо представляется в виде космического корабля, который вы собираетесь строить поэтапно. Иногда рынок вносит свои корректировки и из простенькой, односоставной идеи рождается космический корабль. Но в этом случае, как правило, рядом строят что-то большое.
                    0
                    Главное чего он не понимает – где тут бабло.

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

                    Будем откровенны и скажем, что дизайнеры как творческие натуры, очень редко когда любят критику, тем более если они «в деле уже 25 лет и собаку съели» и договариваться тет-а-тет с дизайнером почти бессмыслено, только на общих встречах — как вы объясните заказчику, что гибкий дизайн для разных разделов — это бабло? Что у одного раздела могут быть одни блоки, а у другого другие? Материально это никак не выражается, выражается это в навигации пользователя по сайту и того что его не вырвет на 5-ой странице.

                    В-третьих, про идеи для новостных проектов.
                    А расскажите ка мне тогда почему люди на kp.ru ходят, и на tden.ru. Ну или ок на internetno.ru
                    Сервисы там какие-то необычные? Нет, просто материалы и все.

                    В-пятых, про сервисы и наполеоновские планы.
                    А в-четвертых куда дели?
                    По поводу планов — ну вот пожалуйста один из лучших стартапов прошлого года — moskva.fm

                    На чем там деньги зарабатываются?
                    На чем деньги vkontakte.ru зарабатывает?
                    Ну кто-там еще у нас? Хабрхарб?

                    Есть три вида заработка в сети:
                    1. Реклама
                    2. Подписка
                    3. Продажа сервисов за деньги

                    Какие — тут бизнесс идеи разрабатывать, я не понимаю.
                    Можно придумать да сервисы какие-то не обычные например Мегаплан.ру или бейзкамп.ру.
                    Отличные продукты зарабатывают на подписке и предоставлении сервисов.
                    Но все эти идеи они на виду. Думать во время создания проекта о том как ты миллионы заработаешь — идиотизм и пагубное действо, думать нужно о том как хороший продукт сделать, а потом и все остальное найдется.

                      0
                      эм, бейзкемп, конечно же не ру, и не бейзкем даже, а basecamphq.com
                      простите у меня под конец рабочего дня как раз голова уже плохо работает.
                        +1
                        в четвертых хабра зажевал (( что-то сбоит он сегодня

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

                        Разумеется, то что я предлагаю, не панацея и не защитит нас от дураков. Это просто еще один инструмент, который при умелом применении способен минимизировать риски.

                        — Почему одни ходят на kp.ru, а другие на internetno.ru? Потому что это разные социальные группы. С разными потребностями и установками, с разным всоприятием действительности и, если честно, с разной совершенно действительностью. Очень хорошо об этом написал как-то Дугаев – www.afisha.ru/article/inet_mir/

                          +1
                          Дугаева статью читал, но конкретно в нашем случае, дело-то в контенте, а не в сайте.
                          Просто на кп — отличный зомбоящик для хомячков. А на интернетно для джедаев, а продается в конечном счете реклама.

                          Разделять ЦА должны уже дяди заказчики, а не разработчики, если это конечно не агенство полного циклаTM

                          А ваша система очень хороша, я даже спорить не буду, но на мой взгляд только для личных стартапов и дружеских дел, а не для реализация проекта в рамках студии для конкретного заказчика. Там многие вещи из предварительной документации — именно клиент должен составить, а задача менеджера уже ограничить проект, чтобы он не разросся во время разработки.
                          Я вообщем об этом и хотел озвучить, может не вышло сразу, извините, у меня сегодня частичное помрачение рассудка
                            0
                            у меня тоже, но мысль вашу поняла :)
                          0
                          Мегаплан не такой уж и не обычный сервис. Просто ребята сначала продумали на чём будут зарабатывать. Поняли и сделаи сервис на котором можно зарабатывать. Они изначально делали серви для продажи услуг.
                          +2
                          >Главное чего он не понимает – где тут бабло.

                          Это ему не разработчики должны рассказывать, а его собственные маркетологи. Ну или «и.о.» маркетологов, кто там у него. В общем, когда он приходит к разработчикам — он уже знает, зачем ему это надо. А если не знает — нуегонах, у нас не детский сад, в самом-то деле. Разговор «я сам не знаю, что мне надо и нахрена мне это надо, вот вы мне что-нибудь сделайте, чтобы мне точно было хорошо» — это не разговор деловых людей. Мы — делаем. А не уговариваем.

                          Извините, возможно у меня совсем иная точка зрения, основанная на совсем других наблюдениях в совсем другой среде :)
                            0
                            Там выше речь шла об идеях, которые предлагают разрабочики. Ну то есть фичи там всякие, штуки, ajax.

                            Заказчики обычно хотят сайт. Они плохо понимают в сайтах, они где-то слышали, что это помогает. Ваша задача выяснить от чего они хотят лечиться с помощью сайта и предпложить оптимальное решение, с учетом ваших специальных знаний. Вот об этом я речь веду.
                              +1
                              Нет, вот я как раз с вами согласен.
                              Мое мнение — заказчик приходя к разработчикам — должен иметь четкое мнение чего он хочет от сайта. Какой инструмент ему должны создать, а как он его уже будет использовать — зависит от него и его команды. Хорошая команда — заработает денег, плохая команда — не заработает, и разработчиков в этом винить дело последние. Это тоже самое, что если строитель Вася забьет в пьяном угаре, молотком строителя Федю — идти обвинять сталелитейный завод, что они молоток-для-убийства создали :)

                  0
                  Хорошая статья. Все коротко и по делу.
                  • UFO just landed and posted this here
                      +3
                      чертовы мозговые слизни!

                      спасибо, исправлено :)
                      0
                      Для получивших нормальное образование либо чтящих Макконнелла, Спольски и иже с ними это очевидно.
                      Проблемы возникают у слегка разобравшихся в «пэхопэ» и решивших, что они получили просветление.
                        +6
                        будем считать, что этот текст для серых масс, которые не читали макконела, но которые почему-то (господи, да как они смеют?!) хотят делать сайты и не знают с какой стороны подступиться;

                        +2
                        Было бы очень полезно написать статью для тех кто уже согласен, что ПД это круто, но не знает как подступиться:
                        что-то типа шагов для начинающих
                          0
                          Или живые примеры, хотя бы, буде таковые разглашабельные найдутся ;)
                            0
                            читайте Спольски в его книге «Джоэл о программировании» глава про спецификации.
                            или тут local.joelonsoftware.com/mediawiki/index.php/Russian
                            Функциональные спецификации малой кровью
                          0
                          Всегда, в первую очередь, начинаю дотошно пропитывать все тонкости проекта, используемые технологии, необходимые функциональные элементы дизайна. Случалось, что в процессе отказывался от некоторых неудачных или ненужных идей и фич. очень помогает
                            0
                            В статье все описано достаточно ясно и доходчиво. Единственно, остается открытый вопрос (он же есть громандный повод для споров): о каких проектах идет речь?

                            В статье упоминается дизайн, а в комментариях php — интуитивно догадываюсь, что говорим о web-проектах.
                            И тут вопрос: речь идет о сайтах «представительство компании в сети»(проект есть вспомогательным для основного бизнеса) или «web-бизнес»(проект есть самодостаточный и сам приносит для себя доход)?

                              0
                              А какое это имеет значение? Описан же подход, его структурные элементы. Они применимы практически в любом случае, просто в разных задачах тот или иной пункт будет больше/меньше других. Например если это приложение без граф. интерфейса, то 2 последних пункта будут минимальны. Если это внутренняя разработка, не для продажи — то изменится бизнес-концепция, так как считать будем не прибыль, а полученную экономию.
                              В данном случае описана одна из самих сложных и комплексных задач.
                                0
                                Это имеет большое значение.

                                Кто, по Вашему мнению, отвечает за создание подобного документа?
                                  0
                                  А это зависит от того, кто у вас есть.

                                  Возможно, мнеджер проекта. Возможно, заказчик. Возможно, заказчик, менеджер-проекта и бизнес-аналитик – каждый за свою часть.

                                  А может, такой вариант тоже возможен, стартапер-одиночка, которому приснился Великий Сервис.

                                  Жизнь она такая… многовариантная штука.
                                    +1
                                    Допустим у меня есть ПМ и клиент.

                                    1) Составляет клиент: — клиент не будет (в большенстве случаев) рисовать макеты и т.д. Клиент ждет этого от дизайнера

                                    2) Составляет ПМ: — ПМ Ваш и вникать каждый раз в бизнес клиента, для описания бизнес-концепции — это слишком.

                                    3) Составляют оба вместе: тут либо клиент соглсится заплатить, за работу ПМ, либо ПМ сделает это бесплатно. Риск достаточно велик, т.к. после маркетинговых результатов и попыток прописать бизнес-концепцию окажется, что лучше этого не делать.

                                    Как правило, устав проекта создается на стороне клиента и этот документ символизирует начало работ. Остальные документы создаются приимущественно ПМ и его людьми.
                                      0
                                      оговорюсь: под требованиями к продукту я тут имею в виду крупноблочное описание страниц и функциональности.

                                      А я вот, например, не понимаю как можно писать требования к продукту, не вникая в суть бинеса. Ну как? Вы же задачу какую-то решаете, как же вы придумаете решение, если не вникните в суть бизнеса?

                                      Давайте предположим, что у нас небольшая веб-студия и заказанный корпоративный сайт. ЧТо мы делаем? Фигачим по шаблону – главная страница (Здравствуйте! Мы такие офигительные!), О нас (Ну мы прямо очень офигительные!), Продукция блаблабла
                                      И что? Какова ценность для потребителя? Ноль ценности.

                                      А теперь давайте немного напряжемся и вникнем в суть бизнеса клиента. Тут же выяснится множество интересных вещей. Окажется, что клиент что-то там продает. И цель у него при помощи сайта увеличить продажи. И что это значит для ПМ и для дизайнера? Что-то продает… увеличить продажи… Надо на главной странице прям продавать-продавать! Прямо каталог! Прямо заказ! А «О нас» в подвал!

                                      Понимаете, о чем я говорю?
                                      Не важно что вы делаете. Важно, что даже у унитаза есть конечный потребитель со своими потребностями. И продавец. Тоже с потребностями.

                                      Знать эти потребности и пользоваться этим знанием – вот ключ от тысячи дверей.

                                        0
                                        по-моему, мозговые слизни опять испортили мне тут орфографию… ну и ладно!
                                          0
                                          Полностью с Вами согласен.

                                          Тогда подобный документ должен составлять исключительно клиент (заказчик).

                                          И подобные документы заполняются. Только они называются по разному: бриф, анкета и т.д. Подобные документы могут включать в себя вопросы из всех выше описанных категорий. Все зависит от конкретной студии: на сколько детализированы данные опросники.
                                            0
                                            я бы не была столь категорична

                                            я за то, чтобы заполнял тот, кто в состоянии сделать это с пользой

                                            если заказчик попался отличный, здорово! пусть заполняет конечно!

                                            а если как всегда, то уж лучше проджект пишет сам и трясет заказчика по необходимости

                                            в общем (и это касается любой работы), пусть делает тот, кто умеет, а не тот, кому на визитке написано
                                          +3
                                          Вот поэтому документация разбивается на части. В качестве примера возьму фичу, которую я завершил неделю назад. Документация к ней содержала такие страшные слова, как FRS, FTS, HLD, DD, UTP, FTP.
                                          Что на практике означает следующее:

                                          FRS — Feature Requirement Specification. Это то, как фичу видит заказчик. «Экранчик вот такой, кнопочка тут, а когда нажимаешь — всё мигает!»
                                          FTS — Feature Technical Specification. Технические детали: протоколы, RFC, форматы и так далее (по каждому пункту из FRS).
                                          HLD — High Level Design. Взгляд «сверху» на то, как это дело будет реализовано. Архитектурно.
                                          DD — Detailed Design. Детали, детали, детали (хвала создателю, буквально перед тем, как мне довелось это дело писать, DD практически упразднили. Низвели до одного дополнительного раздела в HLD :)).
                                          UTP — Unit Tests Plan. Говорит само за себя. Юнит-тесты, a.k.a. тесты со стороны разработчика.
                                          FTP — Fit Tests Plan. Тесты со стороны юзера/QA-команды.

                                          Каждый пишет свою часть, согласовывают вместе, в результате чего вероятность того, что заказчик получит именно то, что он заказывал, намного выше ;)
                                            0
                                            А что это за методология?

                                            *
                                            По существу: с точки зрения технаря – перфектно, сточки зрения всех остальных – эээээ, чо?!

                                            Заказчик думает на одном языке (в идеале – на языке бизнеса) и ничего не рубит в том, куда и какие кнопочки ставить. И что вы себе имеете в виду по Feature Requirement Specification он тоже не понимает. Большинство заказчиков от слова «спецификация» тупеют на глазах.

                                            Проджект думает на другом языке и совсем не понимает, почему это заказчик считает, что пользователи должны идти к нему на сайт толпами.

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

                                            Предпроектная документация пишется на человечьем языке с тем, чтобы все стороны точно понимали о чем идет речь.
                                            А потом можно уже и на клинглонском писать, ага.

                                            Руководитель разработки думает с третьей стороны и слава богу если Проджект понимает чего он там думает.
                                              0
                                              абзац про руководителя разработки, конечно же, идет следом за абзацем про проджекта

                                                0
                                                Еще раз согласен.

                                                «Предпроектная» документация пишется на «человеческом» языке. А проектная на том, для кого она предназначена. Если это для тестировщиков, то и спец.термины им в руки.
                                                  0
                                                  >А что это за методология?

                                                  USDRP (Uniform Software Design and Release Program).

                                                  Сомневаюсь, что заказчик совсем уж «ничего не рубит в том, куда и какие кнопочки ставить». Ну или мы говорим о проектах разного плана. Если это веб, то заказчику скорее всего по барабану, где какие кнопочки, ему надо чтоб на сайт к нему ходили. Но если, к примеру, на сайте компании нужна возможность делать онлайн-заявки, то заказчик это знает. Также он знает, какая информация нужна для того, чтобы эту заявку потом можно было обработать. Вот это и пишется в FRS. Обычным, человеческим языком.
                                                    +1
                                                    оффтоп:
                                                    Заказчик ничего не рубит в том, куда и какие кнопочки ставить. При этом заказчик уверен в том, что он рубит. Больше того, он лучше дизайнера знает куда и какие кнопочки ставить. И какого цвета они должны быть. И вот тут еще красную черту проведите, пожалуйста.

                                                    Как-то так обычно в жизни бывает :(

                                                    *
                                                    за методологию спасибо, почитаю с интересом
                                                      0
                                                      Простите что влезаю — но сколько времени занимает разработка такого описания?
                                                      Вот конкретно вашего последнего проекта если взять и если возможно — то какой процент от суммы конечной разработки — стоило такое ТЗ?

                                                      Просто на мой взгляд — это лишняя и вредная тягомотина. Заказчик действительно часто не знает, чего он хочет. Гораздо лучше узнать его конечные цели и подумать за него как это реализовать, все таки тут вы профессионалы, а не он.

                                                      Потом конечно да, это идеально со стороны разработки — мол так расписал и все поехало, на рельсах, но насколько это реально?

                                                      Я думаю достаточно стандартная ситуация, не смотря на подробность расписанного ТЗ, все равно во время разработки появляются мелкие недочеты или добавления со стороны заказчика. Можно жестко его обрезать, но лучше внести несколько правок и потом закрыться. На моей практике было всего пару проектов без исправлений от заказчика, и то это скорее связано с тем, что он больше дизайном интересовался нежели функциональным ядром.
                                                        0
                                                        «Заказчик действительно часто не знает, чего он хочет»
                                                        На самом деле (в глубине души) он знает. Ему просто нужно задать правильные вопросы. Я за то, чтобы за написание этих документов головой отвечал проджект, как априори более ответственное лицо.

                                                        «лучше узнать его конечные цели и подумать за него как это реализовать»Так точно! В процессе подготовки предпроектной док-ции вы это и выясните.

                                                        Необходимость написания подобных документов основана на том предположении, что у любого продукта есть некоторый объективный жизненный цикл. И еще на том, что есть аудитория.

                                                        Мы должны знать как запускать продукт, как его развивать, ну все эти мелочи. И мы должны понимать для кого мы его делаем, ибо, согласитесь, сайт для аудитории «Хабра» будет сильно отличаться от сайта для аудитории «Одноклассников». Так же как и сайт компании, продающей слуховые аппараты, от сайта компании, продающей напиток «Ягуар».

                                                        Сколько времени занимает разработка такого описания?
                                                        От недели для среднего размера информационного ресурса. Хотя можно и за два дня слабать. Вопрос глубины проработки и масштаба охвата.
                                                          0
                                                          Вы простите, но я про время и суммы спрашивал именно конкретно о Mezomish'a.
                                                          Пре-проектная документация на мой взгляд не должна содержать в себе более 15-20 страниц текста и писаться она дожна не более недели, если говорить о том что вы в посте написали, там никаких сложных вещей нет. Фактически это можно назвать общим видом проекта с разных сторон.

                                                          Мол:
                                                          — вот с точки бизнеса у нас тут эцсамое
                                                          — а вот с точки разработки вот это
                                                          — и да расширять вот так вот будем.
                                                          — но пока у нас вот такая вот структура и никак не больше.

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

                                                          Либо должен заключаться договор на соответствующую сумму, где как минимум выкупается менеджер на 3-4 месяца вперед.

                                                          0
                                                          >Простите что влезаю — но сколько времени занимает разработка такого описания?

                                                          К моменту моего прихода в проект FRS уже было «спущено сверху». FTS и HLD большей частью были написаны. Разработка всего остального заняла месяца 2. Фича небольшая, непосредственно кодирование/отладка заняли ещё месяца 3.

                                                          >Просто на мой взгляд — это лишняя и вредная тягомотина. Заказчик действительно часто не знает, чего он хочет. Гораздо лучше узнать его конечные цели и подумать за него как это реализовать, все таки тут вы профессионалы, а не он.

                                                          Если конечные цели из разряда «сделайте чтоб продажи в 2 раза выросли» — это не по адресу. Это не к нам, это к маркетологам.
                                                          Если «сайт с информацией о компании (такой-то), управление содержимым через веб-форму, онлайн-формой заказа товара» — то это как раз то самое, что и пишется в FRS. Те самые «конечные цели», которые мы понимаем и принимаем, и которые берём за основу для остальных документов.
                                                          А «подумать за него как это реализовать» — естественно, это наше дело. Это и есть FTS, HLD и прочие вещи, которые пишутся нами (а кем же ещё?).

                                                          >Потом конечно да, это идеально со стороны разработки — мол так расписал и все поехало, на рельсах, но насколько это реально?

                                                          Да вполне реально. Если процесс поставлен.
                                                            0
                                                            Т.е. грубо говоря если я правильно понял разработка технического описания небольшой фичи заняла, столько же сколько и ее кодинг, а то и больше?

                                                            Это оправдывается тем, что команде разработчиков не приходится тратить лишнее время на дорбаотку/допиливание проекта по нуждам заказчика?

                                                            Наверное в некоторых случаях, это действительно крайне важно и помогает очень сильно сэкономить время, но если речь идет о небольшом проекте условно говоря корпоративного портала из 5 разделов + веб20 бонусы — мне кажется совсем не оправданная трата времени. Хотя конечно все зависит от суммы счета на разработку сайта и тех. задание, если оно вполне соответствует этим временным затратам — то это только интересно и приятно будет, делать свою работу качественно и без спешки.
                                                              0
                                                              Да, примерно так оно и вышло.

                                                              >Это оправдывается тем, что команде разработчиков не приходится тратить лишнее время на дорбаотку/допиливание проекта по нуждам заказчика?

                                                              В том числе.
                                                              При таком детальном подходе на каждом этапе каждому ясно, что мы делаем, как и зачем. И таки да, заказчик получает ровно то, что заказал. Правки, разумеется, принимаются, но до определённого момента и определённой степени сложности, не вносящие серьёзных изменений в проект.

                                                              >Наверное в некоторых случаях, это действительно крайне важно и помогает очень сильно сэкономить время, но если речь идет о небольшом проекте условно говоря корпоративного портала из 5 разделов + веб20 бонусы — мне кажется совсем не оправданная трата времени.

                                                              Всё зависит от проекта.

                                                              В моём случае сама фича была небольшая, но:
                                                              а) она является частью ОЧЕНЬ большого проекта (более 25 тысяч файлов со всеми потрохами);
                                                              б) она затрагивает такие вещи, как 911-звонки, поэтому всё прорабатывалось самым детальнейшим образом.

                                                              В случае корпоративного сайта, понятное дело, неделя-две на всё про всё — выше крыши.
                                        • UFO just landed and posted this here
                                            0
                                            u ar welkam :)
                                            0
                                            Информация несомненно полезная, но в стиле изложения мне не понравились многочисленные повторы / вдалбливания основных мыслей, можно сделать чище и лаконичней. Был бы признателен, если в будущем обратите на это внимание. Спасибо за статью.
                                              0
                                              учту, спасибо
                                              0
                                              Интересно было бы в подробностях разобрать этапы составления документации. Графические макеты, гайдлайн :)
                                              в целом приветсвую такого рода документ. Это как твой договор или твой «статут» ))
                                                0
                                                Про графические макеты напишу в скором времени, ага.
                                                «Процесс разработки графического макета с точки зрения менеджера проектов» как-то так это пока называется.

                                              Only users with full accounts can post comments. Log in, please.