С чего начинается любой проект. С понимания того, что это и зачем это нужно. Записывая свои мысли, мы лучше их понимаем. Если мы не понимаем к чему идем, то не придем к этому. И уж тем более не приведем других участников проекта, если будем полагаться на память и устное понимание партнеров по проекту.
Очень важно описать задачу таким образом, что бы ее поняли все, кто принимает участие в реализации проекта. «Понимаем» в данном случае ключевое слово. Есть интересный прием для того, что бы объяснить людям, что понимание самим собой задачи очень далеко от успеха проекта, т.к. другие участники проекта могут думать совсем по другому.
НЕГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«МЕЖДУНАРОДНАЯ АКАДЕМИЯ БИЗНЕСА
И НОВЫХ ТЕХНОЛОГИЙ (МУБиНТ)»
Кафедра информационных технологий
Проектирование экономических информационных систем
Реферат на тему: Описание постановки задачи.
Выполнил: студент группы 1ЗБ3 ПИ-31
Правильная постановка задачи
Глебов Андрей Геннадьевич
(Ф.И.О., подпись студента)
Преподаватель:
(должность, учёная степень)
Вейцман Владимир Моисеевич
С чего начинается любой проект. С понимания того, что это и зачем это нужно. Записывая свои мысли, мы лучше их понимаем. Если мы не понимаем к чему идем, то не придем к этому. И уж тем более не приведем других участников проекта, если будем полагаться на память и устное понимание партнеров по проекту.
Очень важно описать задачу таким образом, что бы ее поняли все, кто принимает участие в реализации проекта. «Понимаем» в данном случае ключевое слово. Есть интересный прием для того, что бы объяснить людям, что понимание самим собой задачи очень далеко от успеха проекта, т.к. другие участники проекта могут думать совсем по другому.
Например: перед людьми ставиться задача «Представьте себе собачку». Дается пара минут для того, что бы каждый мог вообразить себе образ, а потом начинается опрос. Казалось бы простейшее задание не должно вызывать разногласий, но в результате мы услышим описание лаек, овчарок, водолазов и т.д. и т.п. Но самое интересное наступит тогда, когда мы скажем, что имели ввиду собачку на замке типа молния. Этот пример очень наглядно демонстрирует необходимость тщательное описания и согласования задачи перед тем как приступать к ее реализации.
Появляется необходимость составления документа под таким известным названием «Техническое задание» или «Постановка задачи». Основная суть этого документа — понимание всеми участниками проекта конечных целей и пути их достижения.
Первый этап составления такого документа — это описание целей задачи. Записывая цели заказчик начинает продумывать то, что он хочет получить от проекта. Описав свои цели, нужно подключать технического специалиста. По указанным целям специалист составляет описание модели реализация, которой должна привести к поставленным целям.
Описывая задание во первых специалист показывает как он понял поставленные перед ним цели и когда заказчик будет читать описание действий для реализации его целей он также вникнет в техническую суть дела и поймет из чего складывается стоимость проекта. Еще два дополнительных плюса при описании задачи, это во первых описанные в начале цели являются чек-листом для проверки результата, а вторых, что пока будет реализовываться проект ни кто не забудет с чего все это началось и зачем все это надо.
ТОП 4 ПРИЛОЖЕНИЯ Для Продуктивности, Постановки Задач, Личных Финансов и Чтения Книг!
Резюмируя вышесказанное можно написать следующее:
1. Описывая цели мы сами лучше их понимаем.
2. Записанные цели никогда не будут забыты.
3. Записанные цели можно использовать для проверки решения.
4. Согласовывая цели с другими участниками проекта записывая решение языком специалистов все приходят к взаимопониманию, что от них требуется.
5. В результате такой работы «Техническое задание» будет сформулировано само собой.
Постановка задачи — точная формулировка условий задачи с описанием входной и выходной информации.
Входная информация по задаче — данные, поступающие на вход задачи и используемые для её решения.
Выходная информация может быть представлена в виде документов, кадров на экране монитора, информации в базе данных, выходного сигнала устройству управления.
Постановка задачи разрабатывается организацией, разработчиком программной продукции, на основании технического задания совместно с заказчиком. Главный исполнитель — это разработчик
На этапе постановки задачи раскрывается организационно-экономическая сущность задачи:
- формулируется цель ее решения
- определяется взаимосвязь с другими задачами
- указывается периодичность ее решения
- раскрывается состав и форма представления входной, промежуточной и выходной информации
- характеризуются формы и методы контроля достоверности информации
- описываются формы взаимодействия пользователя с ЭВМ
Особое внимание уделяется детальному описанию входной, выходной и промежуточной информации.
При этом определяется:
- форма представления отдельных данных
- количество знаков, выделяемых для записи данных, исходя из их максимальной значности
- источник возникновения данных
Кроме того, для цифровой информации указывается:
- целочисленный или дробный характер данных (для дробных указывается количество 10-х знаков) и допустимый диапазон изменения величин.
Завершается постановка задачи описанием контрольного примера, демонстрирующего порядок решения задачи традиционным способом.
Основное требование к контрольному примеру — это отражение всего многообразия возможных форм существования исходных данных.
Пользователь хорошо знает проблемную сторону задачи, но обычно слабо представляет, как она будет решаться на ЭВМ.
Предметная область пользователя часто незнакома программисту, поэтому необходима полная корректная постановка задачи, однозначно понимаемая пользователем и разработчиком.
Построение математической модели объекта — на этом этапе производится анализ и исследование задачи.
- Анализ существующих аналогов задачи.
- Анализ технических и программных средств.
- Разработка математической модели.
- Разработка структур данных.
Естественный язык, на котором осуществляется постановка задачи, имеет свойство неоднозначности. Создание математической модели позволяет формализовать описание задачи. При этом устанавливается и формируется средствами языка математики логико-математической зависимости между исходными и результатными данными.
Математическая модель — это система математических соотношений (формул, уравнений, неравенств и т.д.), отражающих существенные свойства объекта или явления.
Математическая запись постановки задачи отличается высокой точностью отображения ее сущности, лаконичностью записи, однозначностью понимания, но она может быть выполнена не для всех задач.
При выборе метода решения предпочтение отдается методу, который:
- Обеспечивает необходимую точность и не обладает свойством вырождения (бесконечного зацикливания).
- Позволяет использовать уже готовые стандартные программы.
- Ориентирован на минимальный объем информации.
- Наиболее быстрое получение результатов.
План написания постановки задачи (ПЗ).
- Наименование задачи.
- Назначение.
- Достигаемая цель.
- Для кого предназначена.
- Технические средства.
- Периодичность использования.
- Входная информация.
- Выходная информация (формируется по запросам).
- Метод проверки правильности (сравнивается с контрольным примером).
- Организация внедрения задачи.
- Разработка контрольного примера (входная информация с конкретными данными, выходная информация).
- Методы защиты.
Результатом работы на стадии постановки задачи является документ «Описание постановки задач», требования к содержанию которого регламентируются ГОСТ 24.204-80*
Список используемой литературы:
1. «Проектирование экономических информационных систем» Г.Н.Смирнова, А.А.Сорокин, Ю.Ф.Тельнов; М.: Финансы и статистика; 2003
2. «Проектирование информационных систем» В. И. Грекул, Г. Н. Денишенко, Н. Л. Коровкина; М.: Интернет-Ун-т Информ технологий; 2005
3. «Информационные системы в экономике» Под ред. Г.А.Титоренко; 1-е издание — ЮНИТИ, 1998
4. ГОСТ 24.204-80* «Требования к содержанию документа описание постановки задачи»
Источник: www.myunivercity.ru
Как правильно поставить задачу по IT-проекту и не потопить его с самого начала
”Поди туда-не знаю куда, принеси то-не знаю что…” — сказ о том, зачем нужно Техническое Задание, чем оно отличается от технических требований, и нужно ли за него платить.
Большинство организаций имеют сложности при постановке задачи разработчикам сайтов и мобильных приложений (назовем так для упрощения ИТ-компании, работающие в сфере создания онлайн-проектов).
Проблема в том, что пользователями сайтов и приложений являются все, а подводную часть многие не понимают. Это как тот самый айсберг, который на 90 процентов спрятан под водой. Не учитывать этого — значит потопить весь проект.
Попробуйте поставить задачу или сделать проект для разработки автомобиля или постройки даже небольшого дома. Это очень непросто.
Каждый проект индивидуален, требует разной степени детализации при разработке задания и вообще, это большая сложная, скучная и рутинная работа.
В лучшем случае, можно сформулировать пожелания общего характера. Не может человек, который сам не является специалистом в нужной области, знать все нюансы технологий и процессов, тем более, что технологии меняются каждый год.
Для этого человечество придумало писать формализованные (письменные, по шаблонам и стандартам) технические задания. Чтобы ожидания в начале проекта совпадали с реальностью после его завершения.
Техническое задание выполняет две основные функции:
- Точно определяет объем работ и позволяет оценить его стоимость и сроки
- Является инструментом приемки проекта (все, что написано в ТЗ, должно быть выполнено именно так, как написано)
Десятки, а может уже и сотни миллионов онлайн-проектов приучили индустрию лишь к тому, что техническое задание должно быть, но как его написать — нет одинакового мнения. К тому же каждый проект индивидуален, требует разной степени детализации при разработке задания, и вообще, это большая сложная, скучная и рутинная работа.
Дизайнеры для упрощения пишут брифы с вопросами, разработчики типовых шаблонных сайтов просят привести примеры понравившихся сайтов, чтобы хоть что-то вытащить из клиента.
При этом разработка технического задания требует квалификации достаточно высокой, такой же, как профессия архитектора и проектировщика в строительной индустрии. Очень грубо можно привести аналогию:
Дизайнер в ИТ = Архитектор в строительстве
Аналитик (аналитик требований, бизнес аналитик) = Конструктор
Однако никому не приходит в голову садиться за компьютер и нарисовать проект полностью самому, это большой труд, требующий квалификации и опыта. Этот труд стоит соответствующих денег. В строительстве проектирование — это 5–10% от стоимости объекта, в ИТ стоимость ТЗ может достигать 15% от общего бюджета.
В практике отрасли информационных технологий, к сожалению, крайности часто случаются — от «вот вам Техническое задание (на 2–3 страницах), делайте» до «напишите задание сами, вы же профессионалы. А мы посмотрим и примем решение, работать с вами или нет». Все сегодня разбираются в политике, футболе и информационных технологиях ).
Вот как выглядят этапы подготовки требований на практике:
Здесь можно провести аналогию по этапам. Берем пример, когда онлайн-проект реализуется по водопадной модели, а не по методологии гибкой разработки, планируемой итерациями. Рассматриваем проекты стоимостью до 3–5 миллионов рублей и длительностью от 3 до 12 месяцев (да-да, исходя из написанного выше, стоимость разработки ТЗ может составлять 300–600 тысяч рублей).
ЧАСТЫЕ ВОПРОСЫ И ЧЕСТНЫЕ ОТВЕТЫ
Естественным образом у клиентов возникают вопросы, на которые можно дать профессиональный ответ:
Может ли Клиент выполнить все этапы разработки требований самостоятельно?
Нет, не может. Даже если очень подробно описать все требования, все равно остается необходимость в описании сугубо технических моментов и методов реализации.
Может ли Клиент не платить за ТЗ?
Нет, не может. Даже если формально Исполнитель, пытаясь привлечь Клиента, говорит, что сам напишет ТЗ бесплатно, то все равно стоимость его разработки (а она может быть существенной) ложится в себестоимость проекта. Но при этом весь риск берет на себя Исполнитель, и это нехорошо, прежде всего, для Заказчика! Потому что у Исполнителя нет никакой ответственности за то, что он делает.
Бывают ли успешные проекты без написания ТЗ?
Бывают. Если проект очень простой (1 страница на 1 экран с формой подписки, требований к дизайну нет), или Исполнитель делал абсолютно аналогичный проект, либо используются только уже готовые решения. Но в этом случае Заказчик должен быть готов согласиться с этими решениями и довериться Исполнителю на 100%. Таких проектов немного, большинство из них типовые.
Можно ли оценить стоимость проекта без ТЗ?
Можно. Но точность оценки будет невысокой. Итоговый проект может отличаться от первоначально названной стоимости в разы. Более того, если вы покажете ваши технические требования разным Исполнителям, то разброс в ценах может составлять 3–10 раз!.
Это происходит из-за того, что подводная часть онлайн проектов может быть реализована очень по-разному, и какие реально работы Исполнитель оценивает, прочитав только Техтребования, непонятно. И каждый Исполнитель будет по-своему прав, просто он читает документ и сам себе дорисовывает в голове подводную часть айсберга! Чтобы сравнивать круглое с круглым, а зеленое с зеленым, нужно писать Техническое задание.
Можно ли сделать ТЗ, а потом уйти к другому разработчику?
Можно. Если вы платите за Техническое задание, то оно должно быть конечным продуктом, который можно показать нескольким разработчикам. У них при этом не должно возникать существенных вопросов по оценке стоимости проекта. Таким образом, вы можете получить адекватную оценку подробно описанной задачи и сравнить сравнимое.
Чем я рискую, если начну проект без ТЗ?
Вы рискуете не сделать проект. В некоторых случаях дело не доходит даже до разработки, так как непонятно, что конкретно нужно делать. Реализация проекта по типу «Придумай сам, как это должно работать» с вероятностью в 95% приведет к неудаче. Сроки затягиваются, все нервничают, проект стоит.
Вы рискуете деньгами. В нашей практике были случаи, когда в процессе написания ТЗ становится понятно, что проект должен выглядеть совсем по-другому и стоит совершенно других денег, нежели имеется у Клиента в наличии. Без подробного задания началось бы непрерывное вливание денег в разработку, заранее обреченную на неудачу.
ПРИМЕР
В качестве иллюстрации приведем максимально короткий пример, очень упрощенный, который показывает эволюцию требований от этапа к этапу.
КОНЦЕПЦИЯ НА САЛФЕТКЕ
ГЛАВНЫЕ ВОПРОСЫ: О ЧЕМ ПРОЕКТ?
- Цель проекта
- Принципиальный механизм решения
- Рисунок/схема с потоками информации от пользователей к системе и обратно
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
ГЛАВНЫЕ ВОПРОСЫ: ЧТО НУЖНО СДЕЛАТЬ? КАК ЭТИМ ДОЛЖНЫ ПОЛЬЗОВАТЬСЯ?
- Общее описание целей
- Какие задачи должен решать проект, какие показатели он должен изменить (технические)
- На кого проект ориентирован (пользователи с какой квалификацией будут им пользоваться)
- Требования к внешнему виду (дизайну)
- На каких платформах он должен работать
- С какими системами проект должен быть интегрирован (автоматически получать или передавать данные)
- Требования к функциям системы
- Требования к ролям пользователей
- Требования к безопасности системы
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
ГЛАВНЫЕ ВОПРОСЫ: КАК НУЖНО СДЕЛАТЬ? КАК СИСТЕМА ДОЛЖНА РАБОТАТЬ?
Типовая структура Технического задания верхнего уровня для относительно небольшой информационной системы (ИС):
- Общие сведения об ИС
- Назначение и цели ИС (Требования к системе в целом)
- Версии ИС (Веб-версия и другие)
- Типы страниц и элементов страниц сайта (Описание основных функциональных страниц и ключевых элементов)
- Типы (роли) пользователей (Структурированное описание всех ролей: пул возможностей и ограничений)
- Пользовательские сценарии (User story: кто и каким образом взаимодействуем со всем функционалом сайта)
- Структура данных (Клиенты, субъекты инфраструктуры и прочее)
- Дерево ИС
- Функциональные требования к ИС
- Нефункциональные требования к ИС
- Требования к интеграциям
- Архитектура ИС
- Эргономика и техническая эстетика (Макеты визуальной составляющей системы и прочее)
- Требования к дизайну
- Требования к тестированию
- Этапы работ по созданию ИС
- Порядок контроля и приемки ИС (Критерии завершенности разработки и прочее)
- Дальнейшая поддержка продукта
ВЫВОДЫ
- Разработка ИТ-системы, в том числе сайта, мобильного приложения или специализированного сервиса (например CRM-системы или системы бронирования) очень похожа на строительство дома. Сначала идея, общее описание, потом требования и ограчения, потом проектные решения, потом реализация, потом запуск и тестовая эксплуатация.
- Нельзя игнорировать этап проектирования (технического задания для ИТ). При стоимости 10–15% от стоимости всего проекта качественное ТЗ позволит избежать большого количества проблем и, в итоге, сократить сроки и стоимость разработки.
- Не пытайтесь сделать Техническое задание самостоятельно, чтобы сэкономить. Но при этом всегда делайте максимально подробные технические требования, чтобы ускорить проект.
- При приемке ТЗ читайте его таким образом, чтобы можно было представить, как вы будете проверять работающую систему на предмет выполнения ТЗ: все пункты должны быть сформулированы четко и однозначно, напротив каждого — вы потом будете ставить галочку о выполнении.
- После разработки подробного Технического задания вы можете отдать его на обсчет проекта в несколько разных компаний, чтобы корректно сравнить цены. На этом этапе уже разброса на порядок быть не должно.
ПРИЛОЖЕНИЕ
Для тех, кто хочет глубже разобраться в вопросе, приведем пример преобразования Концепции сначала в Технические требования, а затем в Техническое задание.
ПРИМЕР ПРЕОБРАЗОВАНИЯ ОДНОЙ ФУНКЦИИ СИСТЕМЫ
Приведем пример формулировок задачи на разных этапах, на которых можно отследить их эволюцию: увеличение сложности и глубины осмысления задачи.
КОНЦЕПЦИЯ
Как звучит первоначальная постановка задачи:
“В систему вносится информация о результатах матчей и протоколы матчей, а система должна автоматически обновлять данные в турнирных таблицах”
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
Когда специалисты начинаю детализировать задачу получается уже следующее описание:
В систему вносится информация о результатах матчей и протоколы матчей, а система должна автоматически обновлять данные в турнирных таблицах и расставлять команды в таблице в соответствии со следующими критериями: личная встреча, разница-мячей, количество побед.
- Должна быть реализована настройка изменения порядка применения критериев
- В турнирной таблице должны быть реализованы механизмы сортировки по любым столбцам
- Система должна работать на всех основных мобильных платформах
- Ввод данных в систему должны осуществлять только пользователи с правами администратора турнира путем внесения электронных протоколов
- Система должна иметь возможность забирать данные из сторонних сервисов (например SportRadar или BetRadar)
- Система должна иметь функцию выгрузки турнирной таблицы на любой сторонний сайт (виджет)
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Когда проект передается Исполнителю, он начинает задаваться вопросом “Как я это буду делать?”, и возникает существенно бОльшая детализация задачи:
(упрощено для экономии времени читателей)
1) Система должна автоматически обновлять данные в турнирных таблицах и расставлять команды в таблице в соответствии со следующими критериями: личная встреча, разница мячей, количество побед.
— Должна быть реализована настройка изменения порядка применения критериев.
- Описание конечного перечня критериев
- Макет экрана настроек изменения порядка сортировки
- Описание метода изменения порядка сортировки (на сервере или на компьютере клиента)
- Ограничения по доступности изменения порядка сортировки (если турнир завершен, например)
— В турнирной таблице должны быть реализованы механизмы сортировки по любым столбцам.
- Конечный перечень столбцов, по которым необходимо проводить сортировку
- Механика поведения таблицы при нажатии на заголовки столбцов (сначала по алфавиту в прямом порядке, потом в обратном)
- Технология обновления данных (на сервере или на стороне пользователя)
- Поведение системы, если по выбранному критерию сортировки данные идентичные (вторичная сортировка)
— Система должна работать на всех основных мобильных платформах
- На каких платформах должна работать, при каких разрешениях
- Описание поведения системы и отображения данных для различных разрешений экрана и расположений (вертикальное/горизонтальное)
- Макеты страницы с турнирной таблицей для разных платформ
- Отличие в поведении таблиц при сортировке для разных платформ и разрешений экранов
— Ввод данных в систему должны осуществлять только пользователи с правами администратора турнира
- Описание механизма создания пользователей и их ролей
- Описание механизма назначения администраторов для турнира
- Ограничения по назначению администраторов турниров (максимальное количество, одновременные роли в турнире)
- Макеты страниц на которых производится создание пользователей и назначение администраторов
- Макет страницы турнира, на которой отображаются все администраторы турнира
— Система должна иметь возможность импортировать данные из сторонних сервисов (например SportRadar или BetRadar)
- Конечный перечень сторонних сервисов, из которых могут забираться данные
- Формат данных, в которых Система должна забирать информацию из каждого сервиса (описание всех полей)
- Описание процесса подключения импорта данных
- Тип импорта данных (разовая загрузка по требованию или автоматический фоновый импорт через xml-файл из определенного места на сервере)
- Описание механизма решения конфликтных ситуаций при импорте данных
- Структура базы данных (схема) с описанием полей, в которые импортируются данные
- Макет интерфейса для настройки импорта данных
— Система должна иметь функцию выгрузки турнирной таблицы на любой сторонний сайт (виджет)
- Описание возможных настроек выгрузки таблицы (заголовки, цвета, шрифты, размеры, краткая/полная форма таблицы, ширина/высота и т.д.)
- Макет интерфейса выгрузки таблицы на сайт с описанием настроек
- Макет визуализации виджета на стороннем сайте
- Роли, для которых такой функционал доступен
- Методы вставки виджетов на сайт (формат кода, необходимые теги, описание ограничений)
- Описание механизма обновления данных на сторонних сайтах (периодичный, по загрузке страницы, по внесению данных в Системы и т.д.)
- Кроме этого, Техническое задание включает в себя описание процедуры тестирования каждой функции, взаимосвязи с другими функциями системы, описание правил безопасности и еще большое количество сервисных требований, выполнение которых делают систему надежной и удобной.
Источник: sportsoft.ru
Как правильно ставить задачи программистам
Существует расхожее мнение, что программист по умолчанию знает все: с закрытыми глазами ориентируется в незнакомом проекте, бегло читает и сразу же компилирует в голове любой впервые увиденный код, а также умеет на основании очень краткой формулировки детально понять все требования к реализации, заложенные постановщиком задачи. В самом деле, почему бы и нет — он ведь в конце концов программист!
Здесь и кроется основная сложность во взаимодействии и взаимопонимании между постановщиком задачи и ее исполнителем. С точки зрения того, кто формулирует требования к реализации, все может быть более чем очевидно, поскольку типовые сценарии поведения пользователя на его сайте, сервисе и т. п. ему хорошо известны. В то же время исполнитель, получивший задание на реализацию предъявленных требований, вполне может таким пониманием не обладать. Здесь можно возразить: мол, сайты и сервисы одинаковой направленности (например, интернет-магазины), да еще и функционирующие на одинаковой платформе, предполагают схожие модели поведения пользователя, поэтому, казалось бы, и правда все должно быть понятно с полуслова.
Однако важно не забывать: стопроцентно типовых проектов не существует, разве что примитивные сайты — визитки, да и в них чаще всего можно найти какую-то степень индивидуальности. Сложный же продукт — интернет-магазин, корпоративный портал — за время своей жизни неизбежно обрастает огромным объемом присущего только ему функционала, причем очень часто этот нетиповой функционал состоит из кода, написанного далеко не лучшим образом.
Рассмотрим несколько абстрактных интернет-магазинов. В одном из них разрешено оформление заказа для неавторизованного посетителя, в другом — не разрешено, третий же в процессе оформления заказа производит автоматическое создание учетной записи пользователя, да еще и с «теневой» подпиской на рассылку рекламных предложений.
В одном из магазинов информация о товарах и ценах автоматически обновляется в ходе периодического обмена данными с системой управления торговлей, в другом товары создаются и редактируются вручную, в третьем вообще импортируются из таблиц Excel с помощью специально созданного для этой цели скрипта. В магазине одежды или обуви покупатель должен выбрать размер и цвет приобретаемого товара (такие сочетания в ряде «движков» интернет-магазинов именуются торговыми предложениями), магазин бытовой техники, как правило, предлагает к своим товарам ряд расширенных программ гарантийного и постгарантийного обслуживания, магазин электроинструмента посоветует одновременно с перфоратором приобрести подходящие для него буры, зубила и пики. Один магазин предоставляет только почтовую доставку и самовывоз, тогда как другой способен определять местоположение покупателя и на основании этих данных рассчитать стоимость доставки курьерской службой. Где же среди всего перечисленного затерялся тот самый типовой, общий для всех набор функций, присущий всем этим магазинам, так сказать, «из коробки»?
Кроме того, следует учитывать, что любой веб-проект представляет собой довольно-таки слабо связанную систему. Любой раздел сайта, практически любую стороннюю библиотеку, как правило, можно изъять из проекта самым грубым образом, не наблюдая при этом каких-то фатальных последствий. Все сломается лишь в случае непосредственного обращения к отсутствующему разделу или библиотеке.
Другими словами, в огромном количестве веб-проектов отсутствует хотя бы элементарное описание зависимостей, не говоря уже об автоматическом контроле наличия всех необходимых программных составляющих. Также отсутствует и какая-либо документация. Поэтому нередки ситуации, когда проект находится на поддержке уже не первый год, но при этом какая-то отдельно взятая функция за все это время ни разу не была затронута. Соответственно, несмотря на длительный срок поддержки, именно об этой функции, скорее всего, ничего неизвестно, поскольку с прочими частями проекта она никак не взаимодействует. И если владелец проекта внезапно решит, что для этой обособленной функции назрела необходимость доработки, для программиста, имеющего солидный опыт на проекте код этой функции окажется совершенно незнакомым.
Из всех приведенных рассуждений и вытекает взгляд исполнителя на постановку задачи. Задача, сформулированная очень лаконично («нужно сделать, чтобы вот там-то стало вот так-то») в абсолютном большинстве случаев вызовет огромное количество встречных вопросов. Также нередки случаи, когда задача поставлена, на первый взгляд, довольно развернуто, подробно описана проблематика, приведены примеры, но беда в одном: все перечисленное изложено исключительно с точки зрения человека, находящегося в контексте бизнес-процессов проекта, для которого проблема очевидна. Для программиста задача, поставленная исключительно с точки зрения бизнес-процессов, как правило, малопонятна.
Пример: поступила задача со следующей формулировкой «На примере набора иллюстрирую проблему. Данный набор состоит из: — XXX руб, — YYY руб, сумма по ценам отдельных комплектующих = XXX + YYY = ZZZ руб. А цена набора — XYZ руб. Как можно решить данную проблему?
Т.е. мы предлагаем более привлекательные цены клиентам, если они берут наборы, а не товары по отдельности.» Проверка, проведенная исполнителем, показала, что сайт показывает цены верно: за товар 1 XXX руб, за товар 2 YYY руб, за набор — XYZ руб, что меньше суммарной цены двух товаров. Появляется вопрос — в чем состоит проблема? Вероятно, для заказчика она более чем очевидна и прямо вытекает из приведенных ценовых выкладок. Но для программиста очень полезной оказалась бы информация о том, что заказчик ожидает получить на выходе, после решения заявленной задачи. Другими словами, в тексте постановки задачи приведен пример с конкретными товарами, но никак не разъясняется ожидаемый конечный результат.
Рассмотрение постановки задачи, попытки определить модели поведения пользователя, взаимодействующего с требующим доработки инструментом, выявление неясных или двояко толкуемых моментов — это тоже время, затрачиваемое на работу по задаче. Составление и согласование детальных требований, написание технического задания — снова время. И время, затраченное на достижение понимания, что именно скрывается за первоначальной формулировкой, неизбежно будет включено в общую трудоемкость выполнения задачи, поскольку это тоже часть работы, причем нередко наиболее сложная ее часть.
Грамотно поставленная задача способна минимизировать продолжительность подготовительного периода и максимально быстро приступить к оценке и непосредственному выполнению. Само собой, полностью избежать подготовительного периода невозможно и чем масштабнее запрошенная доработка, тем большего периода подготовки она требует. К особо крупным работам невозможно приступить, не имея под рукой утвержденного заказчиком ТЗ, в противном случае работа погрязнет в бесконечной вариативности. Тем не менее, качественная постановка даже крупной задачи позволит составить весь стартовый набор документов с гораздо меньшими трудозатратами, чем если первоначальная формулировка вызовет больше вопросов, чем понимания цели доработки.
Какой же способ постановки задач с нашей точки зрения можно назвать качественным? Человек, формулирующий задачу, для себя уже уяснил, какова цель доработки, какие проблемы предстоит решить с ее помощью.
Для исполнителя, чтобы достигнуть сравнимой степени понимания, весьма полезной будет информация о том, как именно функционирует условный предлагаемый к доработке инструмент на текущий момент, к каким результатам приводит его работа, а также что в этих результатах предполагается изменить. Далее, если работа функционала связана с какой-то визуальной частью, элементами интерфейса, с которыми пользователь взаимодействует в процессе работы, нелишне проиллюстрировать процесс работы с инструментом поэтапно, выделив на скриншотах ключевые операции.
Это позволит составить представление об ожидаемом пользовательском сценарии взаимодействия с инструментом. Как вариант, можно сопроводить задачу непосредственно самим пользовательским сценарием, в котором по пунктам перечислить состав действий пользователя, причем если в ходе доработки сценарий изменится, разумно привести как исходный, так и целевой сценарии. В завершение следует детально изложить ожидаемый результат работы функционала, либо ожидаемый вид страницы после доработки. Такие сведения существенно помогут по завершении убедиться, что доработка проведена правильно.
Пример грамотной постановки задачи: «В настоящий момент на странице корзины работает следующая логика: в момент загрузки страницы проверяется общая сумма товаров и на основании этого устанавливается тот или иной обработчик нажатия кнопки “оформить заказ”; в случае изменения количества позиций (и как следствие — изменения общей суммы заказа) функционал нажатия кнопки «оформить заказ» никак не меняется; требуется поставить работу кнопки «Оформить заказ» в зависимость от текущей итоговой суммы заказа без перезагрузки страницы». Как нетрудно видеть, подробно изложена текущая ситуация и, что особенно важно, разъяснена ожидаемая цель задачи. Такая формулировка вызовет минимум недоумения и встречных вопросов даже у человека, впервые увидевшего данный проект.
Приведенная методика постановки задач может показаться излишне трудоемкой, однако в конечном итоге она позволяет сэкономить время исполнителя, а значит и деньги заказчика.
Источник: maximaster.ru