Клифф Блезински об аргументах разработчиков

В статье на Гамасутре Клифф Блезински перечисляет кучу аргументов, которыми пользуются разработчики, чтобы отказаться от чужой идеи или, наоборот, продвинуть свою.

Он назвал наверное всё, что я когда-либо слышал на проектных собраниях. То есть статья видимо задумывалась как смешная, но на самом деле там всё чистая правда.

  • «…чтобы отказаться от чужой…» идеи?

  • точно, поправил

  • Name

    Сергей, я не понял, в этом посте вы ничего не подтверждаете?

  • В десятый раз уже не смешно, really.

  • Иван

    В десятый раз подтверждать не смешно?

  • Fullmoon

    Чёрт, отличная картинка.

    Статья интересная, спасибо.

  • Шутка, повторенная дважды — в два раза смешнее.

    А тут пределов вообще нет.

  • Jazz Jackrabbit со скрижалями ни имеет к статье никакого отношения, так? =)

  • я регулярно пользуюсь «future release» когда отклоняю идеи 🙂

  • Mike

    В списке нет стандартной отмазки, которая овнит over 90% геймдизайнеров, заставляя их рыдать от бессилия: предоставьте четкое ТЗ, а после согласуйте с руководством указанные мной сроки.

    Ну и ультемейт: «Ни черновая, ни текущая версия диз. дока не содержат указанной фичи, пожалуйста, и, к сожалению, текущий дизайн проекта не дает возможности быстрой реализации данной идеи, поэтому, пожалуйста обоснуйте ее целесообразность руководству и согласуйте сдвиг сроков релиза.»

  • Любой девелопер при появлении любой фичи должен по-хорошему её отвергнуть немедленно. Это железное правило, и это нормально. У дизайнера должен быть противовес и стимул лучше, проще и понятнее прорабатывать задания.
    По этому в идеале программист должен писать не фичи, а тулзы по ТЗ дизайнера, а дизайнер должен хорошо знать хотя бы один скриптовый язык.

  • Ты какой-то жалкий и примитивный троль

  • Ого. А где такие фимозники работают, чтобы так формулировать отказы? Как быстро закрылись ?

  • Иван

    А тыыыыыыыыыыыыыыыыыы? голосом гай германики

  • Valeriy Nikolenko

    «Любой девелопер при появлении любой фичи должен по-хорошему её отвергнуть немедленно. Это железное правило, и это нормально», — подскажите для необразованных, а почему это так? Что-то странная логика как никак.

  • Deny

    Ну как же, меньше же времени у девилопера по бложкам ходить будет и оставлять умные комменты, ага:)

  • Valeriy Nikolenko

    А серьезно, в рамках рабочего процесса?

  • Mike

    Подозреваю, что месячный доход компании, в которой я работаю, больше, чем доход всех IT-компаний в Харькове вместе взятых.

    Формулировка отказов в бизнес-ключе нужна потому, что за ваш провинциальный выпендреж типа «любой девелопер при появлении любой фичи должен по-хорошему её отвергнуть немедленно», — у нас, обычно, просят не мешать работать геймдизайнерам и маркетологам.

    Геймдев — это бизнес. И аргументы в нем — это аргументы бизнеса, т.е. стоимость решений и согласование сроков.

  • sarman

    Когда я захотел взять нового котёнка, которого также захотела взять моя девочка, мне удалось перехитрить (или убедить)
    её следующим образом — у меня добрая кошка, у неё злая. Если она возьмёт к себе кошку, то у неё будут две злых кошки, а если я возьму, то будут две добрые.

  • Расскажите, пожалуйста о вашем месте работы. Мне очень интересно где дают столько свободы дизайнерам.

  • В рамках рабочего процесса любая фича = деньги, и в 100 случаях из 100 — переработки. Надо кому то такое ? Ну иногда и надо, и на это идут. Но чаще вполне нормальная реакция — отвергнуть фичу.

  • Deny

    Именно поэтому есть компании уровня Valve, а есть уровня Zynga. Есть игры влияющие на все индустрию, а что важнее на культуру, а есть миллион однотипных ферм.

    Я конечно утрирую — в рамках рабочего процесса отношение к новой фиче должно быть критическим, но никак не «отвергнуть немедленно».

  • У вас есть данные о переработках и количестве завёрнутых фичей в Valve. Потому что если судить по их книгами и комментариям все как раз наоборот и отвергается в их играх множество решений и фичей, а переделываются почти каждая вторая. Valve вообще очень полагается на постоянные тесты и рубку выпирающих частей.

  • Mike

    Если бы я хотел частично деанонимизироваться, то сделал бы это еще в первом посте.

    Что же по сути вопроса, то я вижу, что вы не совсем точно представляете нормальное течение процесса.

    — У дизайнеров появляется Идея Не Указанная В Диз. Доке (ИНУВДД).
    — Они передают ее тимлиду с обоснованием.
    — Тимлид выясняет у ведущего программиста (или тех. директора, если проект большой), сколько займет реализация ИНУВДД.
    — Если идею можно реализовать быстро, то на этом все заканчивается — тимлид добавляет задачу в список на реализацию.
    — Если же был назван сравнительно большой срок, то дальше начинаются переговоры тройки Ведущий ГД — Тимлид — Ведущий программист. При этом ГД не учат девелоперов программировать, а девелоперы не обсуждают качество идеи. Цель обсуждения — попытаться оптимизировать идею, сократив время разработки и сохранив ключевые части.
    — По результатам обсуждения Тимлид либо принимает оптимизированную идею к реализации, либо нет.

    В мелких конторах складывается неформальная «дикая» ситуация, когда нет разбирающегося в теме тимлида, его организаторские функции выполняют ведущие специалисты, а судейские — непосредственное руководство. Мне довелось как-то работать в одной такой компании, позже поглощенной более крупной. Так вот, в таких случаях отлично работает бюрократическая схема. Потому как иначе в любом провале ГД закономерно обвиняют разработчиков — это же те отказались реализовывать их ценные идеи. А если из-за реализации идей летят сроки, то… снова виноваты девелоперы, кто же еще? ГД-то свою работу сделали.

    Поэтому, любая идея, которая не может быть быстро реализована, должна во-первых, стать максимально формализованной и подробно описанной, а во-вторых — сроки должны быть согласованы с руководством. В идеале этим всем должен заниматься менеджер проекта. И я не понимаю, почему этот подход вам кажется бюрократическим. В конце-концов, это работа, а не хобби.

  • Спасибо, но зачем вы мне это всё пишете? Название компании было бы более чем достаточно.

  • Deny

    Почитайте внимательно про их «кабальный совет» и процесс разработки. Это было в GD Mag англоязычном, про наши ресурсы не в курсе. Думаю, про HL2 можно сказать, что он более чем на 60% состоит из фич, которых не было в первоначальном диздоке.

    «отвергается в их играх множество решений и фичей» — это называется «вижу что хочу». А не подумали, откуда и на какой фазе разработки это множество фич и решений появилось?

  • компанию назови