Заинтересовался недавно покупкой электронной читалки. Начал штудировать мегабайтные фолианты отзывов.
Читал в основном плохие отзывы и смотрел на соотношение плохих и хороших. Народ хает в целом всё равномерно, но.
Основные нарекания в основном касаются софта. Народ больше всего хает глюкавое и сырое программное обеспечение.
Ежели функциональность прошивки гаджета мала, но стабильна, разработчик регулярно выпускает обновления, то народ пишет что-то в стиле "да, функциональность слабовата, но апдэйты выходят регулярно, надо брать. Скоро уберут все недостатки. Жди новой прошивки через неделю...".
Народ в данном случае чувствует себя защищённым и такой товар сметает с полок.
Как же работает программная индустрия во всём мире сегодня?
Чтобы не заявляли пиарщики, в действительности повсеместно в разработке используется подход водопада (waterfall approach). Назначается мифический срок сдачи продукта. И вся команда под руководством эффективного менеджмента движется к нему полным ходом. Но движется она в пропасть.
Приближаясь к сроку (а фактически к часу расплаты), руководство, как заколдованное, начинает самозабвенно гнать команду, давить на людей, заставлять их работать сверхурочно, хотя, к гадалке не ходи, успеть к СРОКУ невозможно. Как результат люди измучены, продукт кривой. Зато сдан в СРОК.
Менеджеры хорошие — сдали в срок; исполнители/разработчики плохие — ибо продукт кривой.
А теперь задумайтесь, выжатая, как лимон, замученная команда, разве будет выпускать нормальные обновления?! Конечно нет.
И далее всё идёт по тому же порочному кругу — "продукт — срок — команда плохая — обновление — срок — команда ещё хуже" и т.д.
В таких проектах команда не ловит кайф от производства нового продукта. Она просто обречённо с потухшими глазами продолжает тянуть лямку. Она пытается оправдаться за "свои" ошибки, буквально грызёт землю из горшка, дабы достичь очередного мифического срока. И быть распятой. В такой гнилой атмосфере нельзя выпустить нечто принципиально лучшего качества. Нет. Как правило новая версия продукта получается если и лучше, то не на много.
Дяди в костюмах до сих пор не понимают, что важнее не срок, а стабильное качество малой функциональности с последующими обновлениями.
Идеологи итерационного подхода скоро съедят свой пенис, доказывая свою правоту на бесчисленных примерах, а эффективным менеджерам хоть вагину на голову надень — они твердят как мантру "срок, срок, срок...".
07.04.10 17:45: Перенесено модератором из 'О жизни' — Кодт
Насколько я понимаю как раз когда регулярно выходят обновления происходит по-другому. Команда работает-работает, наступает дедлайн и то, что команда сделал на текущий момент считается релизом. А дальше уже идут обновления.
Здравствуйте, msk78, Вы писали:
M>Сроки сдачи софта (Народное творчество )
...
M>Чтобы не заявляли пиарщики, в действительности повсеместно в разработке используется подход водопада (waterfall approach). Назначается мифический срок сдачи продукта. И вся команда под руководством эффективного менеджмента движется к нему полным ходом. Но движется она в пропасть.
M>Приближаясь к сроку (а фактически к часу расплаты), руководство, как заколдованное, начинает самозабвенно гнать команду, давить на людей, заставлять их работать сверхурочно, хотя, к гадалке не ходи, успеть к СРОКУ невозможно. Как результат люди измучены, продукт кривой. Зато сдан в СРОК.
M>Менеджеры хорошие — сдали в срок; исполнители/разработчики плохие — ибо продукт кривой.
По моему мнению, грамотного ("эффективных" ) менеджера найти даже сложнее, чем вменяемого senior developer'а.
Поэтому большинство компаний довольствуется теми, которые есть.
Здравствуйте, msk78, Вы писали:
M>Дяди в костюмах до сих пор не понимают, что важнее не срок, а стабильное качество малой функциональности с последующими обновлениями.
Дяди без костюмов иногда забывают о том, что деньги появляются не из воздуха а зарабатываются. И выпуская продукт завтра а не сегодня вы теряете деньги, рыночную нишу, динамику бизнеса.
Чтобы показать, что ваше мировоззрение ошибочно достаточно представить что было бы, если бы Microsoft не выпускала IE 4.0 а пыталась бы сделать идеальный броузер. Сейчас бы не было IE. Если они бы применили этот подход к Windows, то сейчас не было бы ни Windows 7 ни самого Microsoft'а.
Это в общем. А если вдаваться в детали и знать практику ИТ отрасли, то можно заметить что проекты без дедлайнов как правило не релизятся никогда.
Здравствуйте, msk78, Вы писали:
M>Сроки сдачи софта (Народное творчество )
Когда часто и планомерно выходят обновления -- это не программисты без дедлайнов, это дедлайн у них каждую неделю с жестким разепом + "метод двух недель".
Здравствуйте, sharpcoder, Вы писали:
S>Дяди без костюмов иногда забывают о том, что деньги появляются не из воздуха а зарабатываются. И выпуская продукт завтра а не сегодня вы теряете деньги, рыночную нишу, динамику бизнеса.
Вы не уловили смысла сообщения. Разработка ведется итеративно, продукт выпускается в установленный срок с меньшим функционалом, но зато без горы глюков. Новый функционал появляется в следующем обновлении, когда заканчивается следующая итерация.
Здравствуйте, sharpcoder, Вы писали: S>Чтобы показать, что ваше мировоззрение ошибочно достаточно представить что было бы, если бы Microsoft не выпускала IE 4.0 а пыталась бы сделать идеальный броузер. Сейчас бы не было IE. Если они бы применили этот подход к Windows, то сейчас не было бы ни Windows 7 ни самого Microsoft'а.
Если бы не выпускали висту, всем бы было только лучше.
Здравствуйте, Nik_1, Вы писали:
N_>Здравствуйте, sharpcoder, Вы писали: S>>Чтобы показать, что ваше мировоззрение ошибочно достаточно представить что было бы, если бы Microsoft не выпускала IE 4.0 а пыталась бы сделать идеальный броузер. Сейчас бы не было IE. Если они бы применили этот подход к Windows, то сейчас не было бы ни Windows 7 ни самого Microsoft'а.
N_>Если бы не выпускали висту, всем бы было только лучше.
По мне так дело можно было закончить на Win2000, да и NT была не плоха. Но кому-то нужны красивые картинки...
Здравствуйте, Mishka, Вы писали:
M>По мне так дело можно было закончить на Win2000, да и NT была не плоха. Но кому-то нужны красивые картинки...
Ну почему же. 2003 очень хорошей вышла.
Здравствуйте, msk78, Вы писали:
M>Чтобы не заявляли пиарщики, в действительности повсеместно в разработке используется подход водопада (waterfall approach). Назначается мифический срок сдачи продукта. И вся команда под руководством эффективного менеджмента движется к нему полным ходом. Но движется она в пропасть.
может и нет никаких других методик?. их выдумали программисты, чтобы отвлечь внимание от своих багов?.
Здравствуйте, Ytz, Вы писали:
Ytz>Вы не уловили смысла сообщения. Разработка ведется итеративно, продукт выпускается в установленный срок с меньшим функционалом, но зато без горы глюков. Новый функционал появляется в следующем обновлении, когда заканчивается следующая итерация.
Чем отличается "выпуск продукта с меньшим функционалом" от "невыпуска продукта вообще" с точки зрения продуктового бизнеса?
Здравствуйте, msk78, Вы писали:
M>Как же работает программная индустрия во всём мире сегодня?
M>Чтобы не заявляли пиарщики, в действительности повсеместно в разработке используется подход водопада (waterfall approach). Назначается мифический срок сдачи продукта. И вся команда под руководством эффективного менеджмента движется к нему полным ходом. Но движется она в пропасть.
В нормальных компаниях срок сдачи не мифический. Это результат огромного количества вычислений человеко-часов по разным параметрам (не с потолка!), учета рисков, задержек, связанных с внешними и внутренними факторами и т.п. Собственно те, кто умеет правильно вести расчеты, планировать задачи и мотивировать персонал, умудряются на софте зарабатывать миллионы, а другие с трудом выпускают один бажный релизик, после которого контора умирает. Все очень сильно зависит от менеджмента и налаженности бизнес-процессов в компании, ну и, конечно, от исполнителей.
Здравствуйте, The Lex, Вы писали:
TL>Чем отличается "выпуск продукта с меньшим функционалом" от "невыпуска продукта вообще" с точки зрения продуктового бизнеса?
Тем же самым, что и покушать плотно, но без десерта, от не есть вообще. 80% пользователей довольствуется 20% функционала. Выпустив надежный и удобный продукт можно удержать 80%, погнавшись за фичами для 20% можно остаться ни с чем.
Здравствуйте, Ytz, Вы писали:
Ytz>Вы не уловили смысла сообщения. Разработка ведется итеративно, продукт выпускается в установленный срок с меньшим функционалом, но зато без горы глюков. Новый функционал появляется в следующем обновлении, когда заканчивается следующая итерация.
Если конкуренты в это же время выдали желаемый функционал, пусть и с некритичными глюками — это потеря клиентов и ниши на рынке.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, msk78, Вы писали:
M>>Заинтересовался недавно покупкой электронной читалки. Начал штудировать мегабайтные фолианты отзывов.
AL>Читалку то купили в итоге? Если да, то какую? И какие впечатления?
Метаюсь между Onyx Boox 60 или Iriver Story.
Onyx Boox 60 просто смели сполок что в Мск что в Спб, ибо "ня", кавай
У Иривера софт зело глюкав Но выглядит изумительно.
вот и думаю, ждать Оникса или взять Иривер?
Здравствуйте, sunsquirel, Вы писали:
S>Здравствуйте, msk78, Вы писали:
M>>Как же работает программная индустрия во всём мире сегодня?
M>>Чтобы не заявляли пиарщики, в действительности повсеместно в разработке используется подход водопада (waterfall approach). Назначается мифический срок сдачи продукта. И вся команда под руководством эффективного менеджмента движется к нему полным ходом. Но движется она в пропасть.
S>В нормальных компаниях срок сдачи не мифический. Это результат огромного количества вычислений человеко-часов по разным параметрам (не с потолка!), учета рисков, задержек, связанных с внешними и внутренними факторами и т.п. Собственно те, кто умеет правильно вести расчеты, планировать задачи и мотивировать персонал, умудряются на софте зарабатывать миллионы, а другие с трудом выпускают один бажный релизик, после которого контора умирает. Все очень сильно зависит от менеджмента и налаженности бизнес-процессов в компании, ну и, конечно, от исполнителей.
Ну, это понятно, что не мифический Я его назвал мифическим, так как в него зело редко укладываются, несмотря на то, что не один работник умственного труда пашет как раб на галерах.
Здравствуйте, Ytz, Вы писали:
TL>>Чем отличается "выпуск продукта с меньшим функционалом" от "невыпуска продукта вообще" с точки зрения продуктового бизнеса?
Ytz>Тем же самым, что и покушать плотно, но без десерта, от не есть вообще. 80% пользователей довольствуется 20% функционала. Выпустив надежный и удобный продукт можно удержать 80%, погнавшись за фичами для 20% можно остаться ни с чем.
Мы все еще о продукте говорим с конкретно к выпуску анонсированными фичами, или же о целой линейке продуктов или скорее "линейке версий", каждая из которых "будет потом и, возможно, еще потом — если и это не успеем"?
80% пользователей предпочтут подождать "полнофичевый" продукт — или же купить с аналогичной функциональностью, возможно не такой полной "заявленной", но тем ни менее полной в данный конкретный момент. Ну, может 80% я и утрировал: процентов 95-99.
А если продукт заказной и мы к его выпуску придем и скажем заказчику: "вы знаете, мы тут все фичи не успеваем..." — доделать этот заказ, скорее всего, получится, но в 80-99% случаев заказчика мы потерям. И в 100% случаев приобретем соотв. репутацию.
Аналогия с "покушать плотно, но без десерта"? Да вот запросто: вот у нас тут целый ряд совершенно одинаковых забегаловок — продуктовых компаний — мы, потребитель, можем покушать и там, и сям — нам, в принципе, особой разницы нет: функционал на самом деле везде примерно одинаков, но отличается только фичами — десертом, ага. И вот пришли мы пообедать — таки выбрали — а нам там говорят: "Ничего ведь что мы вам все то же самое — отличная ведь еда! — но вот без нашего десерта (за которым вы, собственно, и пришли, ага) — но ведь покушаете!" (к) Какой процент пользователей, желающих "просто покушать", но имеющих выбор, даже не думая особо уйдет либо сразу, либо в следующий раз пойдет к соседям — попробовать их десерт, потому что у тех он может таки наверняка есть, а не просто анонсирован.
Мы еще о продуктовой стратегии говорим или уже просто перешли к обычному неуспеванию реализации заданного количества фич программистами? С каких это пор программисты оценивают полезность тех или иных 80/20% фич для продукта, если они не смогли даже точно оценить сроки выполнения собственной работы?
)
) менеджера найти даже сложнее, чем вменяемого senior developer'а. 
