Практически любая разработка или создание продукта начинается с описания, что нужно получить в конечном счете. Все могут применить понятие "Техническое задание" исходя из жизненного опыта. Будь это задание к курсовой работе в университете или список покупок для похода в магазин. В большинстве случаев сложность и его содержание зависит от многих факторов и от цели для чего создается техническое задание (далее будем именовать его просто ТЗ).
Во всех случаях общение заказчика и исполнителя всегда желательно отображать в документальной форме. Как бы ни старался заказчик сформировать суть чего он хочет получить в конечном счете, как показывает практика, исполнитель подвержен тому, что что-то он все-таки обязательно сделает не так, как ожидал заказчик, или что может быть на много хуже, не сделает того именно через отсутствие четких требований. Ибо как говорится "есть возможность не делать чего-то, не делай", потому как - инициатива наказуема.
В разработке информационных систем и в частности сайтостроении правильное ТЗ является чуть ли не залогом успеха на всех стадиях.
В технических ВУЗах часто пытаются прививать способность требовать щепетильного анализа на этапе проектирования, чтобы было описано все до малейших деталей. Очень часто сопровождаемо присказкой "как корабль назовешь - так он и поплывет". Но как обычно,большинство путает ТЗ и сам по себе технический проект.
Технический проект - это документация на уже сформированный продукт (на этапе проектирования), который требует основательного описания всех имеющихся возможностей и свойств продукта, а также описания процессов создания.
Техническое задание - это описание того, как желательно сделать продукт и по факту техническое задание подвержено и изменениям в процессе проектирования, и в процессе создания продукта. Что больше чем всегда случается с информационными системами.
Грубо говоря, по техническому проекту можно клонировать продукты, а тз - это частный вариант технического проекта, когда все нужно делать по месту.
Естественно, что при создании информационных продуктов можно ориентироваться на технические проекты. Но в данном случае, при грамотно составленном проекте и достаточной детализации - он будет напоминать некоторый псевдокод, который должен адаптировать программист в среде программирования. Требования к программисту в таком случае минимальные. Он должен уметь на уровне курса школьной информатики отобразить в коде весь функционал. Но тогда проектировщик должен быть универсальным специалистом/менеджером - который сможет если не спроектировать все сам, то хотя бы проанализировать и скомпоновать информацию от многих профилированных исполнителей при проектировании. Здесь нужно заметить что все это требует немалых не только усилий, но достаточного времени, что может, при определенной сложности затянуться если не на месяцы, то на годы точно. Но тогда есть риск, что в процессе создания технического проекта технологии будут устаревать, не успев реализоваться в готовом продукте.
Итак, ТЗ - это грамотно составленное изложение требований заказчика исполнителю. Процесс создания можно разложить на такие этапы
В данном случае эти все понятия являются категориями из юридической плоскости. он будут уместны в договоре рядом с суммами.
Для более реального случая можно рассмотреть ТЗ на создание сайта по сдачи жилья в аренду.
В большинстве случаев этот этап проходит полностью на стороне заказчика. Его суть - сформировать абстрактное понимание чего все хотят в конечном счете. Из документов можно отложить только фотоснимки набросков на доске или бумаге сделанных от руки.
Чем более точно специализированный консультант, тем более шире можно будет охватить все свойства элементов. Ключевым моментом является категорическое отсутствие специалистов из области создания сайтов или каких-либо неквалифицированных специалистов типа IT-консультантов. Это позволит избежать излишней детализации и бюрократии в процессе согласования.
По возможности нужно стараться не прерывать цепочку:
тех.-специалист(ы) заказчика <-> менеджер по работе с исполнителем <-> менеджер по работе с заказчиком <-> команда исполнителей
Это может выглядеть как создание временно статических страниц с воспроизведенным заказанным дизайном или текстовые страницы, на которых реализована логика обработки.
Возможно потребуется формирование временных данных на основе генератора.
Создание тестовых баз и тестовых подсистем очень сильно помогают не нагромождать абстрактную документацию без ее реализации.
Всегда нужно разделить процесс на потоки - дизайн/оформление, логика обработки основных данных, обслуживающая логика системы.
Существует множество методологий при сопровождении проектов таких как - scrum, agile, RAD, XP и др., которые приветствуют разработку на коротких циклах, при постоянном контроле и тестировании.
На отмену от "Каскадной модели" суть которой сводится к диаграмме:
Требования ->
Проектирование ->
Реализация ->
Тестирование ->
Эксплуатация
любой из выше приведенных методов более приемлем. Процесс построения домов, мостов, механизмов не сильно изменился за последние тысячелетие. Возможность что-то изменить после построения, особенно на ранних этапах - очень трудоемкий и затратный на отмену от информационных систем. Поэтому водопадная модель и является основной в домостроительстве и машиностроительстве. Но она практически неприменимая в строительстве сайтов. Здесь нужно учитывать, что браузеры и платформы сменяют друг-друга очень часто. В большинстве случаев это связано с безопасностью. Но часто и через конкуренцию для поддержания как можно больше новых технологий.
Линейное/структурное программирование в 90-х было замещено объектно-ориентированным. Объектно-ориентированное в конце 90-х обрело шаблоны проектирования, каркасное проектирование, что позволяет на порядок увеличить и скорость разработки и сложность, параллельно расширяя функциональность и масштабируемость.
Поэтому игнорирование современных инструментов и технологий очень дорогой способ сделать нежизнеспособный продукт.
Во всех случаях общение заказчика и исполнителя всегда желательно отображать в документальной форме. Как бы ни старался заказчик сформировать суть чего он хочет получить в конечном счете, как показывает практика, исполнитель подвержен тому, что что-то он все-таки обязательно сделает не так, как ожидал заказчик, или что может быть на много хуже, не сделает того именно через отсутствие четких требований. Ибо как говорится "есть возможность не делать чего-то, не делай", потому как - инициатива наказуема.
В разработке информационных систем и в частности сайтостроении правильное ТЗ является чуть ли не залогом успеха на всех стадиях.
В технических ВУЗах часто пытаются прививать способность требовать щепетильного анализа на этапе проектирования, чтобы было описано все до малейших деталей. Очень часто сопровождаемо присказкой "как корабль назовешь - так он и поплывет". Но как обычно,большинство путает ТЗ и сам по себе технический проект.
Технический проект - это документация на уже сформированный продукт (на этапе проектирования), который требует основательного описания всех имеющихся возможностей и свойств продукта, а также описания процессов создания.
Техническое задание - это описание того, как желательно сделать продукт и по факту техническое задание подвержено и изменениям в процессе проектирования, и в процессе создания продукта. Что больше чем всегда случается с информационными системами.
Грубо говоря, по техническому проекту можно клонировать продукты, а тз - это частный вариант технического проекта, когда все нужно делать по месту.
Естественно, что при создании информационных продуктов можно ориентироваться на технические проекты. Но в данном случае, при грамотно составленном проекте и достаточной детализации - он будет напоминать некоторый псевдокод, который должен адаптировать программист в среде программирования. Требования к программисту в таком случае минимальные. Он должен уметь на уровне курса школьной информатики отобразить в коде весь функционал. Но тогда проектировщик должен быть универсальным специалистом/менеджером - который сможет если не спроектировать все сам, то хотя бы проанализировать и скомпоновать информацию от многих профилированных исполнителей при проектировании. Здесь нужно заметить что все это требует немалых не только усилий, но достаточного времени, что может, при определенной сложности затянуться если не на месяцы, то на годы точно. Но тогда есть риск, что в процессе создания технического проекта технологии будут устаревать, не успев реализоваться в готовом продукте.
Итак, ТЗ - это грамотно составленное изложение требований заказчика исполнителю. Процесс создания можно разложить на такие этапы
- Формулирование концепции
- Озвучивание заказчиком своего желания
- Анализ желаний на предмет их возможной реализации
- Уточнение требований
- При появлении новых пожеланий к п.3
- Описание модели и взаимодействий
- Прототипирование
- Детализирование
В данном случае эти все понятия являются категориями из юридической плоскости. он будут уместны в договоре рядом с суммами.
Для более реального случая можно рассмотреть ТЗ на создание сайта по сдачи жилья в аренду.
Концепция
Создать сайт по сдаче жилья в аренду. Пользователи вносят в базу данных данные о жилье для сдачи или резервируют съем на определенный срок. Модераторы сайта управляют пользователями, объявлениями.В большинстве случаев этот этап проходит полностью на стороне заказчика. Его суть - сформировать абстрактное понимание чего все хотят в конечном счете. Из документов можно отложить только фотоснимки набросков на доске или бумаге сделанных от руки.
Озвученные требования
- Платформа выделенный сервер с Apache 2.2, PHP 5.3 и MySQL.
- Объявления подают и резервируют только зарегистрированные пользователи. (Приложение - Список полей со свойствами пользователей - ФИО, адрес, телефон, почтовый адрес, юридический адрес и тд. )
- Объявления могут быть - бесплатные, приоритетные (оплаченные), скрытые. (Приложение - Список полей со свойствами объявлений - квартира/дом, этажи, площадь, район, адрес, количество комнат/спален, наличие гаража/сауны/бассейна и тд.)
- Отчеты - формирование при подаче объявления, раз в неделю, раз в месяц - доступны только модераторам (Приложение - Форма "количество поданных объявлений за период", Форма "Список резервирований за период", форма "Список пользователей", Форма - "Список обработанных платежей").
- Оплата по PayPal.
- Готовый дизайн или возможный дизайн (если нужно сделать похожим на что-то)
Чем более точно специализированный консультант, тем более шире можно будет охватить все свойства элементов. Ключевым моментом является категорическое отсутствие специалистов из области создания сайтов или каких-либо неквалифицированных специалистов типа IT-консультантов. Это позволит избежать излишней детализации и бюрократии в процессе согласования.
По возможности нужно стараться не прерывать цепочку:
тех.-специалист(ы) заказчика <-> менеджер по работе с исполнителем <-> менеджер по работе с заказчиком <-> команда исполнителей
Анализ требований
В данном случае конечно же требования гипотетического заказчика просто идеальные. Поскольку акцент поставлен на продукт, а не на процесс. Исходя из того что хочет получить заказчик, исполнитель может предложить варианты реализации- Сделать практически статические страницы с примитивной динамикой на основе структурного кодирования. Практически без возможности масштабирования. В большинстве случаев - это уровень студента ищущего подработок с целью освоить программирование. Он конечно назовет это персональным подходом без использования шаблонов и пообещает выразительность на фоне других. Очень часто бывает что заказчику именно это и нужно, и поэтому нет нужды городить супермасштабируемые проекты, которые только будут "жрать" ресурсы. Цена вопроса - практически пропорциональна затраченному времени, как и ожидается минимальная.
- Сделать сайт на основе готового движка или адаптировать с минимальной доработкой. В целом тоже один из наименее затратных вариантов, хотя не всегда готовые "движки" позволяют сильно перекроить оформление чтобы соответствовать п.6 требований заказчика. Хотя возможность масштабирования и наличие основных скрытых деталей сильно упрощает последующее согласование.
- Сделать сайт на основе модульной структуры, по сути создать свой движок, который в будущем можно будет масштабировать и добавлять функционал. Это будет наиболее дорогостоящий и затратный по времени процесс. Хотя часто некоторые веб-студии представляют свой готовый уникальный движок.
Уточнение требований
В данном этапе очень правильно со стороны исполнителя согласовать такие участки- Нужно ли обслуживать сессии
- Будут ли экспортироваться данные из базы в файлы или только отчеты - от этого зависит какие поля можно использовать в таблицах
- Где и как хранить файлы изображений
- Система подтверждений - через электронную почту или капчи. В таком случае согласовать формат и содержание писем, или разработать редактор шаблонов писем.
- Какие сторонние протоколы подключить - OAuth2, авторизация и публикация через соцсети, переводчики.
- Как будет тестироваться наполнение - с готовой базы/таблицы, или вручную, или нужно написать отдельный модуль тестер.
Описание модели и прототипирование
Этот этап практически уже начало создания продукта. Уже здесь можно увидеть как он будет выглядеть. Для того, чтобы избежать ситуации, когда в ТЗ пишут о том как надо писать, по факту впадают в рекурсию, нужно находить время для прототипирования.Это может выглядеть как создание временно статических страниц с воспроизведенным заказанным дизайном или текстовые страницы, на которых реализована логика обработки.
Возможно потребуется формирование временных данных на основе генератора.
Создание тестовых баз и тестовых подсистем очень сильно помогают не нагромождать абстрактную документацию без ее реализации.
Всегда нужно разделить процесс на потоки - дизайн/оформление, логика обработки основных данных, обслуживающая логика системы.
Детализирование
Процесс создания таких продуктов как сайт или любое другое техническое решение в среде информатизации подвергается постоянному уточнению.Существует множество методологий при сопровождении проектов таких как - scrum, agile, RAD, XP и др., которые приветствуют разработку на коротких циклах, при постоянном контроле и тестировании.
На отмену от "Каскадной модели" суть которой сводится к диаграмме:
Требования ->
Проектирование ->
Реализация ->
Тестирование ->
Эксплуатация
любой из выше приведенных методов более приемлем. Процесс построения домов, мостов, механизмов не сильно изменился за последние тысячелетие. Возможность что-то изменить после построения, особенно на ранних этапах - очень трудоемкий и затратный на отмену от информационных систем. Поэтому водопадная модель и является основной в домостроительстве и машиностроительстве. Но она практически неприменимая в строительстве сайтов. Здесь нужно учитывать, что браузеры и платформы сменяют друг-друга очень часто. В большинстве случаев это связано с безопасностью. Но часто и через конкуренцию для поддержания как можно больше новых технологий.
Линейное/структурное программирование в 90-х было замещено объектно-ориентированным. Объектно-ориентированное в конце 90-х обрело шаблоны проектирования, каркасное проектирование, что позволяет на порядок увеличить и скорость разработки и сложность, параллельно расширяя функциональность и масштабируемость.
Поэтому игнорирование современных инструментов и технологий очень дорогой способ сделать нежизнеспособный продукт.
Комментариев нет:
Отправить комментарий