Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Метрология в вузе была. Понимаю, что определить точно, сколько будет затрачено времени на выполнение какой-либо работы, нереально. Но, всё же, меня интересуют способы, применяя которые я могу хотя бы адекватно оценивать свои трудозатраты по написанию документации и планировать работу. Если поделитесь опытом, буду благодарен.
?....не могу точно определить...Точно — это как? Метрология в вузе была?
а, в-третьих, даже при разработке того же коробочного продукта, желательно предварительно побрейнстормить, а какие цели у бизнеса, которому мы будем это предлагать, а какие у них проблемы, а может этому бизнесу будет дешевле игнорировать эти проблемы, чем покупать наше решение.Ну побрейнстормить — это завсегда полезно, даже при выборе, в какой детский сад отдать ребёнка. Только в случае продуктов, рассчитанных на частного пользователя, никакого бизнеса нет, а в случае корпоративных — нужна картина рынка, а не отдельной компании. Делать бизнес-анализ хотя бы 3-4-х организаций слишком дорого и порой принципиально невозможно (никто вас не пустит внутрь). Тут нужны другие методы.
Например, в некоторых случаях аналитику нужно будет составить большой официальный документ с планом бизнес анализа, а в других эту задачу будет выполнять менеджер, который просто "в уме" решит, что требования будут в виде юзер стори.И зачем этому менеджеру BABOK?
И еще про продуктовую разработку, во многих задачах ВАВОК среди техник предлагается Бенчмаркинг, который, по-моему, ни для чего так не эффективен, как именно для разработки продукта.В том-то и дело, что это всего лишь одна из техник, которые нужны для настоящего бизнес-анализа в продуктовой разработке, в отличие от десятков техник, которые предлагают профильные для продуктов методологии бизнес-анализа, такие как Pragmatic Marketing Framework, например.
Я, если честно, этого не почувствовала. Мне, как раз, кажется, что они даже слишком в общем попытались дать картину - на все случаи жизни.Я как раз и пишу о том, что важно учитывать, что у них замах на всё, начиная от абстрактного названия, а область применимости гораздо меньше.
во-вторых, есть же еще замечательные аналитики - внешние консультанты, хлеб которых именно в том, чтобы проанализировать, найти проблемы, предложить решения, и почему они не могут привлекаться к заказной разработке?,Не знаю, как у вас в Украине, но в России заказная разработка означает то, что подрядчик делает ТЗ на софт и делает софт. До анализа предприятия его тупо не допускают, потому что: 1) Заказчик зачастую не знает, что это нужно делать; 2) У подрядчика экспертиза в разработке ПО, в штате — программисты, а не бизнес-аналитики; 3) Работа может делаться в 2 этапа — один проект по бизнес-анализу/консалтингу, второй, с другим подрядчиком — по разработке ПО. К бизнес-процессам допускают не в заказной разработке, а в системной интеграции (и то не всегда) и в консалтинге.
