Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 141
Вот спасибо! Честное слово, безумно хорошо и доходчиво для определенного круга лиц написано. Надеюсь, что те, кому я ссылку дал впитают информацию и больше не будут допускать ошибок, совершаемых ранее.
Буду очень рад если эта статья хоть чуть-чуть изменит ситуацию с заданиями на сайт :)
Вот бы ещё посмотреть составленное ТЗ на разработку сайта от автора.
Да, я сделаю статью с практичекой частью.
Не прошло и три месяца и вот продолжение с примером ТЗ
Why so comic sans?
Pencil Project uses Comic sans by default
Уже не первая программа, где он по-умолчанию. Это — заговор.
Шрифт Comic Sans был сделан для текста в комиксах. Данные скетчи стилизованы под карандашные наброски и этот шрифт прекрасно к ним подходит. Глупо было бы использовать тут шрифт стилизованный под матричный принтер.
Спасибо за наводку. Что-то что не смотрел подобное — всё платное и под винду.… Жаль нельзя два плюса в карму ставить :(
Мне кажется, это специально, чтобы показать нубство этих картинок
Для иллюстрации «То как видит проект заказчик» это и есть самый правильный шрифт!
Картинки к статье были самостоятельно нарисованы или есть какой-то сервис?
Если что, есть ещё Mockup Builder
если разработчик представляет интернет-магазин (назовем это так) как показано на первой картинке, то он херовый разработчик. Не предусмотреть «скидку», «количество для заказа», «бэйджик „новинка“, „нет на складе — оставить заявку“, „скидка в корзине“ — это банальная некомпетентность и на водит на мысли, что разработчик не только ни разу не делал подобное, но и не удосужился посмотреть интернеты на эту тему.
Заказчик в этом случае прав.
Заказчик в этом случае прав.
Вы знаете чем отличаются иллюстрации для пояснения принципа от реальных вещей?
Для футболок еще обязательно размер, например, с наличием каждого размера, а для автозапчатей цвет, а для школьных тетрадей — в клеточку они или линейку, а для детской одежды еще примерный рост-возраст ребенка, а для кошачих кормов породы кошек, а для резиновых членов длину, форму и флажок ХИТ СЕЗОНА.
Суть в том, что программист все равно никогда не сможет учесть и предусмотреть все необходимые нюансы заранее и сам, если ему о них не рассказать.
Суть в том, что программист все равно никогда не сможет учесть и предусмотреть все необходимые нюансы заранее и сам, если ему о них не рассказать.
«тёртый» программист\дизайнер не будет делать первую картинку основываясь на опыте, он сразу выбьет у заказчика описание и сделает вторую.
Это должен делать менеджер
смотря какую ситуацию рассматривать. фриланс или большую студию.
А менеджер, который знает тонкости баз данных, разбирается в дизайне, верстке и еще куче вещей — золотой человек. таких не бывает.
чаще всего менеджер — ведет проект, звонит заказчику, прикрывает жопу дизайнера\программиста, согласует сроки.
А менеджер, который знает тонкости баз данных, разбирается в дизайне, верстке и еще куче вещей — золотой человек. таких не бывает.
чаще всего менеджер — ведет проект, звонит заказчику, прикрывает жопу дизайнера\программиста, согласует сроки.
смотрите, есть разделение: аккаунт-менеджер и проджект-менеджер. Вот первый общается с заказчиком, а второй ведет проект. Проджект ОБЯЗАН знать основы БД, разбираться в юзабилити и верстке. Имхо. И да, эти два человека должны быть разными.
ну, приближаемся к идеалу. еще есть сэйл-менеджер и еще куча людей. Для крупных студий -да. Но насколько я понял статься не для монстров сайтостроения, которые уже во всем в курсе. Но я не к тому.
Проджект ОБЯЗАН знать основы БД, разбираться в юзабилити и верстке.
основы! я тоже знаю основы бд, но этого недостаточно, чтобы не сделать ошибок как в примере топика. про остальные области тоже самое можно сказать.
Проджект ОБЯЗАН знать основы БД, разбираться в юзабилити и верстке.
основы! я тоже знаю основы бд, но этого недостаточно, чтобы не сделать ошибок как в примере топика. про остальные области тоже самое можно сказать.
Это должен делать аналитик со стороны заказчика, если заказывают разработку сайта. Или аналитик со стороны исполнителя, если заказывают решение бизнес-задачи. А оно может состоять и в открытии оффлайнового магазина.
Это должен делать проектировщик интерфейса.
Вы не правы, как и заказчик.
Этого «немного» хватает лишь для общения и составления документов.
а большего и не надо.
Менеджер в программисте нужен для того, чтобы цену отстоять и на телефон ответить, а программист в программисте — как раз для того, чтобы первой картинки не было.
а большего и не надо.
Менеджер в программисте нужен для того, чтобы цену отстоять и на телефон ответить, а программист в программисте — как раз для того, чтобы первой картинки не было.
да, только делает ее не один недоменеджер, а в паре, например, с техдиром, который понимает намного больше чем недоменеджер и при случае скажет нет, той или иной фиче.
«доработки не по тз бесплатно» — это в идеальном мире. Незначительные вещи в большинстве случаев делаются, если это конечно не зажравшаяся студия.
«доработки не по тз бесплатно» — это в идеальном мире. Незначительные вещи в большинстве случаев делаются, если это конечно не зажравшаяся студия.
А чем Вам так не нравится первая картинка? Вполне себе рабочий, простой магазин. Полно случаев когда нужно именно это. Достаточно идиотическая ситуация, если программист будет единолично додумывать что нужно заказчику, попутно увеличив срок реализации в несколько раз. В итоге всё кончится тем, что заказчик, увидев реализацию по второй картинке, скажет «я этого не заказывал» и будет на 100% прав.
С другой стороны не менее дурацкая ситуация имеет место когда оценку сроков и бюджета делают до утверждения макетов интерфейса.
С другой стороны не менее дурацкая ситуация имеет место когда оценку сроков и бюджета делают до утверждения макетов интерфейса.
Так в данном случае он не додумывает. Он делает так, как правильно, он же профессионал и знает, что и как будет лучше. Ну, по причине, например, собственной гордости или как это назвать. Если просят сделать кнопку, то ясно, что на кнопке будет текст, и она должна, по хорошем, иметь 3 визуально отличающихся состояния. Заказчик об этом и не думает, а грамотный исполнитель — да.
Ну, а сделать «наотъебись» в начале проекта никто не пытается.
Ну, а сделать «наотъебись» в начале проекта никто не пытается.
Почему программист (технический специалист) должен знать как решать задачу увеличения продаж? Конструктор автомобиля должен придумать его рекламную компанию, а конструктор танка боевую задачу для него?
> Он делает так, как правильно, он же профессионал и знает, что и как будет лучше.
Как должен выглядеть интерфейс пользователя это не программисту решать, эта задача вне его компетенции.
> Ну, по причине, например, собственной гордости или как это назвать.
Я бы назвал эту причину раздутым самомнением.
Как должен выглядеть интерфейс пользователя это не программисту решать, эта задача вне его компетенции.
> Ну, по причине, например, собственной гордости или как это назвать.
Я бы назвал эту причину раздутым самомнением.
обсуждаем не интерфейс, а функционал.
Функционал — это не самоцель.
Профессиональные программисты очень принципиальны и одним из их базовых принципов является YAGNI
Когда программист реализует неоговоренный функционал по собственной прихоти — это признак дилетантства, а не профессиональной гордости. Программист может решать как делать оговоренный функционал, но не должен решать что (какой набор фич) делать.
Профессиональные программисты очень принципиальны и одним из их базовых принципов является YAGNI
Когда программист реализует неоговоренный функционал по собственной прихоти — это признак дилетантства, а не профессиональной гордости. Программист может решать как делать оговоренный функционал, но не должен решать что (какой набор фич) делать.
И бюджет сто баксов.
Это удовлетворение требованиям ТЗ, сформированному на базе бизнес-требований. Заказчик сформулировал бизнес-требования, аналитики выразили их в требованиях к проекту, разработчик составил ТЗ на их основе, заказчик его утвердил. Всё что вы назвали — это термины предметной области, их должна вводить сторона заказчика. Если, конечно, вы берётесь за разработку сайта, а не решение проблемы низких продаж у заказчика.
Отличная статья!
[мечтательно]
Вот бы еще перевод на английский, уж я бы нашел ему применение :)
[мечтательно]
Вот бы еще перевод на английский, уж я бы нашел ему применение :)
Спасибо.
Очень полезный текст, вдохновили на написание шаблона ТЗ и дальнейшей его эксплуатации )
Очень полезный текст, вдохновили на написание шаблона ТЗ и дальнейшей его эксплуатации )
Соглашусь с каждым словом. Работать без ТЗ — себе дороже.
Отличная статья, спасибо :)
Отличная статья, спасибо :)
Извечная проблема. Потихоньку приходим к её решению. Ключ к этому — магическое слово Agile.
Ну и причем тут Agile? Вас не зря ведь минусуют
Отход от досконального ТЗ в сторону подхода сделали итерацию-заплатили/договорились заплатить. А то, что описывается в статье — водопадная схема работы.
Отход от константы в понятии «объём необходимого функционала» в сторону констант времени и/или стоимости.
Блин, ну и к чему это?
Я четко говорю, что статья про водрпадную модель. Вы статью хоть читали? Или сразу комментируем?
Я четко говорю, что статья про водрпадную модель. Вы статью хоть читали? Или сразу комментируем?
Сделали итерацию — заплатили, пришла вторая итерация, которая требует для своей реализации доработки/переделки первой, пришла третья итерация, ради которой доработки/переделки первых двух?
Простите, я не знаком с Agile, просто мысли такие возникли на основе ваших слов. Если нет продуманного и досконального ТЗ, то каждый раз будут доработки/переделки сверху вниз, дико усложняя разработку с каждой итерацией.
Простите, я не знаком с Agile, просто мысли такие возникли на основе ваших слов. Если нет продуманного и досконального ТЗ, то каждый раз будут доработки/переделки сверху вниз, дико усложняя разработку с каждой итерацией.
Продуманного досконального ТЗ на крупных проектах в принципе не может быть…
В статье речь идёт о проектах из серии «написали и забыли», а когда проект разрабатывается годами, крутясь на production и реагируя на просьбы пользователей и всяческие исследования, то вам неизбежно придётся постоянно дорабатывать и переделывать 80% от его функционала. И чем раньше вы начнёте этим заниматься и чем более короткими итерациями, тем проще вам будет вести разработку с каждой итерацией и тем изящнее будет архитектура проекта.
В статье речь идёт о проектах из серии «написали и забыли», а когда проект разрабатывается годами, крутясь на production и реагируя на просьбы пользователей и всяческие исследования, то вам неизбежно придётся постоянно дорабатывать и переделывать 80% от его функционала. И чем раньше вы начнёте этим заниматься и чем более короткими итерациями, тем проще вам будет вести разработку с каждой итерацией и тем изящнее будет архитектура проекта.
Мечтаю попасть к тимлиду, который будет способен заранее не допустить серьезных ошибок для жизни такого проекта. К сожалению, таких очень немного…
НО, зная несколько таких людей, могу точно утверждать, что вопрос ТЗ для них критичен и у них существует 2 версии ТЗ:
1. Предварительное, которое, как ожидалось, размытое.
2. Детализированное, на каждую итерацию.
Прелесть первого в том, что можно оценить, где оставить брешь для масштабирования
Прелесть второго — этап будет закончен в сроки, не важно стоит ли переделывать то, что было сделано ранее.
И волокита с ТЗ ведется постоянно, на каждую итерацию. Заказчик высказывает пожелания, а они описывают это и спрашивают: «Вы так хотите?», если нет — уточняют. Пока не провалились, да я и сомневаюсь в их провале. Заказчик готов платить за то, что они думают. Он не нуждается в писанине ради отмазки, ему нужна реальная работа и он прекрасно понимает, что изменить что-то можно по-разному. Особенно это важно и критичено при ревью кода, к примеру.
НО, зная несколько таких людей, могу точно утверждать, что вопрос ТЗ для них критичен и у них существует 2 версии ТЗ:
1. Предварительное, которое, как ожидалось, размытое.
2. Детализированное, на каждую итерацию.
Прелесть первого в том, что можно оценить, где оставить брешь для масштабирования
Прелесть второго — этап будет закончен в сроки, не важно стоит ли переделывать то, что было сделано ранее.
И волокита с ТЗ ведется постоянно, на каждую итерацию. Заказчик высказывает пожелания, а они описывают это и спрашивают: «Вы так хотите?», если нет — уточняют. Пока не провалились, да я и сомневаюсь в их провале. Заказчик готов платить за то, что они думают. Он не нуждается в писанине ради отмазки, ему нужна реальная работа и он прекрасно понимает, что изменить что-то можно по-разному. Особенно это важно и критичено при ревью кода, к примеру.
То, что Вы написали, никак не противоречит моему высказыванию…
За исключением терминологии.
В Agile не пишут ТЗ, а пишут функциональную спецификацию на основе сценариев использования на каждую итерацию.
А то, что Вы называете «предварительное ТЗ» — это в случае плохого ТЗ — набор блоков сайта, а в случае Agile набор т.н. пользовательских историй.
Все прелести сохраняются, но уходит вся «вода», которой практически во всех ТЗ, что я видел, было больше половины. Т.е. описывается не что нужно сделать, а как это должно работать в рамках ментальной модели пользователя.
За исключением терминологии.
В Agile не пишут ТЗ, а пишут функциональную спецификацию на основе сценариев использования на каждую итерацию.
А то, что Вы называете «предварительное ТЗ» — это в случае плохого ТЗ — набор блоков сайта, а в случае Agile набор т.н. пользовательских историй.
Все прелести сохраняются, но уходит вся «вода», которой практически во всех ТЗ, что я видел, было больше половины. Т.е. описывается не что нужно сделать, а как это должно работать в рамках ментальной модели пользователя.
на редкость замечательная статья среди вороха подобных :)
Какое бы подробное ТЗ не было, всегда найдется возможность сделать работу странным способом, формально заданию соответствующим, но приводящему к неудовольствию заказчика. И наоборот тоже.
Надо закрывать почаще актами!
Дизайн-концепция — акт.
Сверстанные макеты — акт.
Прототип — акт.
Все работает на рыбном тексте — акт.
Наполнение — акт.
Когда подписан очередной акт и нашелся конфликт со столь прекрасным техническим заданием — разница в понимании за счет заказчика.
Надо закрывать почаще актами!
Дизайн-концепция — акт.
Сверстанные макеты — акт.
Прототип — акт.
Все работает на рыбном тексте — акт.
Наполнение — акт.
Когда подписан очередной акт и нашелся конфликт со столь прекрасным техническим заданием — разница в понимании за счет заказчика.
всегда найдется возможность сделать работу странным способом
Наверное можно так сделать, но зачем?
Потому что так кажется лучшим, чем очевидное: «Всё, что не оговорено, выполняется на усмотрение исполнителя» ;) «Лучшесть», кстати, может вовсе не заключаться в оптимизации (по любому критерию) «профита» заказчика. Иногда так можно получить опыт реального применения новой технологии/фреймворка/платформы. Или завалить проект :(
Заказчик может остаться недоволен, если всё к актам сводить, да и сам разработчик где-то может был бы не против подправить.
С дизайном можно поступать, например, следующим образом. Первый макет после ТЗ — бесплатно. Внесение корректировок «при первом подходе к снаряду» (то есть заказчик пишет один единственный список того, что исправить) — бесплатно, если это не вылезет за определенные временные лимиты. Далее все исправления уже идут с дополнительной почасовой оплатой.
Тут главное пресечь две вещи: 1) желание заказчика порулить (еще бы, подчиненных, что дух захватывает), 2) многоитерационные творческие флуктации (по-простому говоря, бесконечные правки — пока безымянному пальцу правой ноги дизайн не понравится, в производство не пустят).
С дизайном можно поступать, например, следующим образом. Первый макет после ТЗ — бесплатно. Внесение корректировок «при первом подходе к снаряду» (то есть заказчик пишет один единственный список того, что исправить) — бесплатно, если это не вылезет за определенные временные лимиты. Далее все исправления уже идут с дополнительной почасовой оплатой.
Тут главное пресечь две вещи: 1) желание заказчика порулить (еще бы, подчиненных, что дух захватывает), 2) многоитерационные творческие флуктации (по-простому говоря, бесконечные правки — пока безымянному пальцу правой ноги дизайн не понравится, в производство не пустят).
Что вы в этом свете скажете о Scrum?
Ничего не скажу. Имхо гибкие методологии они несколько для других задач. Для «обычных» сайтов не уверен в необходимости выбора Scrum.
Верно, зачем применять методологию если она будет в ущерб разработке. А для маленьких проектов скрам действительно будет излишним.
Интересно, что именно вы относите к понятию маленький проект? И как переформулируете высказывание, если этих проектов 5, 10, 20 параллельно…
Я думаю что все могут понять что такое маленький проект и без цифр и оценочных характеристик.
Параллельность в случае с 10-20 проектами одновременно — это что-то странное. На моей памяти было много небольших компаний, которые разрабатывали сайты-визитки. Такие проекты можно считать маленькими. Но я не представляю как можно одновременно схватиться и вести разработку, допустим, 10 проектов. Это, на мой взгляд программиста, ошибка менеджера.
Если уйти от декомпозиции и считать пул из 10-20 проектов одним множеством, то можно разработать совершенно новую методологию, наверное.
Если я неправильно понял вопрос или мой ответ для Вас кажется странным, пожалуйста, сформулируйте задачу конкретнее.
Параллельность в случае с 10-20 проектами одновременно — это что-то странное. На моей памяти было много небольших компаний, которые разрабатывали сайты-визитки. Такие проекты можно считать маленькими. Но я не представляю как можно одновременно схватиться и вести разработку, допустим, 10 проектов. Это, на мой взгляд программиста, ошибка менеджера.
Если уйти от декомпозиции и считать пул из 10-20 проектов одним множеством, то можно разработать совершенно новую методологию, наверное.
Если я неправильно понял вопрос или мой ответ для Вас кажется странным, пожалуйста, сформулируйте задачу конкретнее.
Нет, в целом, в большинстве своем я с Вами согласен, однако я не согласен с подходом «проект маленький -> к черту методологию» (в данном случае я горю про скрам, но на его месте может стоять любая другая)
То, что это немного «не корректно», вести много проектов одновременно — да. Все равно программист, как бы не старался, он по большей части будет выполнять их линейно и тут уже у менеджера возникают жуткие головные боли по поводу того, что проектов много, контроль терять нельзя. У вышеупомянутой методологии есть много прекрасных моментов, которые много упростили бы жизнь. Не хочу впадать в дебаты, они тут бессмысленны, но ответьте себе на простой вопрос: 'вы часто на 100% следуете предписаниям методологии, не совершая каких либо отклонений, не подмешивая в процесс «лучшие практики» из других процессов?'. Никто не сказал, что нужно принципиально выдерживать все предписания в полном виде. Очевидно, что некоторые этапы возьмутся наскоком и вполне успешно, однако и в «маленьких» проектах бывают подводные камни, как это и не смешно звучит.
По поводу 10 сайтов визиток параллельно — не вопрос. Костяк все равно будет один и тот же (±) и время, затраченное, к примеру, дизайнером и верстальщиком заведомо больше, чем затратит программист. И вот тут как раз и возникает не состыковка сроков, однако, это уже совсем другая тема, не из области ТЗ.
То, что это немного «не корректно», вести много проектов одновременно — да. Все равно программист, как бы не старался, он по большей части будет выполнять их линейно и тут уже у менеджера возникают жуткие головные боли по поводу того, что проектов много, контроль терять нельзя. У вышеупомянутой методологии есть много прекрасных моментов, которые много упростили бы жизнь. Не хочу впадать в дебаты, они тут бессмысленны, но ответьте себе на простой вопрос: 'вы часто на 100% следуете предписаниям методологии, не совершая каких либо отклонений, не подмешивая в процесс «лучшие практики» из других процессов?'. Никто не сказал, что нужно принципиально выдерживать все предписания в полном виде. Очевидно, что некоторые этапы возьмутся наскоком и вполне успешно, однако и в «маленьких» проектах бывают подводные камни, как это и не смешно звучит.
По поводу 10 сайтов визиток параллельно — не вопрос. Костяк все равно будет один и тот же (±) и время, затраченное, к примеру, дизайнером и верстальщиком заведомо больше, чем затратит программист. И вот тут как раз и возникает не состыковка сроков, однако, это уже совсем другая тема, не из области ТЗ.
На этот раз мой ответ прост как никогда — живое общение внутри команда разработчиков во благо любому проекту. Это основной принцип Agile, если ничего не путаю.
Предыдущий оратор неточно выразился, «отметая методологию». Водопад — это тоже методология, развитая и даже стандартизированная на уровне государства.
Я возможно недосказал. Если я не ошибаюсь, то где-то было красиво сказано waterfall methodology is a description of the natural, and the most dangerous approach to the management of projects, but do not sew the fly's trunk (мог допустить ошибку, ибо по памяти). Другие методологии могут быть эволюционированием или комбинированием. Взглянем на тот же MSF.
Это я к тому, что не может проект выжить без применения какой либо методологии и вполне естественно, если по дефолту будет водопад:
. Пришел заказчик, высказал пожелания
… Команда села, подумала
…… Уточнили все детали
……… Сели делать и сделали
………… Сдали.
Согласен, при малом опыте у команды — будут итерации, вполне оправданные, но, не хочу накручивать, вполне естественно, что по дефолту упоминается водопадная модель.
К тому же, про отрицание всех методологий я не говорил. Я сразу уточнил, что речь идет именно о какой-то конкретной методологии, а не о всех сразу. Это так, если уж цепляться к словам.
Это я к тому, что не может проект выжить без применения какой либо методологии и вполне естественно, если по дефолту будет водопад:
. Пришел заказчик, высказал пожелания
… Команда села, подумала
…… Уточнили все детали
……… Сели делать и сделали
………… Сдали.
Согласен, при малом опыте у команды — будут итерации, вполне оправданные, но, не хочу накручивать, вполне естественно, что по дефолту упоминается водопадная модель.
К тому же, про отрицание всех методологий я не говорил. Я сразу уточнил, что речь идет именно о какой-то конкретной методологии, а не о всех сразу. Это так, если уж цепляться к словам.
Спасибо, отлично написано — легко и весело читать.
Отдельное спасибо за юмор!
У себя используем практическую такую же схему ТЗ, что была описана.
Жалко только, что дошли до нее на своем опыте — набивая шишки.
Отдельное спасибо за юмор!
У себя используем практическую такую же схему ТЗ, что была описана.
Жалко только, что дошли до нее на своем опыте — набивая шишки.
Спасибо за отзыв. Видимо в самом деле удобная схема, раз мы пришли к похожим схемам. А в чем у вас отличия?
Обязательно указываем какие браузеры будет поддерживать сайт.
А такие пункты как:
у нас указан в договоре на разработку, т.к. заказчик может пойти с нашим ТЗ к другим разработчикам, а этот пункт касается только наших с ним договоренностей.
Последнее, кстати, было довольно важным шагом — выделить ТЗ в отдельный этап отношения с заказчиком. Т.е. сначала заказчик оплачивает ТЗ, получает его, и потом уже решает, будет ли он разрабатывать проект с нами.
А такие пункты как:
- 3.9 — наполнение контентом и
- 3.10 сдача и приемка
у нас указан в договоре на разработку, т.к. заказчик может пойти с нашим ТЗ к другим разработчикам, а этот пункт касается только наших с ним договоренностей.
Последнее, кстати, было довольно важным шагом — выделить ТЗ в отдельный этап отношения с заказчиком. Т.е. сначала заказчик оплачивает ТЗ, получает его, и потом уже решает, будет ли он разрабатывать проект с нами.
Про браузеры у меня в сдачу и приемку: «должно работать в таких-то браузерах». В статье не упомянул, вылетело из головы.
Как вы верно говорите про вынесение ТЗ в отдельный этап! Имхо это очень правильно и нужно.
Как вы верно говорите про вынесение ТЗ в отдельный этап! Имхо это очень правильно и нужно.
Зависит от ориентированности ТЗ. ТЗ пишется для двух сторон: заказчика и исполнителя. ТЗ более ориентированное на заказчика, большой ценности не имеет. Это часто приложение к договору. Ну и про детальность в статье уже упоминалось. Глубоко проработанное ТЗ — это этап в ражработке и должно оплачиваться.
> Как вы верно говорите про вынесение ТЗ в отдельный этап! Имхо это очень правильно и нужно.
Да, вот только далеко не все заказчики маленьких проектов готовы платить за ТЗ. Более того, они сильно удивляются когда узнают о том, что на составление ТЗ потребуется некоторое время.
Да, вот только далеко не все заказчики маленьких проектов готовы платить за ТЗ. Более того, они сильно удивляются когда узнают о том, что на составление ТЗ потребуется некоторое время.
Понравился график высчитывания оптимальной стоимости проекта. Очень просто и в то же время очень эффективно резюмируют необходимость в составлении ТЗ.
Отлично.
По поводу багов, лучше тоже оговаривать сроки. И требования к поддержке прописывать. Иначе вылезает клиент через полтора года после сдачи, а его не помнит уже никто.
Плюс, срок «опытной эксплуатации» подстегивает клиента начать эксплуатацию быстрее. А чем быстрее он ошибки найдёт, тем проще их править.
Но это нюансы.
По поводу багов, лучше тоже оговаривать сроки. И требования к поддержке прописывать. Иначе вылезает клиент через полтора года после сдачи, а его не помнит уже никто.
Плюс, срок «опытной эксплуатации» подстегивает клиента начать эксплуатацию быстрее. А чем быстрее он ошибки найдёт, тем проще их править.
Но это нюансы.
Вы не поверите, сколько времени я потратил на прочтение и переваривание статьи. Вы говорите о заказчике-исполнителе на уровне отделов компании и ТЗ выступает внутренним циркуляром? Хотел было пожаловаться вам на то, что у вас самое ценное в процессе производства ТЗ — само ТЗ. Вы как продавец пылесосов Кирби или менеджер RationalRose. Такое ощущение от статьи, что вы участник передачи, где нужно показать слово, не произнося его в слух. Потому я зашел на сайт, указанный в вашем профиле и все встало на свои места.
Что ж, вот вам и живой пример, когда diff — оптимален, а сайт — не будет работать. Я попозже зайду внутрь, но если бы не мое природное задр… тство и уже убитое на переваривание статьи время — не стал бы смотреть даже видео на главной. Переделать! А все потому что diff вы не там мерили, оценивая ценность ТЗ.
Хотя график и вышил почти идеально. С маркетинговой точки зрения.
Что ж, вот вам и живой пример, когда diff — оптимален, а сайт — не будет работать. Я попозже зайду внутрь, но если бы не мое природное задр… тство и уже убитое на переваривание статьи время — не стал бы смотреть даже видео на главной. Переделать! А все потому что diff вы не там мерили, оценивая ценность ТЗ.
Хотя график и вышил почти идеально. С маркетинговой точки зрения.
А мне понравилось. А я проработал системным аналитиком с десяток лет.
Но за упорство респект, я обычно как понимаю, что статья — потерянное время тут же её прекращаю читать. Или дочитываю «по диагонали». На что мне секунд 20 не особо жаль.
Но за упорство респект, я обычно как понимаю, что статья — потерянное время тут же её прекращаю читать. Или дочитываю «по диагонали». На что мне секунд 20 не особо жаль.
Да, спасибо, за поддержку. В статье выражен мой опыт, к которому я пришел с потом и кровью и убитыми нервными клеткам и сорванными сроками.
Из графика следует, что стоимость проекта, сделанного по идеальному «дорогому» ТЗ сводит на нет все «хотелки» и «переделки, при этом стоимость предельных „хотелок/переделок“ и стоимость „идеального ТЗ“ — равны, что само по себе заблуждение. Собственно „нафига ТЗ тогда надо“? При этом под стоимостью мы имеем ввиду, как и автор — все чаяния страждущих. Идеальный мир ТЗ, это когда мальчик, с невысокими интеллектуальным потребностями ловит золотую рыбку, просит её сделать ему большое ухо, второе большое ухо и большой нос, а по „завершению проекта“ рыбка в ответ на вопрос, почему тот не попросил ума слышит в ответ: „а можно было?“ И все счастливо расходятся, как в море корабли. Остальное — ниже.
Мне кажется что формула тут не главное. Хотя задуматься стоит. А вот структура ТЗ с объяснениями многим окажется полезной. Я сам пришел примерно к такой структуре для веб ТЗ. И за такую статью некоторое время назад был бы безумно благодарен.
А если кто не в курсе, то есть понятие Частное ТЗ, которое дополняет основное или часть. Кстати в проектах с дорогими ТЗ именно так и работают.
А если кто не в курсе, то есть понятие Частное ТЗ, которое дополняет основное или часть. Кстати в проектах с дорогими ТЗ именно так и работают.
Из графика следует, что стоимость проекта, сделанного по идеальному «дорогому» ТЗ сводит на нет все «хотелки» и «переделки, при этом стоимость предельных „хотелок/переделок“ и стоимость „идеального ТЗ“ — равны, что само по себе заблуждение.
Нет, вы неверно поняли текст. Я хочу чказать, что этот краевой случай не есть «иделальное ТЗ» по которому можно сделать проект без хотелок, я говорю что крайняя правая точка это есть готовый проект. Его немного некорректно называть ТЗ, это да, но мне нужна иллюстрация поясняющая тенденцию.
Про мальчика с ушами я опять не понял :)
Как то ход ваших мыслей мне не очень ясен. Какие отделы заказчиков-исполнителей? Какие пылесосы? Почему сайт не будет работать? Причем тут видео на сайте?
Потому что при соприкосновении ТЗ с реальностью возникают совершенно другие правила игры, каким бы развеселым не был интерфейс конструктора ТЗ. Не каждый заказчик (плательщик) сможет его освоить. Следовательно, идеальное применение проекта — взаимодействие внутри команды разработчик/дизайнер/проджект/аккаунт/продавец, где они выступают клиентами и исполнителями вашего примера, выше. Иначе на одном «обучении» заказчиков можно потерять больше, чем заработать. Т.е. стоимость владения этой системой не так низка, чего кривить душой или позиционирование (простите) не четкое.
«Пылесос Кирби — это такой пылесос, который решит все ваши проблемы, всего лишь за 100500 рублей, сейчас я покажу как он соберет целый мешок пыли в этой только что убранной комнате».
У вас на сайте проекта копирайт с 2008-го, ни одного отзыва клиента, ни одного живого человека из создателей системы, ни одного дизайна — успех на лицо. Вы только не подумайте, что это какой-то наезд, скорее добрая критика. Как без видео понять, о чем вы вообще и кто вы такие? Продолжить? Будто бы вы сказали «продолжить»:
Нафига вам моя фамилия и имя при регистрации, причем в принудительном порядке с подтверждением почтой по ссылке? Если вы решаете проблему, то покажите её решение, а не увеличивайте мою головную боль постоянным переходом из окна в окно ради того, что бы я увидел 156 новых букв, я среднестатистический, у вас на меня максимум 3-5 минут. Больше модальных окон, всяких драг-н-дропов и аяксов, вы же интернет-приложение сделали: на моих многодюймовых задолбаешься головой мотать от главного нода на схеме страниц до компонентов справа, онМаусОва доложны быть все эти тултипы и т.д. Запланируйте Undo или начните с малого — удобный фидбэк, типа «реформал» и живого приглашения потрепаться с вашими продавцами. Проект интересный, весь по ТЗ, это его слабость. У вас типичные недостатки технарских стартапов — решаете свою проблему, а пытаетесь выдать её за вселенскую. Даже не смотря на схожесть моей и вашей модели бизнеса, из которого система и выплыла, мы по разному её решаем, либо убедите, что мне выгодно пойти за вами, а я — дурак, либо не будьте столь категоричны в своем продукте. И все это с искренним пожеланием успеха в развитии этого интереснейшего продукта!
«Пылесос Кирби — это такой пылесос, который решит все ваши проблемы, всего лишь за 100500 рублей, сейчас я покажу как он соберет целый мешок пыли в этой только что убранной комнате».
У вас на сайте проекта копирайт с 2008-го, ни одного отзыва клиента, ни одного живого человека из создателей системы, ни одного дизайна — успех на лицо. Вы только не подумайте, что это какой-то наезд, скорее добрая критика. Как без видео понять, о чем вы вообще и кто вы такие? Продолжить? Будто бы вы сказали «продолжить»:
Нафига вам моя фамилия и имя при регистрации, причем в принудительном порядке с подтверждением почтой по ссылке? Если вы решаете проблему, то покажите её решение, а не увеличивайте мою головную боль постоянным переходом из окна в окно ради того, что бы я увидел 156 новых букв, я среднестатистический, у вас на меня максимум 3-5 минут. Больше модальных окон, всяких драг-н-дропов и аяксов, вы же интернет-приложение сделали: на моих многодюймовых задолбаешься головой мотать от главного нода на схеме страниц до компонентов справа, онМаусОва доложны быть все эти тултипы и т.д. Запланируйте Undo или начните с малого — удобный фидбэк, типа «реформал» и живого приглашения потрепаться с вашими продавцами. Проект интересный, весь по ТЗ, это его слабость. У вас типичные недостатки технарских стартапов — решаете свою проблему, а пытаетесь выдать её за вселенскую. Даже не смотря на схожесть моей и вашей модели бизнеса, из которого система и выплыла, мы по разному её решаем, либо убедите, что мне выгодно пойти за вами, а я — дурак, либо не будьте столь категоричны в своем продукте. И все это с искренним пожеланием успеха в развитии этого интереснейшего продукта!
А вот тут эмоциональнт, но по делу
Извините, а нафига заказчику сдалась моя программа? Я её делаю для исполнителей: фрилансеров и студий. На заказчиков я и не расчитываю, это глупо. Так, что ваш комментарий опять мимо кассы.
Тише-тише! Вот вы в статье своей 37 раз слово «заказчик» произнесли. Он у вас приходит, приносит дизайн в конце проекта, платит 100%, а я вас тут сразу просил уточнить, зачем вы пример ТЗ внутреннего «межкомандного» взаимодействия и внешнего, который с договором и оплатой, путаете. А вы — не слышите и продолжаете гнуть свою линию. Потому я и на статью начал наезжать. Посмотрите на сайт продукта. Видите, там написано «КОМУ?» И ниже: веб-дизайнерам, веб-разработчикам, веб-студиям, веб-заказчикам. «Раскашомалаште» пожалуйста последнее утверждение в комментарии вашем про заказчика, на которого вы не рассчитываете под предлогом «это глупо» и отделите мне его от заказчика на вашем сайте и в статье он у вас тусуется плотно именно как плательщик. Не для меня, а для себя и стройности идеи. Видите, я с вами говорю, пытаясь показать какие-то ошибки очевидные, который вы «не рекламируете», а вам кажется, что я куда-то целюсь и хочу попасть, а ваша задача — увернуться. Нет — ну и уворачивайтесь пожалуйста. ) Ниже вам хорошо сказали про различие клиентов. Сравнивать внутренних и внешних, как сравнивать плановую экономику и рынок. Т.е. функционально вы все сделали правильно, даже продаваться программа ваша должна, но как вы о ТЗ рассказали выше — это против вас работать будет на том рынке, куда вы с такой статьей и сайтом выйдите.
Толково разложено по полочкам. Хочу добавить, что очень важно помнить, что есть ТЗ которое пишется заказчиком для того что бы исполнитель понял что от него хотят (назовем это «предварительным ТЗ»), еще это можно назвать расширенным брифом, а есть ТЗ которое будучи основанным на этом самом расширенном брифе пишется уже совместными силами, согласовывается и заверяется как приложение к договору.
Вот пример брифа, а вот пример технического задания. Как правило любого из вариантов достаточно для того что бы оценить не сложный проект и в последствии разработать более детальное ТЗ, на основе которого будет разрабатываться сайт.
Вот пример брифа, а вот пример технического задания. Как правило любого из вариантов достаточно для того что бы оценить не сложный проект и в последствии разработать более детальное ТЗ, на основе которого будет разрабатываться сайт.
у вас ошибка тут
pornradio.me/tmp/i/216710656eb1e657bcde39544f7c.png
не брифинга, а брифа, скорее всего вы имели ввиду.
pornradio.me/tmp/i/216710656eb1e657bcde39544f7c.png
не брифинга, а брифа, скорее всего вы имели ввиду.
Я наверное вас удивлю, но документы «постановка задач» и «функциональные требования» существуют.
Спасибо за отличную статью. Видно, что написано со знанием дела, что в голове некоторое время складывалось, а потом уже было выдано другим. Спасибо за твой труд.
По своему опыту могу сказать, что как бы «хорошо» не было написано ТЗ, итоговый результат на практике отличается сильно. И главное назначение ТЗ — это аргумент разработчика в пользу того, что эта разница должна быть (и будет) оплачена.
Тем не менее пост весьма нужный. Он расставит по полочкам некоторые вещи в голове менеджера (если таковые его здесь прочтут).
PS: Свое самое «тяжелое» ТЗ я писал не одну неделю и общее время, потраченное на его написание составило не менее 20% от времени работы над проектом. После этого случая я объявляю цену за написание ТЗ и нередко Заказчик, пытаясь съэкономить, пишет его сам ;)
Тем не менее пост весьма нужный. Он расставит по полочкам некоторые вещи в голове менеджера (если таковые его здесь прочтут).
PS: Свое самое «тяжелое» ТЗ я писал не одну неделю и общее время, потраченное на его написание составило не менее 20% от времени работы над проектом. После этого случая я объявляю цену за написание ТЗ и нередко Заказчик, пытаясь съэкономить, пишет его сам ;)
Спасибо. Сайтами не занимаюсь, но пару важных мыслей о ТЗ получил.
Давно хотел вставить эту картинку. ekimoff.ru/download/job/1.jpg
Есть один маленький нюанс.
Кто будет писать ТЗ? Заказчик? Я вас умоляю! 90% клиентов знать не знают чего они хотят. Вы сами? Отлично, вариант хороший. Но вы ведь понимаете, что ТЗ будет стоить вам времени, оплату которого никто не гарантирует, да?
Вот вам ситуация, классическая до банальности — вам стучит, звонит, телеграфирует клиент. И говорит — хочу мол сайт по продаже футболок. Ваши действия? «Уважаемый, мы ждём от вас подробное ТЗ на 20 страницах с эскизами иначе идите нахуй»? Если вы — Артемий Лебедев, то да. Если нет, то у вас есть следующие адекватные варианты романа с клиентом:
Рассмотрим эти ситуации подробнее:
1) Всё круто, но вы потеряли процентов 80% клиентов, которым ни в жисть не интересно составлять какие-то там ТЗ по форме.
2) Отлично, но вы потеряли 95% клиентов.
3) Идеальный вариант для студии, работающей в ключе «поставщик-исполнитель-грузополучатель». Фейл для тех клиентов, которым нужна примерная стоимость ваших услуг ± 100$ прямо сейчас.
Из тех, кто согласился на схему с ТЗ вы отсеите не меньше половины обратившихся. А с каждым ТЗ вы потеряли 2-3 часа своего времени и столько же времени вашего разработчика на оценку.
4) и 5) — основная на мой взгляд линия поведения при беседе с заказчиком.
Я не соглашусь с тезисом автора статьи о том, что ТЗ и дизайн не коррелируют. Практика показывает, что в нашем бизнесе дизайн и есть ваше самое подробное и полное ТЗ. Именно на нём виден ВЕСЬ оплаченный функционал. Так же, как и на примере понравившегося сайта (хотя тут есть свои подводные камни).
В общем и целом формализацию процесса в нормальных условиях можно свести к следующему:
Помните, что, если вы не делаете сайт Газпрома, а работаете с малым бизнесом или общаетесь с директором крупного предприятия напрямую, то важна заботливая опека клиента. Сегодня самый популярный тренд — это индивидуальный подход. Хотя рубить сплеча концепцию ТЗ не стоит. В сфере услуг нужно понимать, чего от тебя хочет клиент и действовать индивидуально. Только так можно запустить грамотное сарафанное радио и удерживать возле себя клиентов постоянно помогая им и получая за это достойное вознаграждение.
Если кого заинтересовали детали подхода — могу себе закинуть в план статью на эту тему.
Кто будет писать ТЗ? Заказчик? Я вас умоляю! 90% клиентов знать не знают чего они хотят. Вы сами? Отлично, вариант хороший. Но вы ведь понимаете, что ТЗ будет стоить вам времени, оплату которого никто не гарантирует, да?
Вот вам ситуация, классическая до банальности — вам стучит, звонит, телеграфирует клиент. И говорит — хочу мол сайт по продаже футболок. Ваши действия? «Уважаемый, мы ждём от вас подробное ТЗ на 20 страницах с эскизами иначе идите нахуй»? Если вы — Артемий Лебедев, то да. Если нет, то у вас есть следующие адекватные варианты романа с клиентом:
- 1. Пришлите нам ТЗ на ваш проект по форме 0-16, которую вы можете скачать на нашем сайте.
- 2. Опишите пожалуйста подробнее ваш проект и бюджет. По итогам разговора мы составим ТЗ и вышлем вам на согласование. Стоимость составления оценок проекта — 100$
- 3. Опишите пожалуйста подробнее ваш проект и бюджет. По итогам разговора мы составим ТЗ и вышлем вам на согласование (идеально-бюрократический вариант)
- 4. Покажите пожалуйста дизайн проекта (если заказчик, конечно, не хочет сайт под ключ)
- 5. Покажите пожалуйста 2 или 3 сайта в интернете, которые больше всего вам нравятся и соотвествуют вашим представлениям о том, как сайт должен работать
Рассмотрим эти ситуации подробнее:
1) Всё круто, но вы потеряли процентов 80% клиентов, которым ни в жисть не интересно составлять какие-то там ТЗ по форме.
2) Отлично, но вы потеряли 95% клиентов.
3) Идеальный вариант для студии, работающей в ключе «поставщик-исполнитель-грузополучатель». Фейл для тех клиентов, которым нужна примерная стоимость ваших услуг ± 100$ прямо сейчас.
Из тех, кто согласился на схему с ТЗ вы отсеите не меньше половины обратившихся. А с каждым ТЗ вы потеряли 2-3 часа своего времени и столько же времени вашего разработчика на оценку.
4) и 5) — основная на мой взгляд линия поведения при беседе с заказчиком.
Я не соглашусь с тезисом автора статьи о том, что ТЗ и дизайн не коррелируют. Практика показывает, что в нашем бизнесе дизайн и есть ваше самое подробное и полное ТЗ. Именно на нём виден ВЕСЬ оплаченный функционал. Так же, как и на примере понравившегося сайта (хотя тут есть свои подводные камни).
В общем и целом формализацию процесса в нормальных условиях можно свести к следующему:
- 1. Если у вас нет дизайна — вы пишите смету. Она будет и вашим гарантом, и путеводной звездой для клиента. Смету составить проще и быстрее, чем полное и красивое ТЗ.
- 2. Вы профессионал. И должны закладывать в каждый проект возможность внести любые правки бесплатно в некотором оговоренном объёме. Например мы вносим в условия работы от 4х часов бесплатных правок любого характера (в зависимости от проекта)
- 3. Обязательно оговорите момент про доработки. Объясните, что «Вот тут баннер добавить» будет стоить ваша_ставка * трудозатраты по задаче. Кстати, после таких объяснений есть шанс, что клиент таки инициирует работы над ТЗ.
- 4. Подчеркните тот факт, что вы правите баги бесплатно как минимум 2-3 недели после сдачи проекта (но лучше править их бесплатно 2-3 месяца после сдачи), и тот факт, что вы всегда готовы дописывать проект за отдельную плату
Помните, что, если вы не делаете сайт Газпрома, а работаете с малым бизнесом или общаетесь с директором крупного предприятия напрямую, то важна заботливая опека клиента. Сегодня самый популярный тренд — это индивидуальный подход. Хотя рубить сплеча концепцию ТЗ не стоит. В сфере услуг нужно понимать, чего от тебя хочет клиент и действовать индивидуально. Только так можно запустить грамотное сарафанное радио и удерживать возле себя клиентов постоянно помогая им и получая за это достойное вознаграждение.
Если кого заинтересовали детали подхода — могу себе закинуть в план статью на эту тему.
Я проходил мимо, но вас понял. Пишите. Сейчас тут образовалось две секты: «рационалы» и «эмоционалы», при чем и те и другие считают друг-друга..., но при этом зарабатывают одни и те же деньги на одном и том же рынке продавая совершенно разные продукты. Вы теперь на контроле. Ждем-с! )
Кстати, ваш комментарий выше мне показался весьма адекватным. Рационализм и практицизм технарей (а ведь я и сам технарь в большей мере, хоть и закидываю удочки в юзабилити и apple-style дизайн :) уже давно «не рулит». Просто люди таки начали понимать, что компьютер и софт для него были изобретены для упрощения решения задач, а не для того, чтобы пользователь год учил новый способ взаимодействия с гипер-крутым аппом, написанным по самым последним парадигмам ООП. Пользователю в общем-то плевать на язык, парадигмы и т.д. Он будет взаимодействовать с интерфейсом и дизайном ВСЁ время работы с программой или вебсайтом. Значит это камень преткновения, и абстрагироваться от дизайна в ТЗ — это весьма опрометчиво. Собственно проект автора статьи — наглядный тому пример.
Я попробую выразить свое видение процесса работы с заказчиком.
1. Приходит клиент и говорит «Я хочу сайт».
2. Мы выясняем, что есть у клиента «Что у вас есть по сайту? Какой сайт, есть ли ТЗ, бриф или похожие сайты? Если есть — хорошо, если чего-то нет или нет вообще ничего, тоже не страшно, давайте поговорим про то, что вы хотите.»
3. Рассказ клиента про сайт.
4. Мы сразу даем начальную очень грубую оценку с погрешностью от -50% до +100% Если масштаб цен подходящий, мы выясняем все требования, пишем ТЗ, называем точную стоимость и сроки.
5. Написание, утверждение ТЗ
6. Дизайнер делает свою работу, общаясь напрямую с клиентом. Как правило, пока дизайнер приходит к концептуальному согласию с заказчиком (результатом этой работы становится макет главной (или самой важной) страницы, который нравится заказчику, но в дальнейшем будет подкорректирован) параллельно делается ТЗ.
7. Утверждается ТЗ, и параллельно идет прорисовка всех страниц дизайнером.
8. Вступает в работу программист и верстальщик. Программист может начать работу несколько раньше, когда уже понятна общая картина.
9. Завершение работ, исправление верстки, багов, пожеланий, выкладывание на хостинг клиента.
В схеме бывают отклонения, по обстоятельствам.
Особо хочу отметить работу дизайнера. Обычно, в случаях когда дизайн появляется до ТЗ, часть работы по написанию ТЗ (точнее по сбору требований) ложится на дизайнера с заказчиком. Прорисовывая странички, дизайнер помимо вопросов «дизайна», в смысле красивости, думает еще и над тем, какие атрибуты должны быть у товара в каталоге или что будет иметь новость. Т.е. когда дизайнер сделал диз первой страницы, на которой есть список новостей, он нам (разработчикам) сообщил, что заказчик желает, что бы у новости было название, анонс, картинка и теги. Т.е. по сути дизайнер с заказчиком выполнили кусочек из ТЗ «данные и списки».
Для дизайнера настает беда, когда концептуально дизайн утвержден и ему говорят, что «а теперь нарисуй остальные страницы сайта». А откуда он знает про все страницы сайта? В результате получается, что часть страниц не нарисована, зато нарисованы лишние, а на некоторых страницах просто ересь какая-то.
Вы бы видели дизайнеров, которые имели радость прорисовывать все страницы, имея ТЗ со скетчами, на сколько быстрее и качественнее всё получалось. Более того дизайнер попробовавший рисовать по ТЗ очень расстраивался, когда в следующий раз ему приходилось работать без ТЗ.
По поводу стоимости ТЗ. ТЗ — это выяснение требований к сайту. Эта работа в любом случае будет выполнена, только работая без ТЗ, этап выяснения требований «размазан» по всему проекту, мы постоянно общаемся с заказчиком уточняя детали. С ТЗ этот «размазанный» этап сбора информации выносится в отдельную работу. Соответственно, у программиста исчезают паузы в работе, когда что-то нужно уточнить у заказчика и на время выяснения деталей процесс стопорится.
Т.е. ТЗ уменьшает простои, паузы; дает предсказуемость и возможность лучше планировать деятельность.
1. Приходит клиент и говорит «Я хочу сайт».
2. Мы выясняем, что есть у клиента «Что у вас есть по сайту? Какой сайт, есть ли ТЗ, бриф или похожие сайты? Если есть — хорошо, если чего-то нет или нет вообще ничего, тоже не страшно, давайте поговорим про то, что вы хотите.»
3. Рассказ клиента про сайт.
4. Мы сразу даем начальную очень грубую оценку с погрешностью от -50% до +100% Если масштаб цен подходящий, мы выясняем все требования, пишем ТЗ, называем точную стоимость и сроки.
5. Написание, утверждение ТЗ
6. Дизайнер делает свою работу, общаясь напрямую с клиентом. Как правило, пока дизайнер приходит к концептуальному согласию с заказчиком (результатом этой работы становится макет главной (или самой важной) страницы, который нравится заказчику, но в дальнейшем будет подкорректирован) параллельно делается ТЗ.
7. Утверждается ТЗ, и параллельно идет прорисовка всех страниц дизайнером.
8. Вступает в работу программист и верстальщик. Программист может начать работу несколько раньше, когда уже понятна общая картина.
9. Завершение работ, исправление верстки, багов, пожеланий, выкладывание на хостинг клиента.
В схеме бывают отклонения, по обстоятельствам.
Особо хочу отметить работу дизайнера. Обычно, в случаях когда дизайн появляется до ТЗ, часть работы по написанию ТЗ (точнее по сбору требований) ложится на дизайнера с заказчиком. Прорисовывая странички, дизайнер помимо вопросов «дизайна», в смысле красивости, думает еще и над тем, какие атрибуты должны быть у товара в каталоге или что будет иметь новость. Т.е. когда дизайнер сделал диз первой страницы, на которой есть список новостей, он нам (разработчикам) сообщил, что заказчик желает, что бы у новости было название, анонс, картинка и теги. Т.е. по сути дизайнер с заказчиком выполнили кусочек из ТЗ «данные и списки».
Для дизайнера настает беда, когда концептуально дизайн утвержден и ему говорят, что «а теперь нарисуй остальные страницы сайта». А откуда он знает про все страницы сайта? В результате получается, что часть страниц не нарисована, зато нарисованы лишние, а на некоторых страницах просто ересь какая-то.
Вы бы видели дизайнеров, которые имели радость прорисовывать все страницы, имея ТЗ со скетчами, на сколько быстрее и качественнее всё получалось. Более того дизайнер попробовавший рисовать по ТЗ очень расстраивался, когда в следующий раз ему приходилось работать без ТЗ.
По поводу стоимости ТЗ. ТЗ — это выяснение требований к сайту. Эта работа в любом случае будет выполнена, только работая без ТЗ, этап выяснения требований «размазан» по всему проекту, мы постоянно общаемся с заказчиком уточняя детали. С ТЗ этот «размазанный» этап сбора информации выносится в отдельную работу. Соответственно, у программиста исчезают паузы в работе, когда что-то нужно уточнить у заказчика и на время выяснения деталей процесс стопорится.
Т.е. ТЗ уменьшает простои, паузы; дает предсказуемость и возможность лучше планировать деятельность.
Часто сталкиваюсь с такими программистами, которые рисуют как на первой картинке. От таких лучше держаться подальше — это не профессиональные разработчики. Поясню.
Как часто вы приходя в салон с фразой: " мне нужен автомобиль " слышите: " вот есть Жигули "? Как часто выбирая тур вы слышите: " вот отличный двухзвездочный номер " и т. Д
Тот, кого вы описали первой картинкой — индус, к индусу нужен прораб, нет смысла учить индуса тому чему он сам не научился до вас.
Как часто вы приходя в салон с фразой: " мне нужен автомобиль " слышите: " вот есть Жигули "? Как часто выбирая тур вы слышите: " вот отличный двухзвездочный номер " и т. Д
Тот, кого вы описали первой картинкой — индус, к индусу нужен прораб, нет смысла учить индуса тому чему он сам не научился до вас.
Ну если речи о фрилансе, то это скорее:
— У меня есть две тысячи рублей и три бутерброда. Где мне забрать мой BMW?
— У меня есть две тысячи рублей и три бутерброда. Где мне забрать мой BMW?
Если программист рисует как художник, ему за 30 и он — счастлив, ему нужно перестать курить психоактивные вещества и заняться поделками на node.js, или забросить программирование полностью. Как говорил один хороший человек — нельзя одной рукой держаться и за сисю и за писю. Так что если отличный программист рисует абстрактную живопись — это не страшно.
А стоимость проекта от детализации ТЗ не зависит? Или Вы рассчитываете не почасовую оплату, а за проект целиком?
Из моего опыта как раз удобнее фиксировать время и бюджет, а функционал варьировать.
Из моего опыта как раз удобнее фиксировать время и бюджет, а функционал варьировать.
Я говорю о фиксировании и цены, и функционала.
В общем говоря стоимость не зависит от подробности ТЗ. Смотрите, вы хотите сайт с неким набором функций. Не будет же зависить цена этих функций от того опишу я ТЗ или нет, и как подробно. Но наличие и подробность ТЗ может влиять на стоимость разработки (для исполнителя), т.к. от этого зависит сколько переделок будет сделано.
Т.е. для заказчика всё равно есть ТЗ или нет, для него цена не меняется от наличия или отсутвия ТЗ, для разработчика наличие или отсутвие ТЗ может влиять на стоимость работы.
Для разработчика, конечно идеальный вариант — почасовая оплата, только мало кто из заказчиков согласится на условия типа таких: «мы будем работать по 10 уе/час, пока всё не сделаем».
В общем говоря стоимость не зависит от подробности ТЗ. Смотрите, вы хотите сайт с неким набором функций. Не будет же зависить цена этих функций от того опишу я ТЗ или нет, и как подробно. Но наличие и подробность ТЗ может влиять на стоимость разработки (для исполнителя), т.к. от этого зависит сколько переделок будет сделано.
Т.е. для заказчика всё равно есть ТЗ или нет, для него цена не меняется от наличия или отсутвия ТЗ, для разработчика наличие или отсутвие ТЗ может влиять на стоимость работы.
Для разработчика, конечно идеальный вариант — почасовая оплата, только мало кто из заказчиков согласится на условия типа таких: «мы будем работать по 10 уе/час, пока всё не сделаем».
Я недавно задумал один небольшой проект и в роли заказчика решил написать ТЗ на веб-сервис. Знаете, это отличный способ для заказчика разобраться в собственном проекте. Сделать из Идеи что-то более близкое к реализации. Понять какие-то нюансы, скорректировать бизнес-процессы, даже внести какие-то изменения в Идею. Очень полезно, я считаю.
PS: Кстати ТЗ еще ждет своего исполнителя ;)
PS: Кстати ТЗ еще ждет своего исполнителя ;)
Достойная вдумчивая статья. Было бы вообще шикарно, если бы она «подкрепилась» не менее достойным примером.
Большое спасибо за статью!
Нашёл много новых пунктов применительно к своему ТЗ на создание сайта. Хотелось бы услышать ваши размышления насчет ТЗ на продвижение.
И, по-моему, это самый быстрорастущий топик в избранном у хабраюзеров за всю историю! Автор — молодец! Затронул действительно важную для каждого из нас тему. Спасибо!
Нашёл много новых пунктов применительно к своему ТЗ на создание сайта. Хотелось бы услышать ваши размышления насчет ТЗ на продвижение.
И, по-моему, это самый быстрорастущий топик в избранном у хабраюзеров за всю историю! Автор — молодец! Затронул действительно важную для каждого из нас тему. Спасибо!
Хорошоая статья. Я думаю она показана к прочтению как заказчиком так и исполнителем.
Чтение статьи и комментариев напомнило мне недавно прочитанную книгу о роли творчества в программировании и вечное противостояние между формальным и творческим подходам. Сильный перегиб в ту или уную сторону, как правило фатален, поэтому, всегда стоит искать компромисс, а это, к сожалению, не всегда просто.
Чтение статьи и комментариев напомнило мне недавно прочитанную книгу о роли творчества в программировании и вечное противостояние между формальным и творческим подходам. Сильный перегиб в ту или уную сторону, как правило фатален, поэтому, всегда стоит искать компромисс, а это, к сожалению, не всегда просто.
Пропущен важный момент — стоимость самого техзадания, на его написание тоже нужно потратить время, и иногда немало + заказчик может взять ваше ТЗ и потом спокойно уйти к другим разработчикам.
Мы делаем так: в приложении к договору прописываем стоимость и сроки разработки технического задания, к которому приступаем после предоплаты, а в самом договоре пишем, что ТЗ после утверждения сторонами является неотъемлемой частью договора. Обычно его оформляем как Приложение №2. В принципе, тут тоже есть некоторая несуразица, но по крайней мере мы уверены, что клиент не убежит с нашим ТЗ к другому. Пока никто не убегал. :)
Стоимость разработки технической документации. Часть I
За статью либо хорошо, либо ничего. Предпочту ничего.
За статью либо хорошо, либо ничего. Предпочту ничего.
Привет из 2016-го) Большое спасибо за статью!
И в 2018 актуально! ) Спасибо!
Дополню ссылкой на статью, с договром на разработку ТЗ https://habr.com/post/30051/
Отличная статья! Только мы прототипы рисуем с пояснениями, а структуру делаем на основе материалов от заказчика + аналитика поискового спроса.
Получается примерно так:
https://www.nevsem.ru/services/tehnicheskoe-zadanie-koncepciya
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Техническое задание на сайт