Если говорить конкретно об ИТ, сразу можно предположить следующее трудоустройство: управление проектами, тестирование, эргономика (или юзабилити, это уж на вкус). Служба поддержки. Техническое писательство.
Это если исходить из образования. Если же из склада ума (а он не сильно корректируется образованием, есть неплохие программисты бросивший политех и не менее хорошие с какой-нибудь философии), то тут уж вообще размах широкий.
что-то я такого субпродукта не вижу на схеме.
в общем, все эти квадратики - действия, а не результаты. Результатов нет. Соответственно какой план поставки можно скомпоновать из "верстки" и "дизайна", не очень понятно.
оценки по ним делать нельзя, зависимостей нет,
а если менеджер разбивает на подзадачи что-то, что делать будет не он сам и в чем он не очень понимает, это будет зряшная трата бумаги.
нарисуйте там действительно промежуточные продукты и ссылочки на тех, кто их детализирует и реализует, и будет уже что-то более похожее на реальную жизнь.
если ИСР - это такой вольный перевод WBS, то во всем вышесказанном есть один немаловажный недочет, а именно "well-designed WBS describes planned outcomes instead of planned actions" Это может показаться важным хотя бы потому, что в иерархической схеме нет возможностей корректно показать зависимости.
ну если "слушать" в таком стиле ("нам виднее, чего пользователи хотят"), тогда можно хоть как релизить, разница небольшая.
я говорю о ситуации, когда делается запланированная функциональность, делается как предполагалось, доводится до более-менее живого состояния и отдается пользователям. После чего появляется обратная связь: "да, клёвая фича, но мы сталкиваемся со следующей проблемой: ..." Как правило, "следующую проблему",которая может быть как недоделкой реализации, так и проектирования, на сайте разработчика предусмотреть/смоделировать сложно.
в случае публичных релизов, мнээ... тут надо кое-что отметить.
в каком-то смысле это, действительно, бета-тестинг. Но. публичный бета-тестинг подразумевает очень и очень приличное внутреннее тестирование. То есть как минимум регресии нет, а все новое "в основном работает"
и это действительно хороший способ связи с пользователем, в том плане чтобы отследить, а в нужную ли сторону развивается продукт, и вовремя остановиться, если что.
Плюши?
Я наверное неправильный пользователь, мне web 2.0 не нужен, а вот некоторая интеллектуальность сервиса очень даже нужна.
Применительно к вышеописанным проектам, я бы включил в "интеллектуальность" использование geo ip сервиса, способность запоминать введенную информацию и хотя бы иногда догадываться, что пользователь хочет ввести (ну и так далее по Норману и Раскину)
PS а хабру нужна форма ввода комментария побольше, да.
а вот кстати, сегодня обнаружил: старые линки не работают. зашел сегодня по ссылке с гугла - попал на главную страницу.
уж это-то надо было, наверное, сразу реализовать, нет?
ммм... ну в общем я хотел сказать, что это весьма нехорошо, когда пользователя вынужнают переучиваться, как бы намекая, что всё так сложно, что самому ему никак не дотупить. возможно, это не очень справедливое утверждение.
а еще, вот это убило просто, да: Огромное количество голливудских штампов ра Читать полностью
- обрезка рецензий некрасивая.
Не нравится мне слово "компромис". Компромис - это уступки с обоих сторон, в результате которых ни одна сторона не получает того, чего добивалась изначально. Консенсус гораздо лучше.
Рассматривать пользователя как объект системы в данном случае не очень правильно. Вообще про регистрацию пользователей много всего сказано было, но, как правило, джентельменский набор из имени, пароля и емейла считается общепринятым и ни у кого возражений не вызывает. Правда, тот же Раскин считает, что можно обойтись и без имени, только паролем. А е-мейл (настоящий) я готов указать, если знаю, что он нужен для реализации полезных для меня функций, вроде рассылки оповещений или напоминания пароля. Если же я на вашем сайте увижу предупреждение вроде "Обязательно введите емейл. Мы вам не скажем, зачем он нам нужен, но без него мы вам работать не дадим" то я с большой вероятностью закрою страницу и более не вернусь.
Хорошие аргументы против жестких правил я вычитал у Купера. Человек в жизни крайне редко использует жесткие правила. Я перехожу дорогу на красный свет, если считаю, что это можно сделать без опасности для себя и окружающих. Я могу распечатать не полностью заполненное заявление/письмо/что-то еще, чтобы потом вписать недостающее от руки. Можно много таких примеров привести. Я могу заказать товар через интернет, потом по телефону договориться с человеком о конкретных условиях доставки и оплаты.
И в то же время, я вынужден простоять несколько часов в очереди, выбросить десяток испорченных бланков и окончательно вымотаться, когда обращаюсь в некое госучереждение.
Так вот лично мне не нравится, когда я должен принимать правила программного обеспечения, а не оно - мои. Когда я должен заполнить все поля ввода, чтобы ввести какой-то объект в систему, только потому, что разработчик при проектировании слишком часто использовал слова "а вдруг", "предположим" и "на всякий случай". Когда для импортирования одного документа в другой я должен обязательно сохранить его, поместить в определенное место в файловой системе, назвать специальным именем, задать формат импорта, и тд и тп.
Разумеется, это спорное утверждение, что компютеры должны быть похожи на людей. Если же говорить о контексте, то, да, интерфейс управления АЭС не должен допускать ситуации вроде "да ладно, реакцию можно и потом остановить" или сообщений "температура охлаждающей системы приблизительно 50 градусов, ну, плюс-минус полкило". А интерфейс офисной системы не должен требовать от сотрудников поднятия корпоративного флага перед внесением счета в базу. По-моему, хорошим примером тут является ЕГАИС, про неё многие плакали (сам не видел, правда).
А неконкретными как раз являются вещи, типа обсуждаемой презентации. Гармония и красота должна присутствовать везде :-)
Это если исходить из образования. Если же из склада ума (а он не сильно корректируется образованием, есть неплохие программисты бросивший политех и не менее хорошие с какой-нибудь философии), то тут уж вообще размах широкий.
в общем, все эти квадратики - действия, а не результаты. Результатов нет. Соответственно какой план поставки можно скомпоновать из "верстки" и "дизайна", не очень понятно.
оценки по ним делать нельзя, зависимостей нет,
а если менеджер разбивает на подзадачи что-то, что делать будет не он сам и в чем он не очень понимает, это будет зряшная трата бумаги.
нарисуйте там действительно промежуточные продукты и ссылочки на тех, кто их детализирует и реализует, и будет уже что-то более похожее на реальную жизнь.
я говорю о ситуации, когда делается запланированная функциональность, делается как предполагалось, доводится до более-менее живого состояния и отдается пользователям. После чего появляется обратная связь: "да, клёвая фича, но мы сталкиваемся со следующей проблемой: ..." Как правило, "следующую проблему",которая может быть как недоделкой реализации, так и проектирования, на сайте разработчика предусмотреть/смоделировать сложно.
в каком-то смысле это, действительно, бета-тестинг. Но. публичный бета-тестинг подразумевает очень и очень приличное внутреннее тестирование. То есть как минимум регресии нет, а все новое "в основном работает"
и это действительно хороший способ связи с пользователем, в том плане чтобы отследить, а в нужную ли сторону развивается продукт, и вовремя остановиться, если что.
прям грустно смотреть, сегодня один баг, завтра на его месте другой...
Я наверное неправильный пользователь, мне web 2.0 не нужен, а вот некоторая интеллектуальность сервиса очень даже нужна.
Применительно к вышеописанным проектам, я бы включил в "интеллектуальность" использование geo ip сервиса, способность запоминать введенную информацию и хотя бы иногда догадываться, что пользователь хочет ввести (ну и так далее по Норману и Раскину)
PS а хабру нужна форма ввода комментария побольше, да.
и багов порядочно.
уж это-то надо было, наверное, сразу реализовать, нет?
а еще, вот это убило просто, да:
Огромное количество голливудских штампов ра Читать полностью
- обрезка рецензий некрасивая.
Рассматривать пользователя как объект системы в данном случае не очень правильно. Вообще про регистрацию пользователей много всего сказано было, но, как правило, джентельменский набор из имени, пароля и емейла считается общепринятым и ни у кого возражений не вызывает. Правда, тот же Раскин считает, что можно обойтись и без имени, только паролем. А е-мейл (настоящий) я готов указать, если знаю, что он нужен для реализации полезных для меня функций, вроде рассылки оповещений или напоминания пароля. Если же я на вашем сайте увижу предупреждение вроде "Обязательно введите емейл. Мы вам не скажем, зачем он нам нужен, но без него мы вам работать не дадим" то я с большой вероятностью закрою страницу и более не вернусь.
И в то же время, я вынужден простоять несколько часов в очереди, выбросить десяток испорченных бланков и окончательно вымотаться, когда обращаюсь в некое госучереждение.
Так вот лично мне не нравится, когда я должен принимать правила программного обеспечения, а не оно - мои. Когда я должен заполнить все поля ввода, чтобы ввести какой-то объект в систему, только потому, что разработчик при проектировании слишком часто использовал слова "а вдруг", "предположим" и "на всякий случай". Когда для импортирования одного документа в другой я должен обязательно сохранить его, поместить в определенное место в файловой системе, назвать специальным именем, задать формат импорта, и тд и тп.
Разумеется, это спорное утверждение, что компютеры должны быть похожи на людей. Если же говорить о контексте, то, да, интерфейс управления АЭС не должен допускать ситуации вроде "да ладно, реакцию можно и потом остановить" или сообщений "температура охлаждающей системы приблизительно 50 градусов, ну, плюс-минус полкило". А интерфейс офисной системы не должен требовать от сотрудников поднятия корпоративного флага перед внесением счета в базу. По-моему, хорошим примером тут является ЕГАИС, про неё многие плакали (сам не видел, правда).
А неконкретными как раз являются вещи, типа обсуждаемой презентации. Гармония и красота должна присутствовать везде :-)