Также может быть полезна самим разработчикам как мини 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. В этом случае отображаем что есть, если же товара, подходящего нет вовсе, отображаем ближайший или товар из сходной группы. Если нам это не нравится, то можно не отображать блок вовсе, но это не есть гуд.
Добавим и эти условия:
Вроде все видимые варианты предусмотрены.
Теперь компонуем всё в кучу. Берем наш листик с изображением вставки в карточку товара и корзину, добавляем схему и формулируем схему текстом:
Добавить блок «похожие товары» в карточку товара и корзину, согласно схематичному рисунку.
Логика работы в схеме и текстом:
Текст будет тренировкой, думаю его не сложно будет написать самим.
PS
Добавьте в комментариях какие нюансы я мог упустить и подходит ли такой вариант вам как разработчику из разряда лучше так, чем как раньше?
Скачать схему в Visio Яндекс диск
Комментарии (8)
Mur466
06.05.2016 13:54+3Речь идет о выводе списка товаров. Для списка имеются два основных параметра:
а) условие отбора или другими словами фильтр
б) порядок сортировки
Достаточно перечислить условия отбора и порядок сортировки по пунктам в виде текстового списка, например
а) Условия отбора
1. Не более 5
2. Совпадает группа
3. Есть наличие
4. Один из ценовой ценовой группы 0-20%… и т.д.
…
б) Порядок сортировки
1. Цена по возрастанию
Для такой простой задачи блоксхема не нужна, так как излишне громоздка. Сам автор нарисовав несколько квадратиков в итоге перешел к текстовому описанию. Блоксхемы приветствуются если есть сложный бизнес-процесс, чтобы описать этапы этого процесса, показать общую картину. Опускаться до изображения на блоксхеме каждого if'а, который должен написать программист, не следует.
Сам по себе формат ТЗ вообще мало что дает. Рисовать в visio можно и макаку научить. А вот предусматривать все граничные условия, типа «а если нет в наличии, а если слишком дорого, а если все в одну цену, а если нет ни одного» вот это из постановщиков редко кто делает. Обычно такие вопросы по ТЗ задает сам программист или они всплывают, когда показывают результат работы, а он не удовлетворяет.
Как добиться такого подхода от постановщика задачи, вот эта тема не раскрыта.
Tiamon
06.05.2016 20:44-1Я описал шаги с размышлением, постарался показать логику рассуждений, если вы знаете как работает ваш магазин с точки зрения менеджера, не разработчика то это вполне доступно на мой взгляд. Согласен, что нужен опыт и знания, но и учится нужно, как можно руководить магазином не понимая как он работает?
Схема нужна больше для понимания самому заказчику, так проще увидеть картину. Ну а небольшой и достаточно простой вариант взят для примера )
Добиться можно только обучением персонала и нормативными документами в компании.
alexhott
06.05.2016 20:39+2Если ставить задачу просто написать ТЗ, то никогда его правильно не написать.
Даже прочитав много книг и песен — все бесполезно.
Только поработав в тесной команде программист и тестирующий постановщик научатся понимать друг друга и то не сразу и не все.
Более мнее грамотно написать ТЗ можно, но результат всегда будет немного не тот. Я даже иногда офигеваю от того насколько по-разному люди понимают одну и туже нписанную черным по белому фразу.
Но когда я смог ссылаясь на НПА доказать сначала одно, а потом диаметрально противоположное — мое мнение кардинально поменялось.teifo
07.05.2016 03:40«даже иногда офигеваю от того насколько по-разному люди понимают одну и туже нписанную черным по белому фразу.»
лишний раз подтверждает утверждение нашего учителя логики, что нет единой логики и тем более ее как науки. Из одних и тех же фактов разные люди сделают совершенно разные выводы. Имея это в уме, можно походить к построению ТЗ, интерфейса и тому подобного более гибче, чем раз это понял я, значит поймут и все.
gandjustas
07.05.2016 15:16+1Обычно писатель ТЗ не может алгоритмизировать задачу.
Даже если может — не всегда знает ограничения.
Даже если может и знает, то бывает банально не в состоянии учесть все факторы. В итоге отбрасывает часть как незначимые (или не уделяет им достаточно внимания в ТЗ), а потом оказывается что они кардинальным образом меняют продукт.
ЗЫ. Предельно алгоритмизированное ТЗ == программа.
Liquidos
07.05.2016 17:36+1Очень полезна была бы еще статья «как написать универсальное ТЗ, которое можно согласовывать с заказчиком, далёким от IT, и которое могут использовать все члены команды: менеджеры, дизайнеры, разработчики».
Tiamon
08.05.2016 20:26ТЗ нужно писать так, что бы его поняла группа разработки, а руководитель проекта должен уметь объяснить ТЗ на понятном языке заказчику. Корче парадокс, занимаясь ИТ мы начинаем говорить на понятном языке в своем кругу, но переходя или смеживая с продажей, приходится учится в обратную сторону, объяснять ИТ заказчику, так, что бы он тебя понимал. Это сложно и не у многих получается )
CashMyVisit
06.05.2016 13:42+1Сама часто замечаю, что все тонкости процесса всплывают уже во время обсуждения ТЗ с ИТ-шниками.
К сожалению, многие детали заранее сложно продумать, но минимум (то, что вы указали) вполне. Отличный пример!
Mur466
06.05.2016 13:54+3Речь идет о выводе списка товаров. Для списка имеются два основных параметра:
а) условие отбора или другими словами фильтр
б) порядок сортировки
Достаточно перечислить условия отбора и порядок сортировки по пунктам в виде текстового списка, например
а) Условия отбора
1. Не более 5
2. Совпадает группа
3. Есть наличие
4. Один из ценовой ценовой группы 0-20%… и т.д.
…
б) Порядок сортировки
1. Цена по возрастанию
Для такой простой задачи блоксхема не нужна, так как излишне громоздка. Сам автор нарисовав несколько квадратиков в итоге перешел к текстовому описанию. Блоксхемы приветствуются если есть сложный бизнес-процесс, чтобы описать этапы этого процесса, показать общую картину. Опускаться до изображения на блоксхеме каждого if'а, который должен написать программист, не следует.
Сам по себе формат ТЗ вообще мало что дает. Рисовать в visio можно и макаку научить. А вот предусматривать все граничные условия, типа «а если нет в наличии, а если слишком дорого, а если все в одну цену, а если нет ни одного» вот это из постановщиков редко кто делает. Обычно такие вопросы по ТЗ задает сам программист или они всплывают, когда показывают результат работы, а он не удовлетворяет.
Как добиться такого подхода от постановщика задачи, вот эта тема не раскрыта.Tiamon
06.05.2016 20:44-1Я описал шаги с размышлением, постарался показать логику рассуждений, если вы знаете как работает ваш магазин с точки зрения менеджера, не разработчика то это вполне доступно на мой взгляд. Согласен, что нужен опыт и знания, но и учится нужно, как можно руководить магазином не понимая как он работает?
Схема нужна больше для понимания самому заказчику, так проще увидеть картину. Ну а небольшой и достаточно простой вариант взят для примера )
Добиться можно только обучением персонала и нормативными документами в компании.
alexhott
06.05.2016 20:39+2Если ставить задачу просто написать ТЗ, то никогда его правильно не написать.
Даже прочитав много книг и песен — все бесполезно.
Только поработав в тесной команде программист и тестирующий постановщик научатся понимать друг друга и то не сразу и не все.
Более мнее грамотно написать ТЗ можно, но результат всегда будет немного не тот. Я даже иногда офигеваю от того насколько по-разному люди понимают одну и туже нписанную черным по белому фразу.
Но когда я смог ссылаясь на НПА доказать сначала одно, а потом диаметрально противоположное — мое мнение кардинально поменялось.teifo
07.05.2016 03:40«даже иногда офигеваю от того насколько по-разному люди понимают одну и туже нписанную черным по белому фразу.»
лишний раз подтверждает утверждение нашего учителя логики, что нет единой логики и тем более ее как науки. Из одних и тех же фактов разные люди сделают совершенно разные выводы. Имея это в уме, можно походить к построению ТЗ, интерфейса и тому подобного более гибче, чем раз это понял я, значит поймут и все.
gandjustas
07.05.2016 15:16+1Обычно писатель ТЗ не может алгоритмизировать задачу.
Даже если может — не всегда знает ограничения.
Даже если может и знает, то бывает банально не в состоянии учесть все факторы. В итоге отбрасывает часть как незначимые (или не уделяет им достаточно внимания в ТЗ), а потом оказывается что они кардинальным образом меняют продукт.
ЗЫ. Предельно алгоритмизированное ТЗ == программа.
Liquidos
07.05.2016 17:36+1Очень полезна была бы еще статья «как написать универсальное ТЗ, которое можно согласовывать с заказчиком, далёким от IT, и которое могут использовать все члены команды: менеджеры, дизайнеры, разработчики».
Tiamon
08.05.2016 20:26ТЗ нужно писать так, что бы его поняла группа разработки, а руководитель проекта должен уметь объяснить ТЗ на понятном языке заказчику. Корче парадокс, занимаясь ИТ мы начинаем говорить на понятном языке в своем кругу, но переходя или смеживая с продажей, приходится учится в обратную сторону, объяснять ИТ заказчику, так, что бы он тебя понимал. Это сложно и не у многих получается )
CashMyVisit
Сама часто замечаю, что все тонкости процесса всплывают уже во время обсуждения ТЗ с ИТ-шниками.
К сожалению, многие детали заранее сложно продумать, но минимум (то, что вы указали) вполне. Отличный пример!