Как правильно написать задачи в программе

Задачи проектной работы – этапы, которые нужно выполнить для достижения цели, поставленной при работе над проектной работой, включая как теоретическую, так и практическую часть.

Задачи во введении проектной работы

Задачи в проектной работе должны вытекать из поставленной цели и дополнять её так как они отражают выбранные пути для решения поставленной цели.

Особенности подготовки задач проектной (исследовательской) работы

Рассмотрим особенности подготовки задач в проектной работе:

1. Задачи проектной работы формируются после постановки цели и описывают, что конкретно необходимо будет сделать для её достижения.
2. Задачи всегда указываются во «Введении» после цели.
3. Количество задач должно соответствовать количеству параграфов в проектной работе, каждый параграф – это отдельная задача.
4. Задачи в проектной работе всегда необходимо начинать со слов:
5. Задачи: перечислить задачи;
6. Задачи исследования: перечислить задачи;
7. Задачи проектной (исследовательской) работы: перечислить задачи.

Постановка задачи

После чего перечисляются задачи, каждая с новой строки.

Особенности подготовки задач в проектной работе

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

• Выяснить
• Доказать
• Измерить
• Изучить
• Исследовать
• Найти
• Обобщить
• Ознакомиться c
• Описать
• Определить
• Познакомиться c
• Показать
• Получить
• Предложить
• Проанализировать
• Провести анализ
• Провести
• Проработать
• Проследить
• Разработать
• Рассчитать
• Реализовать
• Сделать
• Собрать
• Согласовать
• Составить
• Сопоставить
• Сравнить
• Узнать
• Установить

Характеристика задач во введении проектной работы

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

1. Изучить литературу по теме .
2. Выяснить значение терминов …
3. Найти примеры … в … / собрать материал … / изучить состав … / измерить уровень …
4. Провести опрос / эксперимент /наблюдение/ анкетирование
5. Сравнить/ сопоставить /проанализировать полученные результаты
6. Сделать выводы о …
7. Познакомиться, понаблюдать…

Как сформулировать задачи в проектной (исследовательской) работе

Для того чтобы правильно сформулировать задачи проектной работы необходимо:

SMART цели. Достигать цели легко, если они SMART!

1. Определится с тем, как можно достичь поставленной цели т.е. какие необходимо рассмотреть материалы в теоретической части и на какие пункты можно их разделить (желательно 2-4 параграфа), например:
2. изучить историю развития храмов Древнего Рима;
3. рассмотреть основные храмы Древнего Рима;
4. выявить особенности конструкции храмов Древнего Рима.

Далее определиться с практической частью и также решить, из каких этапов она будет состоять, например:

• подготовка и проведение анкетирования одноклассников;
• анализ полученных результатов;
• разработка рекомендаций (если предполагает тема).

• подготовительную (подготовка анкетных листов, материалов для проведения опытов, сбор информации, поиск информации или материалов и т.д.)
• сам процесс реализации (анкетирование, опыты, расчёт каких-либо данных, анализ статистических данных, изготовление модели, макета, прибора и т.д.).

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

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

Ошибки при подготовке задач проектной (исследовательской) работы

Решая какие задачи необходимо решить в ходе выполнения проектной работы для достижения поставленной цели можно допустить ряд ошибок:

1. Задач в проектной работе не может быть меньше 2-х так как проектная работа не может состоять из 1 главы или параграфа.
2. Количество задач не соответствует количеству этапов, которые были реализованы в ходе выполнения проектной работы (обычно количество задач соответствует количеству параграфов, в некоторых случаях может быть незначительно больше или меньше).
3. Указаны лишние задачи:
4. написание проекта;
5. подготовка каких-либо конкретных разделов проекта (Введения, Заключения, Списка использованных источников);
6. оформление проектной работы;
7. подготовка продукта проектной деятельности;
8. подготовка презентации и речи на защиту;
9. защита проектной работы.
10. Большое количество задачи, не следует делать их больше 10 (для начальной школы не более 6).
11. Лишний текст – в задачах не описываются конкретные пункты, не используется текст по теме работы, не ставятся сноски.
12. Копирование чужих задач – каждая работа индивидуальна, используя чужие материалы хорошего результата добиться не получится, кроме того, это плагиат.
13. Неправильное расположение задач во введении – они должны находиться сразу после цели.

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

Источник: workproekt.ru

Как правильно ставить задачи программистам

Существует расхожее мнение, что программист по умолчанию знает все: с закрытыми глазами ориентируется в незнакомом проекте, бегло читает и сразу же компилирует в голове любой впервые увиденный код, а также умеет на основании очень краткой формулировки детально понять все требования к реализации, заложенные постановщиком задачи. В самом деле, почему бы и нет — он ведь в конце концов программист!

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

Однако важно не забывать: стопроцентно типовых проектов не существует, разве что примитивные сайты — визитки, да и в них чаще всего можно найти какую-то степень индивидуальности. Сложный же продукт — интернет-магазин, корпоративный портал — за время своей жизни неизбежно обрастает огромным объемом присущего только ему функционала, причем очень часто этот нетиповой функционал состоит из кода, написанного далеко не лучшим образом.

Рассмотрим несколько абстрактных интернет-магазинов. В одном из них разрешено оформление заказа для неавторизованного посетителя, в другом — не разрешено, третий же в процессе оформления заказа производит автоматическое создание учетной записи пользователя, да еще и с «теневой» подпиской на рассылку рекламных предложений.

В одном из магазинов информация о товарах и ценах автоматически обновляется в ходе периодического обмена данными с системой управления торговлей, в другом товары создаются и редактируются вручную, в третьем вообще импортируются из таблиц Excel с помощью специально созданного для этой цели скрипта. В магазине одежды или обуви покупатель должен выбрать размер и цвет приобретаемого товара (такие сочетания в ряде «движков» интернет-магазинов именуются торговыми предложениями), магазин бытовой техники, как правило, предлагает к своим товарам ряд расширенных программ гарантийного и постгарантийного обслуживания, магазин электроинструмента посоветует одновременно с перфоратором приобрести подходящие для него буры, зубила и пики. Один магазин предоставляет только почтовую доставку и самовывоз, тогда как другой способен определять местоположение покупателя и на основании этих данных рассчитать стоимость доставки курьерской службой. Где же среди всего перечисленного затерялся тот самый типовой, общий для всех набор функций, присущий всем этим магазинам, так сказать, «из коробки»?

Кроме того, следует учитывать, что любой веб-проект представляет собой довольно-таки слабо связанную систему. Любой раздел сайта, практически любую стороннюю библиотеку, как правило, можно изъять из проекта самым грубым образом, не наблюдая при этом каких-то фатальных последствий. Все сломается лишь в случае непосредственного обращения к отсутствующему разделу или библиотеке.

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

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

Пример: поступила задача со следующей формулировкой «На примере набора иллюстрирую проблему. Данный набор состоит из: — XXX руб, — YYY руб, сумма по ценам отдельных комплектующих = XXX + YYY = ZZZ руб. А цена набора — XYZ руб. Как можно решить данную проблему?

Т.е. мы предлагаем более привлекательные цены клиентам, если они берут наборы, а не товары по отдельности.» Проверка, проведенная исполнителем, показала, что сайт показывает цены верно: за товар 1 XXX руб, за товар 2 YYY руб, за набор — XYZ руб, что меньше суммарной цены двух товаров. Появляется вопрос — в чем состоит проблема? Вероятно, для заказчика она более чем очевидна и прямо вытекает из приведенных ценовых выкладок. Но для программиста очень полезной оказалась бы информация о том, что заказчик ожидает получить на выходе, после решения заявленной задачи. Другими словами, в тексте постановки задачи приведен пример с конкретными товарами, но никак не разъясняется ожидаемый конечный результат.

Рассмотрение постановки задачи, попытки определить модели поведения пользователя, взаимодействующего с требующим доработки инструментом, выявление неясных или двояко толкуемых моментов — это тоже время, затрачиваемое на работу по задаче. Составление и согласование детальных требований, написание технического задания — снова время. И время, затраченное на достижение понимания, что именно скрывается за первоначальной формулировкой, неизбежно будет включено в общую трудоемкость выполнения задачи, поскольку это тоже часть работы, причем нередко наиболее сложная ее часть.

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

Какой же способ постановки задач с нашей точки зрения можно назвать качественным? Человек, формулирующий задачу, для себя уже уяснил, какова цель доработки, какие проблемы предстоит решить с ее помощью.

Для исполнителя, чтобы достигнуть сравнимой степени понимания, весьма полезной будет информация о том, как именно функционирует условный предлагаемый к доработке инструмент на текущий момент, к каким результатам приводит его работа, а также что в этих результатах предполагается изменить. Далее, если работа функционала связана с какой-то визуальной частью, элементами интерфейса, с которыми пользователь взаимодействует в процессе работы, нелишне проиллюстрировать процесс работы с инструментом поэтапно, выделив на скриншотах ключевые операции.

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

Пример грамотной постановки задачи: «В настоящий момент на странице корзины работает следующая логика: в момент загрузки страницы проверяется общая сумма товаров и на основании этого устанавливается тот или иной обработчик нажатия кнопки “оформить заказ”; в случае изменения количества позиций (и как следствие — изменения общей суммы заказа) функционал нажатия кнопки «оформить заказ» никак не меняется; требуется поставить работу кнопки «Оформить заказ» в зависимость от текущей итоговой суммы заказа без перезагрузки страницы». Как нетрудно видеть, подробно изложена текущая ситуация и, что особенно важно, разъяснена ожидаемая цель задачи. Такая формулировка вызовет минимум недоумения и встречных вопросов даже у человека, впервые увидевшего данный проект.

Приведенная методика постановки задач может показаться излишне трудоемкой, однако в конечном итоге она позволяет сэкономить время исполнителя, а значит и деньги заказчика.

Источник: maximaster.ru

Постановка задачи для программиста

Сложно переоценить важность правильно поставленной задачи.
Что дает вам хорошо поставленная задача:

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

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

Так как правильно ставить задачи программистам?
Что должна содержать хорошо поставленная задача:

1. что будет результатом.
2. для чего нужен этот результат (это можно устно сказать разработчику, т.е. как вы собираетесь использовать результат его задачи)
3. особенности и нюансы. Что делать нельзя? Что необходимо использовать? Где могут быть подводные камни? Какие дополнительные критерии качества? (напр, поиск должен отрабатывать за 300 мс).
4. артефакты. Очень важно – укажите конкретику по задаче – URL, скрины, ссылки на документы, макеты.
5. критерии приемки. Как будет тестироваться результат?

После постановки задачи получите обратную связь от исполнителя. Причем не в формате “есть вопросы?”, а в формате “опиши своими словами что нужно сделать” или “как примерно будешь решать задачу”.

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

Конечно не так просто ставить задачи по такому алгоритму и это требует порядочно времени. В некоторых случаях это и вовсе не является необходимым (например, чтобы поправить верстку, необходимо просто указать URL и скрин ошибки).

Но все же при начальном планировании итерации очень желательно ставить задачи максимально конкретно и подробно.
Если у вас есть система автоматизации, то можно внедрять показатели качества постановки задач (по аналогии с объявлениями Яндекс Директ). У каждого это будут свои критерии постановки. Также можно просить исполнителей ставить оценку за постановку задачи.

А сейчас посмотрите свои последние 3 поставленных задачи и оцените насколько полно вы их сформулировали.

Если вам понравилась статья, помогите, пожалуйста с распространением этого материала в Сети.

Я недавно устроился на работу менеджером интернет проектов, эта область для меня новая (ранее работал интернет-маркетологом). Столкнулся со следующей проблемой, которую постараюсь максимально подробно описать ниже.
Перед моими глазами ещё не свёрстаный макет сайта, пока верстальщик делает свою работу, мне нужно написать задачи для программистов. Проблема в том, что я не понимаю какие элементы на сайте требуют написания кода, и как правильно сформулировать задачу.
Сейчас я руководствуюсь логикой, что если элемент интерактивный, то он требует кодинга. А как определить не интерактивные элементы на сайте, которые требуют вмешательства программиста?

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

• Вопрос задан более трёх лет назад
• 9031 просмотр

Вы – менеджер-аналитик? Вы должны произвести анализ предметной области и передать эти данные специалисту, который уже и напишет ТЗ со всеми нужными требованиями и вариантами использования для разработчиков. Которое вы перепроверите.

Напрямую с программистами вы общаться должны будете только в том случае, когда ему что-то не понятно в сфере задачи. И все.

Пользовательский сценарий: Как пользователь сайта я хочу оставить заявку на обратную связь администратору сайта, чтобы со мной связались и дали консультацию.
В блоке «Для Вас мы предлагаем следующие услуги», при нажатии на кнопку «заказать услугу» появляется окошко «заказать услугу» с тремя полями данных:
# поле ввода данных
# поле ввода данных
# поле выбора данных , состоящее из 3-х кнопок для выбора услуги (обследование, экспертиза, проектирование).
При нажатии на кнопку «отправить заявку» данные с трёх полей формы ( , , ) сохраняются в БД и дублируются на email’ы администраторов, с текстом (текст см. ниже).

В админ. панели данные показываются в таблице с четырьмя столбцами (дата обращения, имя пользователя, контактные данные, вид услуги).

h2.Структура данных
* Столбец «Дата обращения» – формируется автоматически согласно шаблону «число.месяц.год – часы:минуты» (15.02.2014 – 14:53).
* Столбец «Имя пользователя» – данные подставляются из поля формы (длина поля – 255 символов).
* Столбец «Контактные данные» – данные подставляются из поля формы (длина поля – 255 символов).
* Столбец «Вид услуги» – данные подставляются из поля формы (длина поля – 255 символов).

После нажатия на кнопку «отправить заявку» пользователю показывается lightbox с текстом, редактируемым через flatblock (текст см.ниже).

h2.Ошибки
* Если поле не заполнено и пользователь пытается отправить заявку, то незаполненное поле подсвечивается красным цветом и появляется hint под полем, с текстом: «Представьтесь пожалуйста».
* Если поле не заполнено и пользователь пытается отправить заявку, то незаполненное поле подсвечивается красным цветом и появляется hint под полем, с текстом: «Оставьте ваши контактные данные».
* Если в поле не выбрана услуга, заявка всё равно отправляется (поле не обязательное).

h3.Тексты
# Текст для email’ов администраторам:
Здравствуйте, ! С сайта « . » был отправлен запрос на обратный звонок. Данные заявки:
Имя отправителя:
Телефон отправителя:
# Текст для lightbox’а:
Спасибо, что обратились к нам!
Наш администратор свяжется с Вами в течении 10 минут.

Прокомментируйте пожалуйста задачу. Всё ли правильно расписал? Поймут ли её программисты?

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

В целом, большую часть такого ТЗ можно увидеть глядя на макет (описание формы текстом – лишняя процедура, например). Структуру БД тоже можно оставить программисту на откуп. Я бы сократил это все до примерно такого:

Необходимо реализовать функционал отправки заявки на обратную связь через форму (см. приложение N). Сохранять данные формы в БД (можно указать имя таблицы) без перезагрузки страницы, отправлять сообщение администратору сайта и информировать пользователя об успешном создании заявки сообщением в lightbox’е (см. приложение N+1).

Для кого эта статья: В первую очередь для управленцев, менеджеров и всех прочих кто не принадлежит к сословию разработчиков, но тем не менее вынужден общаться с ними и встречать непонимание при постановке задач по разработке ERP или интернет магазина, АСУ и т.д.

Также может быть полезна самим разработчикам как мини FAQ для общения с теми, кто не имел чести «накодить» хоть пару строк за свою жизнь.

Основная мотивация для внедрения этого или подобного FAQ постановки задачи очень проста и выражена ярко и понятно в виде денежных средств. Хорошие программисты стоят дорого, и не проработанные задания занимают кучу времени на уточнения, исправления и т.д., что ведет к ощутимым финансовым потерям.

Предупреждение 1: хоть статья имеет прикладной смысл и затрагивает достаточно серьезные вопросы в ней встречается .

Предупреждение 2: сам я не являюсь профессиональным программистом, но по роду своей работы при внедрении ERP или разработке бизнес окружения, проработке процессов и т.д. разрабатываю и ставлю задачи программистам.

Предупреждение 3: я буду стараться описывать процесс простым и доступным языком, понятным тем, кто мало знаком с этой сферой.

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

Возьмем пример из статьи:

Хотя немного задержимся и пропишем некоторые правила.
1. Добавляйте сопутствующие товары.
Если клиент покупает, допустим, аудио плейер не забудьте предложить ему наушники, чехол, карту памяти и т.д.
2. Похожие товары.
В этом пункте играем на повышение. Если выбранный клиентом плейер стоит 5тр. Нужно предложить ему более дорогой вариант с большим количеством функций.
Это минимум того, что нужно сделать на этой стадии.

Допустим, у нас интернет магазин и функционала «похожих товаров» по описанной схеме у нас нет, и мы хотим поставить задачу нашему отделу разработки. Задачу ставит Руководитель отдела продаж.

Первое, с чего стоит начать, это как можно точнее сформулировать свою «хотелку»:

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

Взять и нарисовать на листочке, а лучше распечатать скриншот с карточки товара и нарисовать на нем, как это должно выглядеть.
Казалось бы, всё, но лучше взять и нарисовать логическую схему.

Сделать это можно на листочке или же в Visio входящем в пакет Офис.

Нарисовать схему просто, вы сейчас сами это увидите, рисуем:

Прямоугольники сверху — это исходные данные или результат принятия решения.

Ромбы — это решение которое нужно принять, ДА или НЕТ, логическое действие.

Итак, имеем Цену исходного товара, исходную группу и сам исходный товара. Дальше, согласно нашей задумке, делаем выборку из группы товара идентичной исходной и цене выше исходного товара. И тут сразу стоп, насколько товар, который мы предлагаем как альтернативу, может быть выше исходного? Ведь если мы предложим покупающему плеер за 5тр и топовую модель за 50тр, он вряд ли обратит на это внимание. Но если предложить вариант, скажем, за 6-7, ну до 10тр, то возможно клиент выберет вариант и подороже, соответственно принесет магазину большую прибыль.

Первое, что приходит в голову, это ограничиться порогом «не более чем в два раза». Теперь в каком порядке выстраивать дорожку из предложений в карточке товара? Начинать с самой дорогой смысла нет, логичнее, если клиент начнет сравнивать модели, а не испугается сразу высокой ценой. Но и предлагать модели по цене 5020р, то есть на немного дороже, тоже нет, количество похожих товаров ограничено, скажем, 5шт (больше не влезет). Отсюда добавляется ещё одно условие, «не более чем в два раза, но и не менее чем на 10%-20%».

Уже интереснее. Но опять стоп. А товара мы можем показать всего 5шт, но какой у них шаг по цене? То есть исходный плеер по цене 5000р и другие 5550р., 5505р и т.д. То есть товара много, а показать нам нужно разный и всего 5шт.

Думаем: максимальная планка у нас в два раза, то есть 200%, минимальная 20%, то есть нам эту цепочку нужно разбить на 5 частей и примерно равномерно.

Подумав и прикинув статистику продаж, движение покупателя по товарам и т.д. делаем так, к примеру 20% — 60% — 100% — 150% — 200%. Отлично, но товара именно с такой ценой, то есть + 200% может и не быть, следовательно, нужно заложить, что выбираем ближайший, максимально подходящий по цене, то есть +-.

Вроде всё учел, ещё раз продумываем все нюансы… Есть ещё один, а что если товара из выборки нет в наличии? То его явно не следует показывать, добавляем и это условие.

Что ещё может случиться? Ну, например, товара по выборке может не быть вообще или же его окажется не 5 а скажем 2 или 3. В этом случае отображаем что есть, если же товара, подходящего нет вовсе, отображаем ближайший или товар из сходной группы. Если нам это не нравится, то можно не отображать блок вовсе, но это не есть гуд.

Добавим и эти условия:

Вроде все видимые варианты предусмотрены.

Теперь компонуем всё в кучу. Берем наш листик с изображением вставки в карточку товара и корзину, добавляем схему и формулируем схему текстом:

Добавить блок «похожие товары» в карточку товара и корзину, согласно схематичному рисунку.

Логика работы в схеме и текстом:

Текст будет тренировкой, думаю его не сложно будет написать самим.

Добавьте в комментариях какие нюансы я мог упустить и подходит ли такой вариант вам как разработчику из разряда лучше так, чем как раньше?

Источник: 4systems.ru