Комментарии 8
Сама часто замечаю, что все тонкости процесса всплывают уже во время обсуждения ТЗ с ИТ-шниками.
К сожалению, многие детали заранее сложно продумать, но минимум (то, что вы указали) вполне. Отличный пример!
К сожалению, многие детали заранее сложно продумать, но минимум (то, что вы указали) вполне. Отличный пример!
Речь идет о выводе списка товаров. Для списка имеются два основных параметра:
а) условие отбора или другими словами фильтр
б) порядок сортировки
Достаточно перечислить условия отбора и порядок сортировки по пунктам в виде текстового списка, например
а) Условия отбора
1. Не более 5
2. Совпадает группа
3. Есть наличие
4. Один из ценовой ценовой группы 0-20%… и т.д.
…
б) Порядок сортировки
1. Цена по возрастанию
Для такой простой задачи блоксхема не нужна, так как излишне громоздка. Сам автор нарисовав несколько квадратиков в итоге перешел к текстовому описанию. Блоксхемы приветствуются если есть сложный бизнес-процесс, чтобы описать этапы этого процесса, показать общую картину. Опускаться до изображения на блоксхеме каждого if'а, который должен написать программист, не следует.
Сам по себе формат ТЗ вообще мало что дает. Рисовать в visio можно и макаку научить. А вот предусматривать все граничные условия, типа «а если нет в наличии, а если слишком дорого, а если все в одну цену, а если нет ни одного» вот это из постановщиков редко кто делает. Обычно такие вопросы по ТЗ задает сам программист или они всплывают, когда показывают результат работы, а он не удовлетворяет.
Как добиться такого подхода от постановщика задачи, вот эта тема не раскрыта.
а) условие отбора или другими словами фильтр
б) порядок сортировки
Достаточно перечислить условия отбора и порядок сортировки по пунктам в виде текстового списка, например
а) Условия отбора
1. Не более 5
2. Совпадает группа
3. Есть наличие
4. Один из ценовой ценовой группы 0-20%… и т.д.
…
б) Порядок сортировки
1. Цена по возрастанию
Для такой простой задачи блоксхема не нужна, так как излишне громоздка. Сам автор нарисовав несколько квадратиков в итоге перешел к текстовому описанию. Блоксхемы приветствуются если есть сложный бизнес-процесс, чтобы описать этапы этого процесса, показать общую картину. Опускаться до изображения на блоксхеме каждого if'а, который должен написать программист, не следует.
Сам по себе формат ТЗ вообще мало что дает. Рисовать в visio можно и макаку научить. А вот предусматривать все граничные условия, типа «а если нет в наличии, а если слишком дорого, а если все в одну цену, а если нет ни одного» вот это из постановщиков редко кто делает. Обычно такие вопросы по ТЗ задает сам программист или они всплывают, когда показывают результат работы, а он не удовлетворяет.
Как добиться такого подхода от постановщика задачи, вот эта тема не раскрыта.
Я описал шаги с размышлением, постарался показать логику рассуждений, если вы знаете как работает ваш магазин с точки зрения менеджера, не разработчика то это вполне доступно на мой взгляд. Согласен, что нужен опыт и знания, но и учится нужно, как можно руководить магазином не понимая как он работает?
Схема нужна больше для понимания самому заказчику, так проще увидеть картину. Ну а небольшой и достаточно простой вариант взят для примера )
Добиться можно только обучением персонала и нормативными документами в компании.
Схема нужна больше для понимания самому заказчику, так проще увидеть картину. Ну а небольшой и достаточно простой вариант взят для примера )
Добиться можно только обучением персонала и нормативными документами в компании.
Если ставить задачу просто написать ТЗ, то никогда его правильно не написать.
Даже прочитав много книг и песен — все бесполезно.
Только поработав в тесной команде программист и тестирующий постановщик научатся понимать друг друга и то не сразу и не все.
Более мнее грамотно написать ТЗ можно, но результат всегда будет немного не тот. Я даже иногда офигеваю от того насколько по-разному люди понимают одну и туже нписанную черным по белому фразу.
Но когда я смог ссылаясь на НПА доказать сначала одно, а потом диаметрально противоположное — мое мнение кардинально поменялось.
Даже прочитав много книг и песен — все бесполезно.
Только поработав в тесной команде программист и тестирующий постановщик научатся понимать друг друга и то не сразу и не все.
Более мнее грамотно написать ТЗ можно, но результат всегда будет немного не тот. Я даже иногда офигеваю от того насколько по-разному люди понимают одну и туже нписанную черным по белому фразу.
Но когда я смог ссылаясь на НПА доказать сначала одно, а потом диаметрально противоположное — мое мнение кардинально поменялось.
«даже иногда офигеваю от того насколько по-разному люди понимают одну и туже нписанную черным по белому фразу.»
лишний раз подтверждает утверждение нашего учителя логики, что нет единой логики и тем более ее как науки. Из одних и тех же фактов разные люди сделают совершенно разные выводы. Имея это в уме, можно походить к построению ТЗ, интерфейса и тому подобного более гибче, чем раз это понял я, значит поймут и все.
лишний раз подтверждает утверждение нашего учителя логики, что нет единой логики и тем более ее как науки. Из одних и тех же фактов разные люди сделают совершенно разные выводы. Имея это в уме, можно походить к построению ТЗ, интерфейса и тому подобного более гибче, чем раз это понял я, значит поймут и все.
Обычно писатель ТЗ не может алгоритмизировать задачу.
Даже если может — не всегда знает ограничения.
Даже если может и знает, то бывает банально не в состоянии учесть все факторы. В итоге отбрасывает часть как незначимые (или не уделяет им достаточно внимания в ТЗ), а потом оказывается что они кардинальным образом меняют продукт.
ЗЫ. Предельно алгоритмизированное ТЗ == программа.
Даже если может — не всегда знает ограничения.
Даже если может и знает, то бывает банально не в состоянии учесть все факторы. В итоге отбрасывает часть как незначимые (или не уделяет им достаточно внимания в ТЗ), а потом оказывается что они кардинальным образом меняют продукт.
ЗЫ. Предельно алгоритмизированное ТЗ == программа.
Очень полезна была бы еще статья «как написать универсальное ТЗ, которое можно согласовывать с заказчиком, далёким от IT, и которое могут использовать все члены команды: менеджеры, дизайнеры, разработчики».
ТЗ нужно писать так, что бы его поняла группа разработки, а руководитель проекта должен уметь объяснить ТЗ на понятном языке заказчику. Корче парадокс, занимаясь ИТ мы начинаем говорить на понятном языке в своем кругу, но переходя или смеживая с продажей, приходится учится в обратную сторону, объяснять ИТ заказчику, так, что бы он тебя понимал. Это сложно и не у многих получается )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Как правильно писать ТЗ или общаемся с программистом на понятном языке. Простое моделирование и алгоритмизация