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

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

Управление проектами *
ОФФТОП: Хочу выразить свою благодарность, всем кто плюсанул мой предыдущей пост и карму, это позволило мне пригласить на Хабр еще несколько хороших людей.

Во многих студиях нет единого формата ТЗ, у нас его тоже не было. Просмотрев множество различных форматов и ГОСТов, мы выбрали самые значимые пункты и разработали типовой шаблон ТЗ для нашей компании.
Возможно, это будет полезно и другим студиям, т.к. если мы все будем работать по единым стандартам плюсы очевидны как для студий, так и для заказчиков.

image
Читать дальше →
Всего голосов 90: ↑82 и ↓8 +74
Просмотры 249K
Комментарии 48

Техническое задание: какие элементы должны быть прописаны, а какие – в уме

Блог компании Digital Professionals Hub
Когда мне предложили данную тему для написания своих мыслей в виде статьи, я долго думал, о чем же написать, потому что, по сути, вся данная статья укладывается в одно предложение, которое является прямым ответом на данный вопрос — Все документы должны быть прописаны и никаких моментов не должно быть в уме. Почему именно так? Рассмотрим по пунктам:
Читать дальше →
Всего голосов 47: ↑26 и ↓21 +5
Просмотры 21K
Комментарии 13

Почему фрилансер и заказчик часто считают друг друга идиотами

Блог компании Мосигра
Мне повезло: я побывал по обе стороны баррикад и теперь знаю, что и как делает заказчик на проектах разного уровня и что делает фрилансер, чтобы получить или провалить такой проект. В итоге я уверен, что 95% фрилансеров говорят с заказчиком на разных языках.

Осторожно, butthurt.

Читать дальше →
Всего голосов 240: ↑225 и ↓15 +210
Просмотры 95K
Комментарии 87

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

Чулан
Из песочницы
Сколько лет занимаюсь разработкой сайтов, всегда сталкиваюсь с одной проблемой — 9 из 10 заказчиков считают, что мы телепаты. Мы — это в принципе все айтишники, а, может быть, и специалисты других отраслей (не могу сказать точно — не пробовал). Когда заказчик говорит «мне нужен интернет-магазин для продажи <...> через интернет», он обычно предполагает, что любой интернет-магазин — это нечто «готовое», позволяющие «делать деньги» просто после того как «наполнил склад» и получил от Исполнителя сам сайт.
Я не буду здесь расписывать про раскрутку магазина, про юридические и бюрократические нюансы. Просто хочу потенциальным заказчикам (неважно у кого заказывать) дать несколько советов, чтобы в результате они получили то, чего хотят, а не то, чего хотел разработчик.
Читать дальше →
Всего голосов 35: ↑28 и ↓7 +21
Просмотры 5.2K
Комментарии 35

Техническое задание на сайт

Разработка веб-сайтов *
UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ


А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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



Далее много букв
Всего голосов 212: ↑209 и ↓3 +206
Просмотры 691K
Комментарии 141

Техническое задание на сайт. Практика

Разработка веб-сайтов *


В комментариях к статье Техническое задание на сайт зашел разговор о шаблоне для техзадания и, собственно, примере ТЗ, составленного по описанным в статье принципам. Там я пообещал показать, и шаблон, и само ТЗ.

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

Много текста и картинок
Всего голосов 70: ↑63 и ↓7 +56
Просмотры 198K
Комментарии 58

Технология сбора требований в процессе проектирования сайта

Разработка веб-сайтов *
Из песочницы

Вступление


Сбор требований – это один из самых важных этапов при создании информационных систем и интернет-сайтов в частности. От того, насколько точно и полно будут учтены все пожелания заказчика в процессе проектирования сайта, и будет зависеть итоговый результат: получим ли мы сайт «для галочки» или это будет эффективный инструмент бизнеса, который будет приносить прибыль своему владельцу.
Предлагаемая методика сбора требований используется в нашей компании при разработке несложных клиентских сайтов, реализуемых по каскадной модели (Waterfall). Методика позволяет менеджеру по продажам организовать эффективный сбор требований и написать на его основе «Техническое задание», по которому разработчик будет создавать сайт.
Замечу, что ничего не мешает использовать данную методику сбора требований и в Agile–разработке, в частности, для создания первичного бэклога.
В данной статье я концентрировался именно на содержательной части сбора требований, а не на вопросах внедрения сбора требований в бизнес-процессы компании или на то, как строить диалог с клиентом – это тема для отдельного разговора.
Читать дальше →
Всего голосов 9: ↑8 и ↓1 +7
Просмотры 41K
Комментарии 9

FAQ про центры решений — как большие компании в России выбирают софт так, чтобы не наступать на грабли

Блог компании КРОК
Малый бизнес берёт демку и ставит чтобы посмотреть. Средний бизнес идёт к соседям и советуется, смотрит, а потом внедряет у себя. Крупный бизнес так сделать не может, потому что софт уровня ERP нельзя просто взять и попробовать (на одну организацию тестов может уйти 2 месяца), у соседей можно подсмотреть только общие принципы, да и дистрибутив и лицензию так просто не достать.

Поскольку понять как что-то сделать на таком уровне очень сложно (всё-таки надо иметь пару лет крайне редкого опыта), а вариантов как правило не один, начинаются проблемы. В итоге может получиться размытое техзадание, которое выставляется на тендер. И тендер выигрывает «за две копейки» кто-то, кто сделает всё, как было в задаче — но при этом совершенно не то, что хотел бизнес. Думаю, как это происходит, объяснять не нужно.

Поэтому и нужны специальные центры решений — своего рода испытательные полигоны. Там можно посмотреть на один рабочий день абстрактной компании с позиции пользователей из разных отделов, администратора и так далее, используя уже заполненные тестовые базы и смоделированную инфраструктуру.
Читать дальше →
Всего голосов 30: ↑24 и ↓6 +18
Просмотры 12K
Комментарии 3

Как мы проектируем и прототипируем всякую фигню

Блог компании Мосигра Анализ и проектирование систем *Разработка игр *


Главный враг раздолбайства — план.

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

С планом тесно связан прототип. Это может быть что угодно: черновик новой игры на салфетках, накарябанный от руки в блокноте макет указателя в метро, детальная схема процессов или же CAD-файл, например, для выкладки магазина.

Подобный подход рождает несколько довольно странных выводов. Например, если речь идёт о новом сайте – явно, что все тексты должны быть готовы до начала работ по дизайну. При работе с игрой виртуальные прототипы (в симуляциях) работают только на последних этапах балансировки, вначале же куда важнее быстро собрать на бумаге. Если уж говорить шире, то мы знаем, что новый XCOM (и XCOM2) тестировали и тестируются как настолки, а потом уже гонятся на компьютер.

Может показаться, что прототипировать — это вроде как не очень нужно. Херак-херак — и в продакшн. На самом деле, это чертовски важно в любом процессе; например, по заветам юзабелистов — это 70% работы. Вопрос только в том, как это можно делать.

Я не претендую на истину в этом вопросе, и мне очень интересен ваш опыт. Давайте сначала расскажу, какие мы вывели для себя вещи в прототипировании, а потом попрошу вас рассказать о своих прототипах и процессах проектирования.
Читать дальше →
Всего голосов 46: ↑43 и ↓3 +40
Просмотры 37K
Комментарии 49

Не наступайте на наши грабли с ТЗ: эпический опыт конкурсов и пара баек

Блог компании КРОК IT-инфраструктура *

Широко известный пример неточно поставленного ТЗ

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

Однажды мне достался проект, рассчитанный на полтора года с ооочень трудным заказчиком. Статус: прошло полгода, но всё ещё идут согласования технического задания. Подписались на одно, но заказчик упорно продолжал выдвигать новые требования. Задача ставилась даже не закончить вовремя или заработать, а выйти достойно, с минимальными для всех потерями.

Было сложно — не то слово. В длинном перелёте я читал ТЗ на 20 страниц. В нём была такая особенность: если читать его бегло, то может показаться, что оно написано правильно и точно. Но если начать копать в детали инженерной реализации, то всплывало сразу много нежданчиков. Некоторые требования подпунктов, вроде 3.2.5 и 4.8.2.9, могли противоречить друг другу или быть просто взаимно невыполнимыми в реальном мире.
Читать дальше →
Всего голосов 50: ↑44 и ↓6 +38
Просмотры 32K
Комментарии 21

Интеграция — байки

Блог компании КРОК IT-инфраструктура *


Тебе хана, если ты не влез в бизнес-процесс заказчика, а копаешься только в ИТ-процессе.

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

Я видел много разных историй: и то, как один малюсенький сервис для работы с факсами после внедрения начал вести себя как вирус и бороться с почтовым сервером и другими сервисами компании (кстати, победил), и то, как сегмент «малый и средний бизнес» не включал в себя средний бизнес (к искреннему удивлению ИТ-отдела), и как люди просто не знали, в чём смысл обрабатываемых данных и зачем они нужны — это часто касается финансов.

Поэтому давайте расскажу пару баек про то, что случается, когда нужно просто взять и соединить несколько ИТ-систем. Делов-то!
Читать дальше →
Всего голосов 47: ↑47 и ↓0 +47
Просмотры 23K
Комментарии 12

Ты можешь писать безупречные ТЗ, но какой в этом толк, если разработчик твой плачет?

Управление разработкой *Управление проектами *Управление продуктом *
Из песочницы
Tutorial


В далекой-далекой галактике трудится сферический product owner. Он бегло пишет заметки на салфетке и молча отдает ее разработчикам. А вскоре получает готовый продукт, который на 100% соответствует его ожиданиям. Даже если продукт этот – сложный кроссплатформенный сервис с блэкджеком и адаптивностью.

Возможно ли такое на практике?
Читать дальше →
Всего голосов 35: ↑33 и ↓2 +31
Просмотры 19K
Комментарии 29