Это все прекрасно, но в первую очередь фильтрация должна быть функциональной. Т.е. у пользователя должна быть возможность осуществить отбор интересующих его товаров без необоснованных ограничений, как то недостаточное число параметров фильтрации (если по каким то причинам автор решит что изобилие отпугнет пользователя :)) или возможность выбора только одного варианта там, где нужно несколько (пример — pandawill.com). Когда нельзя нормально отфильтровать лишнее и приходится листать десятки страниц, отыскивая товар вручную — это куда важнее чем где расположена панелька — сбоку или по центру. А насчет локуса довольно спорно. Он всегда будет сосредоточен на одной сущности, но это не значит, что нужно весь экран отдавать под форму фильтрации. Ведь часто люди увидев результаты фильтрации стремятся немного поправить параметры и перефильтровать… а для этого удобней когда на странице и форма и результаты выдачи. Если посмотреть на тот же Яндекс.Маркет — там все действительно удобно (разве что подсознательно тянет форму фильтрации перенести в левую часть окна)
Наверно не только. Математика скорее универсальный язык описания действительности, как окружающей (воспринимаемой как объективная реальность), так и любой абстрактной
7й месяц использую Family 11 Pro. Из плюсом — весьма удобный клиент под Android. Минусов к сожалению больше — периодически подглючивает, редкие релизы, уж слишком примитивная система отчетов и т.д.
Насчет, «почитать про чужой опыт»:
Ведем с женой учет седьмой месяц. Бюджетированием пока не занимаемся, только учет расходов и их анализ. Пока используем Family 11 Pro, но к нему уже скопился внушительный набор замечаний — от некоторой глючности и крайне редких релизов до примитивной системы отчетности. Неоспоримый плюс — удобный мобильный клиент. Это хотел бы особенно подчеркнуть, т.к. для нас это стало решением главное проблемой — собирать чеки/запоминать/записывать расходы. В мобильном клиенте это занимает считанные секунды и практически не напрягает. Чеки собирать необходимость отпадает. В остальном — как закончится годовая лицензия попробуем что-то новое.
Если говорить про результаты, то можно два момента отметить:
1) Теперь мы точно знаем куда уходят деньги. Сделали для себя несколько неожиданных открытий )
2) Даже учет сам по себе немного дисциплинирует. Так что на всякую ерунду денег стали тратить немного меньше. Хотя до удовлетворительного результата еще далеко. Неадвно подбивал итоги за пол года… Еда заметно «вылезла» из 20%, почти 15% расходов на корректировку (это то, что не учли/не вспомнили). Пока плохом. Будем стараться лучше
ТЗ — результат этапа анализа, прототипы — как минимум уже этапа проектирования (в зависимости от их типа). Другой вопрос, что часто макеты интерфейса проектируют те же аналитики, причем иногда включают их в само ТЗ.
Очень позитивная статья! ) Сам недавно прочитал книгу "(бес)Цельная жизнь", да и mind maps как раз начал использовать. Ни о том ни о другом не жалею — эти потраченные время/силы окупились УЖЕ. Ну а базовые идеи вроде «фиксировать задачи», «оптимизировать рабочий процесс под свои особенности», «полноценно отдыхать», «не забывать о главном» — они ведь по большому счету не новы, и качуют из одной бизнес-книги в другую уже не первое десятилетие. Разница лишь в настрое, с которым они подаются, сочности примеров да личной харизме автора. Но главный вопрос — как заставить себя начать! Как оторвать 5-ю точку от дивана и начать делать то, что важно и что давно хотел? А уж разобраться трекать ли таски в Джире или чиркать ручкой в блокноте — это уж совсем мелочь. Да хоть на скрижалях выбивайте. Лучно я от этой статьи кроме позитива взял идею (а точнее решимость ее выполнить) мониторить на что я трачу время и потом это проанализировать. Так что спасибо Вам большое! )
Мда… MSc in Software Engineering — € 17,249.33. Но тут интересней вопрос даже не столько про финансовую сторону, сколько про время. По собственному, хоть и скромному опыту (на Coursera), совмещать с повседневной жизнь даже 2 их курса одновременно уже совсем непросто. У меня, например, не получалось, если не халтурить. Максимум 1. А полноценное обучение совместить с полноценной работой — это уже героизм ).
>> The total workload is the same as the residential program
С такой загрузкой не совсем понятно, как это совмещать еще хоть с чем-то. Кстати, очень любопытно было бы взглянуть на подробную программу обучения
Устаревание требований — действительно ключевая проблема. Согласен с коллегами — она отчасти решается использованием гибких методологий разработки, а отчасти — прописанием в уставе проекта, что все понимают, что требования не могут быть сформулированы сразу полностью и безошибочно, да еще и на длительный срок. Т.е. заказчик имеет право менять требования по ходу проекта, но при этом адекватно относится к соответствующему увеличению сроков и стоимости.
Что касается «недетализированных ТЗ», то это скорее Бизнес-требования. Если по вашим формулировкам программист не может начать работать, то это не ТЗ и не его аналог. ТЗ на 10 страниц — отличная идея, но не всегда реализуемая (например многие гос. заказчики требуют полное ТЗ до начала разработки). Но даже если мы напишем «монстра» на 250 стр, то его совсем не нужно читать полностью всем разработчикам. Куда удобнее использовать системы таск-трекинга, в талоны которых можно писать номера конкретных разделов ТЗ, где детализирован именно текущий таск.
Пример:
1. Аналитик Вася заводит фичу, что нужно добавить в админку новый справочник и указывает номер раздела ТЗ, где он описан
2. Dev lead Дима создает дочерние таски (доработать БД, создать новую вкладку на UI, реализовать импорт их XLSX и т.д.)
3. И когда дело доходит до разработчиков Саши, Маши и Вольдемара — то им либо не нужно смотреть в спеку вообще, либо — только в указанный раздел
Как удостовериться, что програмулька, на анализ которой ушло пол года, а на разработку еще год полностью соответствует требованиям заказчика
Формальные способ (если резюмировать) — использование agile-овых методик. Косвенный — не скупиться на опытных аналитиков :)
Приоритезация требований — задача заказчика с помощью аналитика(-ов) исполнителя. Но никак не менеджера исполнителя. Следующие 2 пункта РП так же может только курировать. Он сам не определяет ни рамки (а лишь согласовывает с заказчиком то, что предварительно оговорено с аналитиком… а еще перед этим — с аккаунтом) и сам не определяет границы итераций, т.к. для этого надо как минимум четко понимать взаимосвязи между требованиями. Он может лишь согласовывать и утверждать их.
Я не хочу спорить о смысле формальных терминов, я просто имел ввиду что по сути управление требованиями — задача аналитика. А то что РП в ней организационно участвует — так он так же участвует в большинстве проектных активностей.
Извиняюсь, если некорректно сформулировал. Я просто хотел донести суть.
Кстати, переход «разработано — протестировано» тоже бывает организован по-разному. Часто реализацию ключевых требований полезно «пропускать» через аналитика, чтобы обеспечить высокоуровневую проверку (чтобы исключить ситуацию, когда тестеры убьют неделю на тестирование того, что в принципе должно работать по другому… причем такая ситуация может быть не только из-за нечетко сформулированных требований, но и еще из-за ряда причин, таких, например, как квалификация самих тестировщиков… ничего плохого не хочу про них сказать, но бывают ситуации когда на проекте временно работают только тест-джуниоры).
и как же вы интересно в работе отличаете функциональные функциональные требования от функциональных нефункциональных?
получается, что так, как предложено во второй Вашей ссылке — зовем их системными (в классификации по уровню)
Какие ещё есть подходы, делюсь
Было бы интересно почитать про опыт практического применения первого подхода. На первый взгляд, он выглядит перегруженным. А второй по сути совпадает с описанным в статье.
То, что во второй — управление требованиями — совсем другая работа, ей занимается менеджер.
Признаться, на практике ни разу не сталкивался с ситуацией, когда менеджер участвует в процессе управления требованиями более, чем на уровне отслеживания статусов ключевых из них. Даже на довольно крупных проектах не попадалось подобного разделения. Весь жизненный цикл требований всегда контролируется аналитиком, иначе будет бедлам.
Если Вы имеете ввиду менеджера продукта, то в нашей действительности это обычно на 80% тот же аналитик с некоторыми дополнительными обязанностями/полномочиями, вроде участия в маркетинговых активностях.
«Пишутся» это скорее уже фиксация. Едва ли в ТЗ для крупного гос. заказчика будут уместны эмоции. Доносятся же мысли обычно раньше — на совещаниях и конф. колах. Там, конечно, язык куда боле живой. Иногда даже слишком живой :)
Но что я, судя по всему, точно сделал зря, так это выбрал сухой стиль изложения для этой статьи на Хабре. Не стоило насиловать Ваше восприятие формализованным текстом. Исправлюсь.
Я имел ввиду, что не стоит включать в ТЗ результаты «тяжелых» работ этапа проектирования, выполняемых архитектором. Макеты интерфейса — тоже проектирование, но трудозатраты на него как правило меньше, и выполняется оно тем же аналитиком, который пишет ТЗ. Поэтому, хотя логически это не правильно, в ТЗ все-таки можно включать макеты UI, т.к. это дается малой кровью.
Ведем с женой учет седьмой месяц. Бюджетированием пока не занимаемся, только учет расходов и их анализ. Пока используем Family 11 Pro, но к нему уже скопился внушительный набор замечаний — от некоторой глючности и крайне редких релизов до примитивной системы отчетности. Неоспоримый плюс — удобный мобильный клиент. Это хотел бы особенно подчеркнуть, т.к. для нас это стало решением главное проблемой — собирать чеки/запоминать/записывать расходы. В мобильном клиенте это занимает считанные секунды и практически не напрягает. Чеки собирать необходимость отпадает. В остальном — как закончится годовая лицензия попробуем что-то новое.
Если говорить про результаты, то можно два момента отметить:
1) Теперь мы точно знаем куда уходят деньги. Сделали для себя несколько неожиданных открытий )
2) Даже учет сам по себе немного дисциплинирует. Так что на всякую ерунду денег стали тратить немного меньше. Хотя до удовлетворительного результата еще далеко. Неадвно подбивал итоги за пол года… Еда заметно «вылезла» из 20%, почти 15% расходов на корректировку (это то, что не учли/не вспомнили). Пока плохом. Будем стараться лучше
звучит одновременно комично и грустно
С такой загрузкой не совсем понятно, как это совмещать еще хоть с чем-то. Кстати, очень любопытно было бы взглянуть на подробную программу обучения
Что касается «недетализированных ТЗ», то это скорее Бизнес-требования. Если по вашим формулировкам программист не может начать работать, то это не ТЗ и не его аналог. ТЗ на 10 страниц — отличная идея, но не всегда реализуемая (например многие гос. заказчики требуют полное ТЗ до начала разработки). Но даже если мы напишем «монстра» на 250 стр, то его совсем не нужно читать полностью всем разработчикам. Куда удобнее использовать системы таск-трекинга, в талоны которых можно писать номера конкретных разделов ТЗ, где детализирован именно текущий таск.
Пример:
1. Аналитик Вася заводит фичу, что нужно добавить в админку новый справочник и указывает номер раздела ТЗ, где он описан
2. Dev lead Дима создает дочерние таски (доработать БД, создать новую вкладку на UI, реализовать импорт их XLSX и т.д.)
3. И когда дело доходит до разработчиков Саши, Маши и Вольдемара — то им либо не нужно смотреть в спеку вообще, либо — только в указанный раздел
Формальные способ (если резюмировать) — использование agile-овых методик. Косвенный — не скупиться на опытных аналитиков :)
Я не хочу спорить о смысле формальных терминов, я просто имел ввиду что по сути управление требованиями — задача аналитика. А то что РП в ней организационно участвует — так он так же участвует в большинстве проектных активностей.
Извиняюсь, если некорректно сформулировал. Я просто хотел донести суть.
Кстати, переход «разработано — протестировано» тоже бывает организован по-разному. Часто реализацию ключевых требований полезно «пропускать» через аналитика, чтобы обеспечить высокоуровневую проверку (чтобы исключить ситуацию, когда тестеры убьют неделю на тестирование того, что в принципе должно работать по другому… причем такая ситуация может быть не только из-за нечетко сформулированных требований, но и еще из-за ряда причин, таких, например, как квалификация самих тестировщиков… ничего плохого не хочу про них сказать, но бывают ситуации когда на проекте временно работают только тест-джуниоры).
получается, что так, как предложено во второй Вашей ссылке — зовем их системными (в классификации по уровню)
Было бы интересно почитать про опыт практического применения первого подхода. На первый взгляд, он выглядит перегруженным. А второй по сути совпадает с описанным в статье.
Кстати, хотел поблагодарить за интересные видео (В чём заключается работа системного аналитика (видео)), и узнать, планируете ли Вы продолжать активности по летней школе системного анализа?
Признаться, на практике ни разу не сталкивался с ситуацией, когда менеджер участвует в процессе управления требованиями более, чем на уровне отслеживания статусов ключевых из них. Даже на довольно крупных проектах не попадалось подобного разделения. Весь жизненный цикл требований всегда контролируется аналитиком, иначе будет бедлам.
Если Вы имеете ввиду менеджера продукта, то в нашей действительности это обычно на 80% тот же аналитик с некоторыми дополнительными обязанностями/полномочиями, вроде участия в маркетинговых активностях.
Но что я, судя по всему, точно сделал зря, так это выбрал сухой стиль изложения для этой статьи на Хабре. Не стоило насиловать Ваше восприятие формализованным текстом. Исправлюсь.