Re[8]: Scrum vs Waterfall и его судьба в Yahoo!
От: Gaperton http://gaperton.livejournal.com
Дата: 28.09.07 11:51
Оценка: 8 (1) +1
Здравствуйте, Павел Кузнецов, Вы писали:

G>> Если это именно продукт, который будет продаваться, то тогда не дай вам бог требования от маркетинга прощелкать, и не протестировать на соответствие. У вас в случае разработки собственного продукта по собственным требованиям есть все возможности по грамотному управлению требованиями и для предварительного проектирования.


ПК>Кроме случаев, когда условия рынка меняются: ну не нужна рынку сегодня фича X, запланированная пол-года назад, когда проект начинался, зато нужна фича Y, которую тогда никто не предсказал... К сожалению, это типичная картина:

ПК>

ПК>Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has already made a billion on stock market trading.


Это не типичная картина. Это балшыт. Требования всегда делатся на стопудовые, вероятные, и сомнительные, причем процент последних крайне невелик — и можно заранее заложиться на их изменение. Обсуждаемая проблема решается стратегическим маркетингом. Если вы не имеете понятия, что это такое, не имеете планов хотя бы на 4-5 лет, не имеете роадмапа и стратегии — то тогда конечно проблема лежит за пределами вашего контроля. Почему, черт возьми, мы знали за полгода по принятия приказа Реймана, когда чиновники еще сами этого не знали, что в качестве стандарта телевизионного вещания будет выбран DVB c кодированием H.264? А вот НИИМА Прогресс пролелел — заложился на MPEG2. Почему мы смогли предсказать ситуацию, а они нет? Потому что требования непредсказуемые — зависят типа от наших дурных на голову чиновников? Или все-таки потому, что у нас есть эффективная система технического маркетинга, и мы заранее просчитали вероятность этого варианта как 90%? Да ладно мы — мы то мелочь и ламеры — почему IBM в конце 80-х знал, как будут выглядеть суперкомпьютеры в 2000 году, и заранее изменил стратегию, неторопливо прорабатывая софт и технические проблемы на симуляторах, а Cray тихо загнулся, и был выкуплен Silicon Graphics?

Фаулер зачем-то приводит кривой пример про трейдеров (по ходу, даже у трейдеров есть методики прогнозирования — те, кто ими не пользуется — проигрывает, я не понаслышке знаком с работой трейдера), когда можно сказать прямо реальное положение вещей, не прибегая к дурацким аналогиям. Те компании, которые умеют предсказывать потребности рынка на срок 4-5 лет вперед и больше — зарабатывают деньги на продакт девелопменте. И не обязательно миллиарды — для нишевых продуктов будет поняное дело меньше. Те кто не умеют, не имеют грамотного маркетинга, не покупают маркетинговых отчетов, не следят за тенденциями, и не выполняют прогноза будущего на базе анализа сценариев — плетутся в хвосте и ищут себе разнообразные оправдания, в виде неожиданно меняющихся требований и неудобных процессов разработки. Выигрывает всегда тот, кто успешно работает на опережение — цикл разработки в хайтеке длинный. Впрочем, это условие необходимо, но не является достаточным.

Видите ли, есть две категории людей — одни изменяют мир по себя, другие подстраиваются под окружающий мир. Что важнее — исключить дорогие ошибки в требованиях раньше и иметь точные планы по бюджетам и рискам — или сразу встать лапками кверху и стараться удешевить внесение ad hoc изменений, адаптируясь к бестолковости собственных служб маркетинга? Это взаимоисключающие подходы. В одном случае вы делаете ставку на улучшение планирования, что позволяет вам эффективно управлять портфелем проектов, а не одним, в другом — адаптируетесь к хаосу. Первый подход — эффективнее. На портфеле проектов в long term будет однозначно четкий выигрыш. Второй подход снизит максимальную цену промаха по отдельному проекту, но на портфеле проектов вы получите худший суммарный результат.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.