неуверен что существуют какие то единственно верные классификаторы, но от себя добавлю:
неопределенности
1. Неопределенные качественно цели
2. непродуманные, неэффективные правила и процедуры согласования и управления
3. Заниженные бюджеты, вход в проект слоном
4. Завышенные ожидания
5. Борьба за статусность
6. плохо определенные проблемы бизнеса
7. Неадыкватное описание бизнеса
8.… и т.д.
неопределенностей много, некоторые из них исскуственно создаются интегратором, но управление требованиями как единица стратегии не решает индивидуальну ни одну из перечисленных определенностей. Так же повторюсь важна зрелость бизнеса как заказчика так и исполнителя.
Среди всех стандартов и программ которые собраны у вас в кучу и непонятно каким образом корелируют друг с другом, вы забыли самое главное — то что для зрелых процессов ИТ рамочным является ИСО 12207, уже манипулируя процессами внутри этого стандарта можно охватить все необходимые процессы для конкретного ИТ проекта. и не городить огород (ласкутное одеяло). Спасибо
ага, смысл понятен, тогда возникает вопрос о гарантиях того что эта идея не будет продана сто раз разным инвесторам. По крайней мере задействуя самого стартапера я могу ограничить его в поисках и выкупить его время и старания, а так идея может быть продана, причем это логично, много раз и ее одновременно будут развивать куча других людей. Соответственно увеличивается риск, причем значительно…
Интересный пост, только хочу внести коррективу. Во- первых для того что бы эффективно работали госты и стандарты требуется определенная зрелость бизнеса как у заказчика так и у интегратора, иначе простая трата времени и денег, со зрелостью у нас вообще проблемы. Ваша ситуация изображенная на картинка абсолютна типична на сегодняшний день. Решаться она должна комплексно, процесса управления требованиями недостаточно, Важно уметь применять лучшие практики различных стандартов ситуационно. Так же если вводится в проект понятие управление требованиями, необходимо одновременно вводить управление качеством продукта и управление конфигурациями, иначе требования сведут проект на НЕТ! оч. распространенная ошибка, присутствует в большинстве не успешных проектов.
В том то вся и проблема что идея на миллион практически у каждого найдется, открытый вопрос предсказуемость результата, ресурсы, время отдачи. Мне как инвестору важно защищать свои инвестиции, я неготов пачками скупать стартапы в надежде что хоть какой то из них выстрелит, авантюризм в таких делах должен быть строго нормирован. Большинство идей «на миллион» представляют собой коррекцию существующих бизнесов, инновационных идей практически нету. Важно что бы сам стартапер не только разводил демагогию на тему — «что если сделать все красиво выстрелит прямо завтра» а включался в рабочую группу, представлял ресурсы которые необходимы, рассчитывал свои силы, понимал и брал на себя часть рисков, только в этом случае большинство инвесторов готовы давать ресурсы. Идея это хорошо, хорошая идея это еще лучше, но не факт что даже имея неограниченные ресурсы эта самая хорошая идея выстрелит!
З.Ы. Еще отмечу проблему, которая довольно таки распространена среди стартаперов — оч часто стартаперы не могут объяснить в силу разных причин в чем фишка ихней идеи, простым понятным языком, получается так что есть туманные наметки, есть видение миллионом а понимания элементарных основ напрочь отсутствует.
Есть ли у Вас опыт автоматизации бизнес-процессов хаоса который давал бы на выходе предпринимательские отношения внутри коллектива? Проводите ли вы SWOT или GAP анализ перед началом проекта? или ориентируетесь на данные полученные самим заказчиком?
do cool project
if project not cool killyourself
неопределенности
1. Неопределенные качественно цели
2. непродуманные, неэффективные правила и процедуры согласования и управления
3. Заниженные бюджеты, вход в проект слоном
4. Завышенные ожидания
5. Борьба за статусность
6. плохо определенные проблемы бизнеса
7. Неадыкватное описание бизнеса
8.… и т.д.
неопределенностей много, некоторые из них исскуственно создаются интегратором, но управление требованиями как единица стратегии не решает индивидуальну ни одну из перечисленных определенностей. Так же повторюсь важна зрелость бизнеса как заказчика так и исполнителя.
Среди всех стандартов и программ которые собраны у вас в кучу и непонятно каким образом корелируют друг с другом, вы забыли самое главное — то что для зрелых процессов ИТ рамочным является ИСО 12207, уже манипулируя процессами внутри этого стандарта можно охватить все необходимые процессы для конкретного ИТ проекта. и не городить огород (ласкутное одеяло). Спасибо
З.Ы. Еще отмечу проблему, которая довольно таки распространена среди стартаперов — оч часто стартаперы не могут объяснить в силу разных причин в чем фишка ихней идеи, простым понятным языком, получается так что есть туманные наметки, есть видение миллионом а понимания элементарных основ напрочь отсутствует.