Читал в основном плохие отзывы и смотрел на соотношение плохих и хороших. Народ хает в целом всё равномерно, но.
Основные нарекания в основном касаются софта. Народ больше всего хает глюкавое и сырое программное обеспечение.
Ежели функциональность прошивки гаджета мала, но стабильна, разработчик регулярно выпускает обновления, то народ пишет что-то в стиле "да, функциональность слабовата, но апдэйты выходят регулярно, надо брать. Скоро уберут все недостатки. Жди новой прошивки через неделю...".
Народ в данном случае чувствует себя защищённым и такой товар сметает с полок.
Как же работает программная индустрия во всём мире сегодня?
Чтобы не заявляли пиарщики, в действительности повсеместно в разработке используется подход водопада (waterfall approach). Назначается мифический срок сдачи продукта. И вся команда под руководством эффективного менеджмента движется к нему полным ходом. Но движется она в пропасть.
Приближаясь к сроку (а фактически к часу расплаты), руководство, как заколдованное, начинает самозабвенно гнать команду, давить на людей, заставлять их работать сверхурочно, хотя, к гадалке не ходи, успеть к СРОКУ невозможно. Как результат люди измучены, продукт кривой. Зато сдан в СРОК.
Менеджеры хорошие — сдали в срок; исполнители/разработчики плохие — ибо продукт кривой.
А теперь задумайтесь, выжатая, как лимон, замученная команда, разве будет выпускать нормальные обновления?! Конечно нет.
И далее всё идёт по тому же порочному кругу — "продукт — срок — команда плохая — обновление — срок — команда ещё хуже" и т.д.
В таких проектах команда не ловит кайф от производства нового продукта. Она просто обречённо с потухшими глазами продолжает тянуть лямку. Она пытается оправдаться за "свои" ошибки, буквально грызёт землю из горшка, дабы достичь очередного мифического срока. И быть распятой. В такой гнилой атмосфере нельзя выпустить нечто принципиально лучшего качества. Нет. Как правило новая версия продукта получается если и лучше, то не на много.
Дяди в костюмах до сих пор не понимают, что важнее не срок, а стабильное качество малой функциональности с последующими обновлениями.
Идеологи итерационного подхода скоро съедят свой хуй, доказывая свою правоту на бесчисленных примерах, а эффективным менеджерам хоть пизду на голову надень — они твердят как мантру "срок, срок, срок...".
ДОВЕСОК
Именно итеративные подходы советуют сдавать часть функционала, если вы не успеваеете. Чтобы не получилось так, что вы часть функционала сдать по-просту не можете, потому что продукт будет не пригодным к использованию (например, машина без руля), необходимо общаться с заказчиком, выяснять основной функцианал. Причём, действительно основной, а не так, что "серая звёздочка по центру — must be. (А у представителя заказчика в подсознании "трусики жены напоминает")"
Надо уметь работать с заказчиком, договариваться...
Хороший пример есть в книжке Кента Бека про космопорт на примере продажы билетов.
Функционал вполне конкретный — читалка, а не 20% разного. Качественный плэер в ридере для людей — второе. А ежели ридер не выполняет по-человечески базовой функциональности, то это, мягко говоря, плохо.
Прототипом для статейки были Оникс Букс и Иривер Стори. Букса уже нет на полках. Смели всю партию в МСк и СПб. Народ требует. Show must go on.
Иривер до сих пор лежит, хотя время выхода продуктов приблизительно одно.
Почему? Да, потому что читалка Оникс выполняет свои прямые функции и выполняет их хорошо. Основные нарекания к ней — к побочному функционалу.
Иривер Стори — совсем другая история
Хают как раз-таки исключительно глюкавый основной функционал — чтение и, как следствие, книга, подчёркиваю, книга, слабо пригодна для чтения. Народ берёт, да, но не так интенсивно.Вы для чего покупаете книгу? Лазить в и-нете или слушать музыку? Читать, конечно же! Так что Iriver Story, Reading — failed.
И, да, кстати говоря, 80% пользователей как раз-таки предпочтут брать классную читалку, чем ждать рюшечек-игрушечек с кривым базовым функционалом (see Оникс Букс zum Beispiel). Полный функционал ждут в основном гики.
До программистов ещё дело не дошло. Я пробовал выразить иную мысль. Ведать не сильно удачно.
Попытаюсь иначе
В долгой беседе исполнителя и заказчика (как правило представителя заказчика), заказчик говорит, например: "DJVu формат — обязательно должен быть, это для нас важно". Но в действительности таких "очень важно для нас" вы на протяжении беседы с заказчиком упомянули уже очень много. И "плэер очень важен для нас" (жена босса любит), и меню в клеточку "очень важно" и т.д.
В этих "очень важно(must-be)" перемешано всё, начиная от действительно необходимого функционала, без которого нельзя и кончая второстепенным, всякие звёздочки, плэеры...
Так вот наша задача, не быть пассивным перед заказчиком, а пытать его, выяснять, быть дотошным, любопытным.
Наши же эффективные менеджеры в своём большинстве просто слепо следуют тому, что говорит заказчик, не пытаясь вникнуть в его бизнес-процесс.
Как следствие, может быть приблизительно следующее:
Выходит продукт.
А заказчик вам говорит: "#$%@$, почему нет поддержки FB2!!! Без этого формата это просто груда железа! Я же вам говорил!"
Вы: Ну, мы сделали важные фичи... ДэЖаВю...
Заказчик: Мля, Вы же не спросили! Я бы вам сказал, что да, ДэЖаВю важная и звёздочка в полэкрана важна! Но воспроизведение FB2 — это всё. Я думал, вы это понимаете и без меня!!!
Программисты — непосредственные исполнители. Они ничего не решают. Решаете вы, как руководитель...
Поэтому, если заказчик занимается нефтью и при этом требует в приложении кнопку в пол-экрана с надписью "Сиськи", то имеет смысл насторожиться и переспросить, выяснить зачем, как это влияет на его бизнес-процесс.
ДОВЕСОК 2
gandjustas (Rsdn)1. Тем что продукт с меньшим функционалом можно продавать не хуже продукта с полным функционалам. Увеличиваются только риски потери рынка из-за более полнофункционального продукта конкурентов. Это именно риски, а не факт.
Поэтому имеет смысл выпускать продукт в срок, хоть и с меньшим функционалом.
2. Тут есть некоторый критический функционал, без которого продукт не имеет ценности вообще. То есть без него выпускать продукт бессмысленно. Не вышел бы iPhone, если бы он не умел звонить, несмотря на все старания маркетологов.
Обычно критический функционал составляет довольно малую часть всего предполагаемого функционала, по моим наблюдениями не более 20%.
Комментариев нет:
Отправить комментарий