Комментарии 52
полезно, но про хабракат забывать не стоит)
не справилась с управлением :)
Я лично считаю, что ТЗ важно для обоих сторон!
Это как страховая грамота:
для Заказчика будет уверенность, что сделают то, что он описал
для Исполнителя будет уверенность, что проект не будет обрастать каждый день новыми рюшками…
Это как страховая грамота:
для Заказчика будет уверенность, что сделают то, что он описал
для Исполнителя будет уверенность, что проект не будет обрастать каждый день новыми рюшками…
А вот смотря как оно написано!
Как показывает практика заказчики плохо понимают о чем вы им толкуете на 60-ти листах и реагируют на ключевые слова вроде «Баннер 240x10 000» в левой колонке.
Задача предпроектной документации (среди прочего) выяснить ключевые моменты бизнеса (чтобы не выяснилось после первой тестовой версии, что вообще было бы классно еще и каталог товаров), стратегических планов (чтобы каталог товаров, который нужно запустить через полгода, не стал сюрпризом для БДшника) ну и так далее.
А вообще, иногда уже в середине работы над предпроектной документацией выясняется, что идея-то… эээ… фигня…
Как показывает практика заказчики плохо понимают о чем вы им толкуете на 60-ти листах и реагируют на ключевые слова вроде «Баннер 240x10 000» в левой колонке.
Задача предпроектной документации (среди прочего) выяснить ключевые моменты бизнеса (чтобы не выяснилось после первой тестовой версии, что вообще было бы классно еще и каталог товаров), стратегических планов (чтобы каталог товаров, который нужно запустить через полгода, не стал сюрпризом для БДшника) ну и так далее.
А вообще, иногда уже в середине работы над предпроектной документацией выясняется, что идея-то… эээ… фигня…
Задача предпроектной документации (среди прочего) выяснить ключевые моменты бизнеса (чтобы не выяснилось после первой тестовой версии, что вообще было бы классно еще и каталог товаров), стратегических планов (чтобы каталог товаров, который нужно запустить через полгода, не стал сюрпризом для БДшника) ну и так далее.
Хм, не понял почему оно отправилось, само по себе, после установки тегов
Еще раз:
Задача предпроектной документации (среди прочего) выяснить ключевые моменты бизнеса (чтобы не выяснилось после первой тестовой версии, что вообще было бы классно еще и каталог товаров), стратегических планов (чтобы каталог товаров, который нужно запустить через полгода, не стал сюрпризом для БДшника) ну и так далее.
Как раз это описывается в ТЗ, которое и подписывает заказчик. Предпроектная документация, может меняться, конечное слово будет за ТЗ в любом случае.
А вообще, иногда уже в середине работы над предпроектной документацией выясняется, что идея-то… эээ… фигня…
Если говорить, о собственных стартапах и идеях — то да, такое описание очень полезно.
Если говорить о заказчике — то часто сайты разрабатываемые для них идеями вообще не блещут, даже если разработчик с низов пытается их внедрить — то очень часто клиент их замораживает.
У меня неоднократно были случаи, когда ты идешь на встречу к заказчику полным идей и предложений, а заказчик все урезает до банальностей и с этим ничего не поделаешь.
Но вообще то что вы описали очень полезно, для дружеских стартапов-сервисов, которые небольшими силами создаешь для души.
Если честно говорить про какие-то бизнесс идеи например новостных проектов — даже не интересно, ну какие там бизнесс идеи? Либо все удачно — мы поставляем хороший контент, создаем хороший, удобный сайт и он работает и продает рекламу. Либо он превращается в еще один новостной сайт.
А про сервесы — можно строить наполеоновские планы. Но на мой взгляд это лишнее, лучше реализовать для начала простые функции — посмотреть насколько это нужно/интересно людям, а потом уже зашивать-расширять. Конечно приблезительные области для расширения лучше изначально начертить, но бизнесс-модель, какая еще бизнесс-модель. Продажа рекламы или доступа к сервисам за смсочку, вот и бизнесс модель.
Еще раз:
Задача предпроектной документации (среди прочего) выяснить ключевые моменты бизнеса (чтобы не выяснилось после первой тестовой версии, что вообще было бы классно еще и каталог товаров), стратегических планов (чтобы каталог товаров, который нужно запустить через полгода, не стал сюрпризом для БДшника) ну и так далее.
Как раз это описывается в ТЗ, которое и подписывает заказчик. Предпроектная документация, может меняться, конечное слово будет за ТЗ в любом случае.
А вообще, иногда уже в середине работы над предпроектной документацией выясняется, что идея-то… эээ… фигня…
Если говорить, о собственных стартапах и идеях — то да, такое описание очень полезно.
Если говорить о заказчике — то часто сайты разрабатываемые для них идеями вообще не блещут, даже если разработчик с низов пытается их внедрить — то очень часто клиент их замораживает.
У меня неоднократно были случаи, когда ты идешь на встречу к заказчику полным идей и предложений, а заказчик все урезает до банальностей и с этим ничего не поделаешь.
Но вообще то что вы описали очень полезно, для дружеских стартапов-сервисов, которые небольшими силами создаешь для души.
Если честно говорить про какие-то бизнесс идеи например новостных проектов — даже не интересно, ну какие там бизнесс идеи? Либо все удачно — мы поставляем хороший контент, создаем хороший, удобный сайт и он работает и продает рекламу. Либо он превращается в еще один новостной сайт.
А про сервесы — можно строить наполеоновские планы. Но на мой взгляд это лишнее, лучше реализовать для начала простые функции — посмотреть насколько это нужно/интересно людям, а потом уже зашивать-расширять. Конечно приблезительные области для расширения лучше изначально начертить, но бизнесс-модель, какая еще бизнесс-модель. Продажа рекламы или доступа к сервисам за смсочку, вот и бизнесс модель.
Я с вами не соглашусь по всем пунктам.
Во-первых, про то, что клиент как правило замораживает классные идеи, которые выдвигают разработчики.
А давайте подумаем почему он это делает? Редиска? Дурак? Не понимает, что в этом классного?
Не понимает. Главное чего он не понимает – где тут бабло.
И не потому что редиска и дурак, а потому что вы ему не объяснили. Придумать идею – это 20% успеха, адаптировать под бизнес-нужды клиента 30% и продать идею клиенту 50%.
А то я ведь знаю как разработчики идею толкают "&*(*^^&#!!! AJAX!!! Везеде так!!! YouTube!!! Yahooo!!! Google!!! 500 человеко/часов!!!!". Ну кому она нужна такая?
Во-вторых, по поводу того, что с этим ничего не поделаешь, если вы не можете впарить заказчику идею, вероятнее всего идея не стоит того, чтобы быть впаренной. Траст ми.
Мы все тут очень любим мир будущего и высокотехнологичные технологии, но у каждой идеи есть целевая аудитория и вероятнее всего то, что вы предлагаете будет уместо смотреться в социальных сетях третьего поколения, а клиенту вообще не упало. Ну правда.
В-третьих, про идеи для новостных проектов. Если вы воспринимаете новостной проект, как совокупность «хорошего контента, удобного интерфейса, который работает и продает рекламу», то на рекламе вы как раз ни хрена и не заработаете, потому что тут нет ответа на вопрос «Почему пользователь будет читать именно наши новости?».
В-пятых, про сервисы и наполеоновские планы. Хорошая идея, как правило, либо идеальна в своей простоте, либо представляется в виде космического корабля, который вы собираетесь строить поэтапно. Иногда рынок вносит свои корректировки и из простенькой, односоставной идеи рождается космический корабль. Но в этом случае, как правило, рядом строят что-то большое.
Во-первых, про то, что клиент как правило замораживает классные идеи, которые выдвигают разработчики.
А давайте подумаем почему он это делает? Редиска? Дурак? Не понимает, что в этом классного?
Не понимает. Главное чего он не понимает – где тут бабло.
И не потому что редиска и дурак, а потому что вы ему не объяснили. Придумать идею – это 20% успеха, адаптировать под бизнес-нужды клиента 30% и продать идею клиенту 50%.
А то я ведь знаю как разработчики идею толкают "&*(*^^&#!!! AJAX!!! Везеде так!!! YouTube!!! Yahooo!!! Google!!! 500 человеко/часов!!!!". Ну кому она нужна такая?
Во-вторых, по поводу того, что с этим ничего не поделаешь, если вы не можете впарить заказчику идею, вероятнее всего идея не стоит того, чтобы быть впаренной. Траст ми.
Мы все тут очень любим мир будущего и высокотехнологичные технологии, но у каждой идеи есть целевая аудитория и вероятнее всего то, что вы предлагаете будет уместо смотреться в социальных сетях третьего поколения, а клиенту вообще не упало. Ну правда.
В-третьих, про идеи для новостных проектов. Если вы воспринимаете новостной проект, как совокупность «хорошего контента, удобного интерфейса, который работает и продает рекламу», то на рекламе вы как раз ни хрена и не заработаете, потому что тут нет ответа на вопрос «Почему пользователь будет читать именно наши новости?».
В-пятых, про сервисы и наполеоновские планы. Хорошая идея, как правило, либо идеальна в своей простоте, либо представляется в виде космического корабля, который вы собираетесь строить поэтапно. Иногда рынок вносит свои корректировки и из простенькой, односоставной идеи рождается космический корабль. Но в этом случае, как правило, рядом строят что-то большое.
Главное чего он не понимает – где тут бабло.
Ну вот представьте себе, заказчик доверяет только своему дизайнеру, который на самом-то деле полиграфист, а вам оплачивает только ведение проекта, верстку и программирование.
Будем откровенны и скажем, что дизайнеры как творческие натуры, очень редко когда любят критику, тем более если они «в деле уже 25 лет и собаку съели» и договариваться тет-а-тет с дизайнером почти бессмыслено, только на общих встречах — как вы объясните заказчику, что гибкий дизайн для разных разделов — это бабло? Что у одного раздела могут быть одни блоки, а у другого другие? Материально это никак не выражается, выражается это в навигации пользователя по сайту и того что его не вырвет на 5-ой странице.
В-третьих, про идеи для новостных проектов.
А расскажите ка мне тогда почему люди на kp.ru ходят, и на tden.ru. Ну или ок на internetno.ru
Сервисы там какие-то необычные? Нет, просто материалы и все.
В-пятых, про сервисы и наполеоновские планы.
А в-четвертых куда дели?
По поводу планов — ну вот пожалуйста один из лучших стартапов прошлого года — moskva.fm
На чем там деньги зарабатываются?
На чем деньги vkontakte.ru зарабатывает?
Ну кто-там еще у нас? Хабрхарб?
Есть три вида заработка в сети:
1. Реклама
2. Подписка
3. Продажа сервисов за деньги
Какие — тут бизнесс идеи разрабатывать, я не понимаю.
Можно придумать да сервисы какие-то не обычные например Мегаплан.ру или бейзкамп.ру.
Отличные продукты зарабатывают на подписке и предоставлении сервисов.
Но все эти идеи они на виду. Думать во время создания проекта о том как ты миллионы заработаешь — идиотизм и пагубное действо, думать нужно о том как хороший продукт сделать, а потом и все остальное найдется.
Ну вот представьте себе, заказчик доверяет только своему дизайнеру, который на самом-то деле полиграфист, а вам оплачивает только ведение проекта, верстку и программирование.
Будем откровенны и скажем, что дизайнеры как творческие натуры, очень редко когда любят критику, тем более если они «в деле уже 25 лет и собаку съели» и договариваться тет-а-тет с дизайнером почти бессмыслено, только на общих встречах — как вы объясните заказчику, что гибкий дизайн для разных разделов — это бабло? Что у одного раздела могут быть одни блоки, а у другого другие? Материально это никак не выражается, выражается это в навигации пользователя по сайту и того что его не вырвет на 5-ой странице.
В-третьих, про идеи для новостных проектов.
А расскажите ка мне тогда почему люди на kp.ru ходят, и на tden.ru. Ну или ок на internetno.ru
Сервисы там какие-то необычные? Нет, просто материалы и все.
В-пятых, про сервисы и наполеоновские планы.
А в-четвертых куда дели?
По поводу планов — ну вот пожалуйста один из лучших стартапов прошлого года — moskva.fm
На чем там деньги зарабатываются?
На чем деньги vkontakte.ru зарабатывает?
Ну кто-там еще у нас? Хабрхарб?
Есть три вида заработка в сети:
1. Реклама
2. Подписка
3. Продажа сервисов за деньги
Какие — тут бизнесс идеи разрабатывать, я не понимаю.
Можно придумать да сервисы какие-то не обычные например Мегаплан.ру или бейзкамп.ру.
Отличные продукты зарабатывают на подписке и предоставлении сервисов.
Но все эти идеи они на виду. Думать во время создания проекта о том как ты миллионы заработаешь — идиотизм и пагубное действо, думать нужно о том как хороший продукт сделать, а потом и все остальное найдется.
эм, бейзкемп, конечно же не ру, и не бейзкем даже, а basecamphq.com
простите у меня под конец рабочего дня как раз голова уже плохо работает.
простите у меня под конец рабочего дня как раз голова уже плохо работает.
в четвертых хабра зажевал (( что-то сбоит он сегодня
Про дизайнеров-полиграфистов и заказчиков-идиотов. К сожалению, их действительно непростительно много в реальной жизни. Пока нам, джедаям, не разрешили рубить их в капусту световыми мечами, приходится верить в то, что договориться можно со всеми.
Разумеется, то что я предлагаю, не панацея и не защитит нас от дураков. Это просто еще один инструмент, который при умелом применении способен минимизировать риски.
— Почему одни ходят на kp.ru, а другие на internetno.ru? Потому что это разные социальные группы. С разными потребностями и установками, с разным всоприятием действительности и, если честно, с разной совершенно действительностью. Очень хорошо об этом написал как-то Дугаев – www.afisha.ru/article/inet_mir/
Про дизайнеров-полиграфистов и заказчиков-идиотов. К сожалению, их действительно непростительно много в реальной жизни. Пока нам, джедаям, не разрешили рубить их в капусту световыми мечами, приходится верить в то, что договориться можно со всеми.
Разумеется, то что я предлагаю, не панацея и не защитит нас от дураков. Это просто еще один инструмент, который при умелом применении способен минимизировать риски.
— Почему одни ходят на kp.ru, а другие на internetno.ru? Потому что это разные социальные группы. С разными потребностями и установками, с разным всоприятием действительности и, если честно, с разной совершенно действительностью. Очень хорошо об этом написал как-то Дугаев – www.afisha.ru/article/inet_mir/
Дугаева статью читал, но конкретно в нашем случае, дело-то в контенте, а не в сайте.
Просто на кп — отличный зомбоящик для хомячков. А на интернетно для джедаев, а продается в конечном счете реклама.
Разделять ЦА должны уже дяди заказчики, а не разработчики, если это конечно не агенство полного циклаTM
А ваша система очень хороша, я даже спорить не буду, но на мой взгляд только для личных стартапов и дружеских дел, а не для реализация проекта в рамках студии для конкретного заказчика. Там многие вещи из предварительной документации — именно клиент должен составить, а задача менеджера уже ограничить проект, чтобы он не разросся во время разработки.
Я вообщем об этом и хотел озвучить, может не вышло сразу, извините, у меня сегодня частичное помрачение рассудка
Просто на кп — отличный зомбоящик для хомячков. А на интернетно для джедаев, а продается в конечном счете реклама.
Разделять ЦА должны уже дяди заказчики, а не разработчики, если это конечно не агенство полного циклаTM
А ваша система очень хороша, я даже спорить не буду, но на мой взгляд только для личных стартапов и дружеских дел, а не для реализация проекта в рамках студии для конкретного заказчика. Там многие вещи из предварительной документации — именно клиент должен составить, а задача менеджера уже ограничить проект, чтобы он не разросся во время разработки.
Я вообщем об этом и хотел озвучить, может не вышло сразу, извините, у меня сегодня частичное помрачение рассудка
Мегаплан не такой уж и не обычный сервис. Просто ребята сначала продумали на чём будут зарабатывать. Поняли и сделаи сервис на котором можно зарабатывать. Они изначально делали серви для продажи услуг.
>Главное чего он не понимает – где тут бабло.
Это ему не разработчики должны рассказывать, а его собственные маркетологи. Ну или «и.о.» маркетологов, кто там у него. В общем, когда он приходит к разработчикам — он уже знает, зачем ему это надо. А если не знает — нуегонах, у нас не детский сад, в самом-то деле. Разговор «я сам не знаю, что мне надо и нахрена мне это надо, вот вы мне что-нибудь сделайте, чтобы мне точно было хорошо» — это не разговор деловых людей. Мы — делаем. А не уговариваем.
Извините, возможно у меня совсем иная точка зрения, основанная на совсем других наблюдениях в совсем другой среде :)
Это ему не разработчики должны рассказывать, а его собственные маркетологи. Ну или «и.о.» маркетологов, кто там у него. В общем, когда он приходит к разработчикам — он уже знает, зачем ему это надо. А если не знает — нуегонах, у нас не детский сад, в самом-то деле. Разговор «я сам не знаю, что мне надо и нахрена мне это надо, вот вы мне что-нибудь сделайте, чтобы мне точно было хорошо» — это не разговор деловых людей. Мы — делаем. А не уговариваем.
Извините, возможно у меня совсем иная точка зрения, основанная на совсем других наблюдениях в совсем другой среде :)
Там выше речь шла об идеях, которые предлагают разрабочики. Ну то есть фичи там всякие, штуки, ajax.
Заказчики обычно хотят сайт. Они плохо понимают в сайтах, они где-то слышали, что это помогает. Ваша задача выяснить от чего они хотят лечиться с помощью сайта и предпложить оптимальное решение, с учетом ваших специальных знаний. Вот об этом я речь веду.
Заказчики обычно хотят сайт. Они плохо понимают в сайтах, они где-то слышали, что это помогает. Ваша задача выяснить от чего они хотят лечиться с помощью сайта и предпложить оптимальное решение, с учетом ваших специальных знаний. Вот об этом я речь веду.
Нет, вот я как раз с вами согласен.
Мое мнение — заказчик приходя к разработчикам — должен иметь четкое мнение чего он хочет от сайта. Какой инструмент ему должны создать, а как он его уже будет использовать — зависит от него и его команды. Хорошая команда — заработает денег, плохая команда — не заработает, и разработчиков в этом винить дело последние. Это тоже самое, что если строитель Вася забьет в пьяном угаре, молотком строителя Федю — идти обвинять сталелитейный завод, что они молоток-для-убийства создали :)
Мое мнение — заказчик приходя к разработчикам — должен иметь четкое мнение чего он хочет от сайта. Какой инструмент ему должны создать, а как он его уже будет использовать — зависит от него и его команды. Хорошая команда — заработает денег, плохая команда — не заработает, и разработчиков в этом винить дело последние. Это тоже самое, что если строитель Вася забьет в пьяном угаре, молотком строителя Федю — идти обвинять сталелитейный завод, что они молоток-для-убийства создали :)
Хорошая статья. Все коротко и по делу.
НЛО прилетело и опубликовало эту надпись здесь
Для получивших нормальное образование либо чтящих Макконнелла, Спольски и иже с ними это очевидно.
Проблемы возникают у слегка разобравшихся в «пэхопэ» и решивших, что они получили просветление.
Проблемы возникают у слегка разобравшихся в «пэхопэ» и решивших, что они получили просветление.
Было бы очень полезно написать статью для тех кто уже согласен, что ПД это круто, но не знает как подступиться:
что-то типа шагов для начинающих
что-то типа шагов для начинающих
Или живые примеры, хотя бы, буде таковые разглашабельные найдутся ;)
читайте Спольски в его книге «Джоэл о программировании» глава про спецификации.
или тут local.joelonsoftware.com/mediawiki/index.php/Russian
Функциональные спецификации малой кровью
или тут local.joelonsoftware.com/mediawiki/index.php/Russian
Функциональные спецификации малой кровью
Всегда, в первую очередь, начинаю дотошно пропитывать все тонкости проекта, используемые технологии, необходимые функциональные элементы дизайна. Случалось, что в процессе отказывался от некоторых неудачных или ненужных идей и фич. очень помогает
В статье все описано достаточно ясно и доходчиво. Единственно, остается открытый вопрос (он же есть громандный повод для споров): о каких проектах идет речь?
В статье упоминается дизайн, а в комментариях php — интуитивно догадываюсь, что говорим о web-проектах.
И тут вопрос: речь идет о сайтах «представительство компании в сети»(проект есть вспомогательным для основного бизнеса) или «web-бизнес»(проект есть самодостаточный и сам приносит для себя доход)?
В статье упоминается дизайн, а в комментариях php — интуитивно догадываюсь, что говорим о web-проектах.
И тут вопрос: речь идет о сайтах «представительство компании в сети»(проект есть вспомогательным для основного бизнеса) или «web-бизнес»(проект есть самодостаточный и сам приносит для себя доход)?
А какое это имеет значение? Описан же подход, его структурные элементы. Они применимы практически в любом случае, просто в разных задачах тот или иной пункт будет больше/меньше других. Например если это приложение без граф. интерфейса, то 2 последних пункта будут минимальны. Если это внутренняя разработка, не для продажи — то изменится бизнес-концепция, так как считать будем не прибыль, а полученную экономию.
В данном случае описана одна из самих сложных и комплексных задач.
В данном случае описана одна из самих сложных и комплексных задач.
Это имеет большое значение.
Кто, по Вашему мнению, отвечает за создание подобного документа?
Кто, по Вашему мнению, отвечает за создание подобного документа?
А это зависит от того, кто у вас есть.
Возможно, мнеджер проекта. Возможно, заказчик. Возможно, заказчик, менеджер-проекта и бизнес-аналитик – каждый за свою часть.
А может, такой вариант тоже возможен, стартапер-одиночка, которому приснился Великий Сервис.
Жизнь она такая… многовариантная штука.
Возможно, мнеджер проекта. Возможно, заказчик. Возможно, заказчик, менеджер-проекта и бизнес-аналитик – каждый за свою часть.
А может, такой вариант тоже возможен, стартапер-одиночка, которому приснился Великий Сервис.
Жизнь она такая… многовариантная штука.
Допустим у меня есть ПМ и клиент.
1) Составляет клиент: — клиент не будет (в большенстве случаев) рисовать макеты и т.д. Клиент ждет этого от дизайнера
2) Составляет ПМ: — ПМ Ваш и вникать каждый раз в бизнес клиента, для описания бизнес-концепции — это слишком.
3) Составляют оба вместе: тут либо клиент соглсится заплатить, за работу ПМ, либо ПМ сделает это бесплатно. Риск достаточно велик, т.к. после маркетинговых результатов и попыток прописать бизнес-концепцию окажется, что лучше этого не делать.
Как правило, устав проекта создается на стороне клиента и этот документ символизирует начало работ. Остальные документы создаются приимущественно ПМ и его людьми.
1) Составляет клиент: — клиент не будет (в большенстве случаев) рисовать макеты и т.д. Клиент ждет этого от дизайнера
2) Составляет ПМ: — ПМ Ваш и вникать каждый раз в бизнес клиента, для описания бизнес-концепции — это слишком.
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-команды.
Каждый пишет свою часть, согласовывают вместе, в результате чего вероятность того, что заказчик получит именно то, что он заказывал, намного выше ;)
Что на практике означает следующее:
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-команды.
Каждый пишет свою часть, согласовывают вместе, в результате чего вероятность того, что заказчик получит именно то, что он заказывал, намного выше ;)
А что это за методология?
*
По существу: с точки зрения технаря – перфектно, сточки зрения всех остальных – эээээ, чо?!
Заказчик думает на одном языке (в идеале – на языке бизнеса) и ничего не рубит в том, куда и какие кнопочки ставить. И что вы себе имеете в виду по Feature Requirement Specification он тоже не понимает. Большинство заказчиков от слова «спецификация» тупеют на глазах.
Проджект думает на другом языке и совсем не понимает, почему это заказчик считает, что пользователи должны идти к нему на сайт толпами.
Это происходит от того, что каждый специалист в своей области и пытается своим профессиональным языком убедить другую сторону. Но дело в том, что кроме того, что мы специалисты, мы еще и люди. У нас есть человчий язык.
Предпроектная документация пишется на человечьем языке с тем, чтобы все стороны точно понимали о чем идет речь.
А потом можно уже и на клинглонском писать, ага.
Руководитель разработки думает с третьей стороны и слава богу если Проджект понимает чего он там думает.
*
По существу: с точки зрения технаря – перфектно, сточки зрения всех остальных – эээээ, чо?!
Заказчик думает на одном языке (в идеале – на языке бизнеса) и ничего не рубит в том, куда и какие кнопочки ставить. И что вы себе имеете в виду по Feature Requirement Specification он тоже не понимает. Большинство заказчиков от слова «спецификация» тупеют на глазах.
Проджект думает на другом языке и совсем не понимает, почему это заказчик считает, что пользователи должны идти к нему на сайт толпами.
Это происходит от того, что каждый специалист в своей области и пытается своим профессиональным языком убедить другую сторону. Но дело в том, что кроме того, что мы специалисты, мы еще и люди. У нас есть человчий язык.
Предпроектная документация пишется на человечьем языке с тем, чтобы все стороны точно понимали о чем идет речь.
А потом можно уже и на клинглонском писать, ага.
Руководитель разработки думает с третьей стороны и слава богу если Проджект понимает чего он там думает.
абзац про руководителя разработки, конечно же, идет следом за абзацем про проджекта
Еще раз согласен.
«Предпроектная» документация пишется на «человеческом» языке. А проектная на том, для кого она предназначена. Если это для тестировщиков, то и спец.термины им в руки.
«Предпроектная» документация пишется на «человеческом» языке. А проектная на том, для кого она предназначена. Если это для тестировщиков, то и спец.термины им в руки.
>А что это за методология?
USDRP (Uniform Software Design and Release Program).
Сомневаюсь, что заказчик совсем уж «ничего не рубит в том, куда и какие кнопочки ставить». Ну или мы говорим о проектах разного плана. Если это веб, то заказчику скорее всего по барабану, где какие кнопочки, ему надо чтоб на сайт к нему ходили. Но если, к примеру, на сайте компании нужна возможность делать онлайн-заявки, то заказчик это знает. Также он знает, какая информация нужна для того, чтобы эту заявку потом можно было обработать. Вот это и пишется в FRS. Обычным, человеческим языком.
USDRP (Uniform Software Design and Release Program).
Сомневаюсь, что заказчик совсем уж «ничего не рубит в том, куда и какие кнопочки ставить». Ну или мы говорим о проектах разного плана. Если это веб, то заказчику скорее всего по барабану, где какие кнопочки, ему надо чтоб на сайт к нему ходили. Но если, к примеру, на сайте компании нужна возможность делать онлайн-заявки, то заказчик это знает. Также он знает, какая информация нужна для того, чтобы эту заявку потом можно было обработать. Вот это и пишется в FRS. Обычным, человеческим языком.
оффтоп:
Заказчик ничего не рубит в том, куда и какие кнопочки ставить. При этом заказчик уверен в том, что он рубит. Больше того, он лучше дизайнера знает куда и какие кнопочки ставить. И какого цвета они должны быть. И вот тут еще красную черту проведите, пожалуйста.
Как-то так обычно в жизни бывает :(
*
за методологию спасибо, почитаю с интересом
Заказчик ничего не рубит в том, куда и какие кнопочки ставить. При этом заказчик уверен в том, что он рубит. Больше того, он лучше дизайнера знает куда и какие кнопочки ставить. И какого цвета они должны быть. И вот тут еще красную черту проведите, пожалуйста.
Как-то так обычно в жизни бывает :(
*
за методологию спасибо, почитаю с интересом
Простите что влезаю — но сколько времени занимает разработка такого описания?
Вот конкретно вашего последнего проекта если взять и если возможно — то какой процент от суммы конечной разработки — стоило такое ТЗ?
Просто на мой взгляд — это лишняя и вредная тягомотина. Заказчик действительно часто не знает, чего он хочет. Гораздо лучше узнать его конечные цели и подумать за него как это реализовать, все таки тут вы профессионалы, а не он.
Потом конечно да, это идеально со стороны разработки — мол так расписал и все поехало, на рельсах, но насколько это реально?
Я думаю достаточно стандартная ситуация, не смотря на подробность расписанного ТЗ, все равно во время разработки появляются мелкие недочеты или добавления со стороны заказчика. Можно жестко его обрезать, но лучше внести несколько правок и потом закрыться. На моей практике было всего пару проектов без исправлений от заказчика, и то это скорее связано с тем, что он больше дизайном интересовался нежели функциональным ядром.
Вот конкретно вашего последнего проекта если взять и если возможно — то какой процент от суммы конечной разработки — стоило такое ТЗ?
Просто на мой взгляд — это лишняя и вредная тягомотина. Заказчик действительно часто не знает, чего он хочет. Гораздо лучше узнать его конечные цели и подумать за него как это реализовать, все таки тут вы профессионалы, а не он.
Потом конечно да, это идеально со стороны разработки — мол так расписал и все поехало, на рельсах, но насколько это реально?
Я думаю достаточно стандартная ситуация, не смотря на подробность расписанного ТЗ, все равно во время разработки появляются мелкие недочеты или добавления со стороны заказчика. Можно жестко его обрезать, но лучше внести несколько правок и потом закрыться. На моей практике было всего пару проектов без исправлений от заказчика, и то это скорее связано с тем, что он больше дизайном интересовался нежели функциональным ядром.
«Заказчик действительно часто не знает, чего он хочет»
На самом деле (в глубине души) он знает. Ему просто нужно задать правильные вопросы. Я за то, чтобы за написание этих документов головой отвечал проджект, как априори более ответственное лицо.
«лучше узнать его конечные цели и подумать за него как это реализовать»Так точно! В процессе подготовки предпроектной док-ции вы это и выясните.
Необходимость написания подобных документов основана на том предположении, что у любого продукта есть некоторый объективный жизненный цикл. И еще на том, что есть аудитория.
Мы должны знать как запускать продукт, как его развивать, ну все эти мелочи. И мы должны понимать для кого мы его делаем, ибо, согласитесь, сайт для аудитории «Хабра» будет сильно отличаться от сайта для аудитории «Одноклассников». Так же как и сайт компании, продающей слуховые аппараты, от сайта компании, продающей напиток «Ягуар».
Сколько времени занимает разработка такого описания?
От недели для среднего размера информационного ресурса. Хотя можно и за два дня слабать. Вопрос глубины проработки и масштаба охвата.
На самом деле (в глубине души) он знает. Ему просто нужно задать правильные вопросы. Я за то, чтобы за написание этих документов головой отвечал проджект, как априори более ответственное лицо.
«лучше узнать его конечные цели и подумать за него как это реализовать»Так точно! В процессе подготовки предпроектной док-ции вы это и выясните.
Необходимость написания подобных документов основана на том предположении, что у любого продукта есть некоторый объективный жизненный цикл. И еще на том, что есть аудитория.
Мы должны знать как запускать продукт, как его развивать, ну все эти мелочи. И мы должны понимать для кого мы его делаем, ибо, согласитесь, сайт для аудитории «Хабра» будет сильно отличаться от сайта для аудитории «Одноклассников». Так же как и сайт компании, продающей слуховые аппараты, от сайта компании, продающей напиток «Ягуар».
Сколько времени занимает разработка такого описания?
От недели для среднего размера информационного ресурса. Хотя можно и за два дня слабать. Вопрос глубины проработки и масштаба охвата.
Вы простите, но я про время и суммы спрашивал именно конкретно о Mezomish'a.
Пре-проектная документация на мой взгляд не должна содержать в себе более 15-20 страниц текста и писаться она дожна не более недели, если говорить о том что вы в посте написали, там никаких сложных вещей нет. Фактически это можно назвать общим видом проекта с разных сторон.
Мол:
— вот с точки бизнеса у нас тут эцсамое
— а вот с точки разработки вот это
— и да расширять вот так вот будем.
— но пока у нас вот такая вот структура и никак не больше.
но еще раз говорю — может быть мы разным заказчикам сайты делаем, но будет приносить деньги сайт или не будет — это уже не ваша проблема. Т.е. понятное дело нужно делать качественно, но бизнес-концепция портала — меня соврешенно не волнует, так же как и трафикогенерация — об этом должны менеджеры думать нанятые со стороны заказчика.
Либо должен заключаться договор на соответствующую сумму, где как минимум выкупается менеджер на 3-4 месяца вперед.
Пре-проектная документация на мой взгляд не должна содержать в себе более 15-20 страниц текста и писаться она дожна не более недели, если говорить о том что вы в посте написали, там никаких сложных вещей нет. Фактически это можно назвать общим видом проекта с разных сторон.
Мол:
— вот с точки бизнеса у нас тут эцсамое
— а вот с точки разработки вот это
— и да расширять вот так вот будем.
— но пока у нас вот такая вот структура и никак не больше.
но еще раз говорю — может быть мы разным заказчикам сайты делаем, но будет приносить деньги сайт или не будет — это уже не ваша проблема. Т.е. понятное дело нужно делать качественно, но бизнес-концепция портала — меня соврешенно не волнует, так же как и трафикогенерация — об этом должны менеджеры думать нанятые со стороны заказчика.
Либо должен заключаться договор на соответствующую сумму, где как минимум выкупается менеджер на 3-4 месяца вперед.
>Простите что влезаю — но сколько времени занимает разработка такого описания?
К моменту моего прихода в проект FRS уже было «спущено сверху». FTS и HLD большей частью были написаны. Разработка всего остального заняла месяца 2. Фича небольшая, непосредственно кодирование/отладка заняли ещё месяца 3.
>Просто на мой взгляд — это лишняя и вредная тягомотина. Заказчик действительно часто не знает, чего он хочет. Гораздо лучше узнать его конечные цели и подумать за него как это реализовать, все таки тут вы профессионалы, а не он.
Если конечные цели из разряда «сделайте чтоб продажи в 2 раза выросли» — это не по адресу. Это не к нам, это к маркетологам.
Если «сайт с информацией о компании (такой-то), управление содержимым через веб-форму, онлайн-формой заказа товара» — то это как раз то самое, что и пишется в FRS. Те самые «конечные цели», которые мы понимаем и принимаем, и которые берём за основу для остальных документов.
А «подумать за него как это реализовать» — естественно, это наше дело. Это и есть FTS, HLD и прочие вещи, которые пишутся нами (а кем же ещё?).
>Потом конечно да, это идеально со стороны разработки — мол так расписал и все поехало, на рельсах, но насколько это реально?
Да вполне реально. Если процесс поставлен.
К моменту моего прихода в проект FRS уже было «спущено сверху». FTS и HLD большей частью были написаны. Разработка всего остального заняла месяца 2. Фича небольшая, непосредственно кодирование/отладка заняли ещё месяца 3.
>Просто на мой взгляд — это лишняя и вредная тягомотина. Заказчик действительно часто не знает, чего он хочет. Гораздо лучше узнать его конечные цели и подумать за него как это реализовать, все таки тут вы профессионалы, а не он.
Если конечные цели из разряда «сделайте чтоб продажи в 2 раза выросли» — это не по адресу. Это не к нам, это к маркетологам.
Если «сайт с информацией о компании (такой-то), управление содержимым через веб-форму, онлайн-формой заказа товара» — то это как раз то самое, что и пишется в FRS. Те самые «конечные цели», которые мы понимаем и принимаем, и которые берём за основу для остальных документов.
А «подумать за него как это реализовать» — естественно, это наше дело. Это и есть FTS, HLD и прочие вещи, которые пишутся нами (а кем же ещё?).
>Потом конечно да, это идеально со стороны разработки — мол так расписал и все поехало, на рельсах, но насколько это реально?
Да вполне реально. Если процесс поставлен.
Т.е. грубо говоря если я правильно понял разработка технического описания небольшой фичи заняла, столько же сколько и ее кодинг, а то и больше?
Это оправдывается тем, что команде разработчиков не приходится тратить лишнее время на дорбаотку/допиливание проекта по нуждам заказчика?
Наверное в некоторых случаях, это действительно крайне важно и помогает очень сильно сэкономить время, но если речь идет о небольшом проекте условно говоря корпоративного портала из 5 разделов + веб20 бонусы — мне кажется совсем не оправданная трата времени. Хотя конечно все зависит от суммы счета на разработку сайта и тех. задание, если оно вполне соответствует этим временным затратам — то это только интересно и приятно будет, делать свою работу качественно и без спешки.
Это оправдывается тем, что команде разработчиков не приходится тратить лишнее время на дорбаотку/допиливание проекта по нуждам заказчика?
Наверное в некоторых случаях, это действительно крайне важно и помогает очень сильно сэкономить время, но если речь идет о небольшом проекте условно говоря корпоративного портала из 5 разделов + веб20 бонусы — мне кажется совсем не оправданная трата времени. Хотя конечно все зависит от суммы счета на разработку сайта и тех. задание, если оно вполне соответствует этим временным затратам — то это только интересно и приятно будет, делать свою работу качественно и без спешки.
Да, примерно так оно и вышло.
>Это оправдывается тем, что команде разработчиков не приходится тратить лишнее время на дорбаотку/допиливание проекта по нуждам заказчика?
В том числе.
При таком детальном подходе на каждом этапе каждому ясно, что мы делаем, как и зачем. И таки да, заказчик получает ровно то, что заказал. Правки, разумеется, принимаются, но до определённого момента и определённой степени сложности, не вносящие серьёзных изменений в проект.
>Наверное в некоторых случаях, это действительно крайне важно и помогает очень сильно сэкономить время, но если речь идет о небольшом проекте условно говоря корпоративного портала из 5 разделов + веб20 бонусы — мне кажется совсем не оправданная трата времени.
Всё зависит от проекта.
В моём случае сама фича была небольшая, но:
а) она является частью ОЧЕНЬ большого проекта (более 25 тысяч файлов со всеми потрохами);
б) она затрагивает такие вещи, как 911-звонки, поэтому всё прорабатывалось самым детальнейшим образом.
В случае корпоративного сайта, понятное дело, неделя-две на всё про всё — выше крыши.
>Это оправдывается тем, что команде разработчиков не приходится тратить лишнее время на дорбаотку/допиливание проекта по нуждам заказчика?
В том числе.
При таком детальном подходе на каждом этапе каждому ясно, что мы делаем, как и зачем. И таки да, заказчик получает ровно то, что заказал. Правки, разумеется, принимаются, но до определённого момента и определённой степени сложности, не вносящие серьёзных изменений в проект.
>Наверное в некоторых случаях, это действительно крайне важно и помогает очень сильно сэкономить время, но если речь идет о небольшом проекте условно говоря корпоративного портала из 5 разделов + веб20 бонусы — мне кажется совсем не оправданная трата времени.
Всё зависит от проекта.
В моём случае сама фича была небольшая, но:
а) она является частью ОЧЕНЬ большого проекта (более 25 тысяч файлов со всеми потрохами);
б) она затрагивает такие вещи, как 911-звонки, поэтому всё прорабатывалось самым детальнейшим образом.
В случае корпоративного сайта, понятное дело, неделя-две на всё про всё — выше крыши.
НЛО прилетело и опубликовало эту надпись здесь
Информация несомненно полезная, но в стиле изложения мне не понравились многочисленные повторы / вдалбливания основных мыслей, можно сделать чище и лаконичней. Был бы признателен, если в будущем обратите на это внимание. Спасибо за статью.
Интересно было бы в подробностях разобрать этапы составления документации. Графические макеты, гайдлайн :)
в целом приветсвую такого рода документ. Это как твой договор или твой «статут» ))
в целом приветсвую такого рода документ. Это как твой договор или твой «статут» ))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Предпроектная документация: что это и почему она так важна?