Pull to refresh

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

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

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

image
Читать дальше →
Total votes 90: ↑82 and ↓8 +74
Views 249K
Comments 48

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

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

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

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

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

Читать дальше →
Total votes 240: ↑225 and ↓15 +210
Views 95K
Comments 87

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

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

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

Website development *
UPD: Продолжение статьи с примером техзадания

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

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

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

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


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

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



Далее много букв
Total votes 212: ↑209 and ↓3 +206
Views 690K
Comments 141

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

Website development *


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

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

Много текста и картинок
Total votes 70: ↑63 and ↓7 +56
Views 198K
Comments 58

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

Website development *
Sandbox

Вступление


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

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

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

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

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

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

Мосигра corporate blog System Analysis and Design *Game development *


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

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

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

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

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

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

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

КРОК corporate blog IT Infrastructure *

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

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

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

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

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

КРОК corporate blog IT Infrastructure *


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

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

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

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

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

Development Management *Project management *Product Management *
Sandbox
Tutorial


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

Возможно ли такое на практике?
Читать дальше →
Total votes 35: ↑33 and ↓2 +31
Views 18K
Comments 29