Идеальный шторм. Постмортем неанонсированного проекта.

    Сегодня мы шли с Вовчегом, нашим гуру гейм-дизайнером, брать ему кредит на покупку квартиры и обсуждали наш текущий проект.

    Сошлись на том, что удивительно, что нас до сих пор обоих не уволили. Мы умудрились допустить огромное количество очень существенных ошибок: я — по управлению, Вовчег — по дизайну. Проект еще не закончен, но уже можно сделать определенные выводы.



    Проект длится 8-ой месяц, будет длиться со всеми многочисленными платформами еще 2-3 месяца. При этом мы сейчас четко видим, какие именно ошибки стоили компании 2-3 месяца разработки и десятки тысяч долларов (надеюсь, что счет на сотни тысяч не пойдет).

    КОМАНДА

    Главная ошибка в управлении моя — это ошибка выбора команды:
    — Ставка на молодую команду, которая так и не смогла, по сути, «развернуться» на этом очень сложном во всех аспектах проекте.
    — Связка молодой PM + опытный PMA, которая провалилась сразу. Мне показалось, что я смогу реализовать то, что, мне тогда казалось, работало в Нивале.
    — Мы фатально ошиблись с оценкой сложности задачи по гейм-дизайну, что привело к тому, что связка дизайнер-программист оказалась удаленной, что почти катастрофа для проекта нашей сложности.

    Мне потребовалось целых 2 месяца, чтобы осознать, насколько плоха ситуация, меня только совсем чуть-чуть оправдывает, что из этих 2 месяцев 2 недели я был в отпуске в тёплом месте. То, что я увидел после отпуска, было катастрофой. Я понял, _насколько_ категорически и масштабно я облажался. Кажется, еще никогда раньше я не ошибался ТАК круто.

    Исправление заключалось в полной смене всего core team и концентрации его в одной комнате минского офиса. Только после этого проект фактически начался с той скоростью, с которой он должен был начаться 2 месяца назад.

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

    Я в очередной раз убедился, что в сложной ситуации я не способен исправить ситуацию PM директингом. Единственный способ, как я могу решать такие проблемы на проектах, — это решать их собой. Закрывать дырки собой. К сожалению, я не оказался лучше, чем все другие люди в этом аспекте.

    Ошибка Вовчега в дизайне была в том, что нельзя было вбрасывать в удаленную команду не достаточно проработанную идею. Мы очень хорошо увидели, что происходит с проектом, когда команда делает, то чего НЕ понимает и НЕ принимает. Никто из команды даже и близко тогда не понимал, что же мы конкретно хотим сделать. Реально, даже близко не понимал! При этом на протяжении недель видя, с одной стороны, какая неиграбельная фигня есть в билде, с другой — разрыв с тем Vision-ом, который мы с Вовчегом хотим реализовать.

    3 очень важных вывода по этой части, которые, конечно, выглядят очевидными.
    — Самые сложные вещи буду делать я сам, только сам. Когда у нас появится другой крутой пм, это изменится.
    — Core team сложных проектов будет _всегда_ находиться в одной комнате одного офиса. И будь я проклят, если я это еще когда-нибудь попытаюсь нарушить.
    — Никогда никогда я больше не буду «выбрасывать людей в воду с надеждой, что они всплывут», я буду «учить плавать аккуратно и последовательно», это касается построения команд и развития пм-ов.
    — Нельзя делать что-то, если у тебя нету хотя бы 1 человека, который поддерживает и понимает идею, у нас этого тогда не было.

    КАК РОЖДАЛСЯ ИДЕАЛЬНЫЙ ШТОРМ

    Мы очень сильно напортачили с Вовчегом в сущностях, где мы с ним считались опытными ребятами – Pre-production и Vertical Slice (reference playable его еще называют).

    Мы отлично прошли концепт фазу. У нас был хороший и четкий vision. Мы очень долго и многими людьми думали над концептом. Не скажу, что мы придумали нечто невероятное, но концепт фаза была пройдена действительно хорошо. Был сделан хороший задел.

    Четкий и правильный vision был единственным лучиком надежды. Осознание, что есть цель, что она достижима, но мы пока не знаем четкого пути, как туда прийти — это то, что спасло проект. Если б этого не было, был бы типичный Death March Project, или, как я это называю, — Disaster Project. Таких проектов за 8 лет компании было много. Я пока не научился их избегать. Чёткая концепт фаза позволила нам удержать опоздание в рамках 2-2.5 месяцов.

    Pre-production был полностью провален. Несмотря на то, что формально какие-то документы делались, какой-то (неиграбельный) Vertical Slice развивался, какие-то планы писались, рапортовалось о том, что сняты какие-то риски, – фактически всё это было fake-ом. Главного не было сделано – определенности того, что же мы делаем. Без этого у планов и гдд не могло быть реального наполнения.

    Всё это привело к катастрофе.
    Мы начали продакшн.


    На проект пришло много людей. Резервы уже были съедены. Вместо того, чтобы сконцентрировано решать Главные проблемы проекта – получить настоящий Vertical Slice, внести Определенность в ключевые фичи — нам пришлось сильно распыляться на то, чтобы обеспечивать работой большую команду. Мы давили на программиста движка, чтобы изменения вносились еще быстрее. Когда уже большая продакшн команда производила результаты, интеграция этого всего дела в билд только усугубляла проблему, мы видели, что совсем ничего не работает. Приходилось многое переделывать, люди выли от этого, спираль проблем закручивалась.

    Изменения, которые мы вносили в движок, стали стоить очень дорого. Это уже стало очевидно для внешних людей, не могут совсем простые изменения стоить дней. Значит, что-то не так с системой внутри. Новый лид программист проекта Димусик, к сожалению, не осознавал, насколько в глубокой заднице мы тогда оказались.

    Я оказался в ситуации, когда у меня фундаментальные проблемы были везде. В дизайне – мы не знаем, что мы делаем. У нас нет ничего кроме vision-a и плохого Vertical Slice билда. У нас уже какого-то черта продакшн и куча людей, которые озлоблены от того, что приходится делать много изменений, которым нужно давать задачи, но нормально продуманных задач нету. У нас нарисовано много арта, но качество многих элементов было далеко от того “Wow”, на которое мы рассчитывали.

    Чтобы хоть как-то это решать, нам нужно было менять Vertical Slice. Я понимал, что еще чуть-чуть и шансов успеть в срок не будет. Успеть в срок — это значит выйти одновременно с большим релизом на американском ТВ. Это был настоящий deadline, который нельзя было двигать.

    В этот момент ко мне приходит лид программист и говорит, что нужно остановить любую работу и выкинуть 80% всего code base-а. Что это единственное решение. Мы оба понимаем, что это правда. В лучшем случае, если мы будем переписывать текущие сложные элементы в самом простом виде, например, полный рандом, вместо текущего сложного АИ, мы сделаем это всё за 2 недели. Мы вернемся к рабочему билду через 2 недели. Мы понимали, что мы вернемся к прежней точке скорее через месяц. И это всего лишь позволит нам вносить хоть какие-то изменения в проект.

    Помните, я недавно рассказывал про то, что проект подобен пьесе, где задача менеджера это «впихнуть невпихуемое» и make everyone a winner.

    Мой проект стал ТРАГЕДИЕЙ. Моей личной трагедией. Трагедией команды и всей нашей компании.

    Я четко осознавал, что мы опаздываем _минимум_ на 2 месяца и что мы фактически находимся в начале пре-продакшена.

    Перенос deadline-а на 2 месяца, по большому бренду, где у нас большие гарантии по revenue, — это была КАТАСТРОФА.

    ЖИЗНЬ ПОСЛЕ КАТАСТРОФЫ

    Только когда на проект вернулись реалистичные сроки, когда мы четко осознали, что мы находимся в начале пре-продакшена, когда за дело взялась очень опытная и крепкая команда, сидящая в одной комнате, проект начал продвигаться очень быстрыми темпами вперед. Идеи генерировали уже не один дизайнер, а вся команда, то есть пм, дизайнер, художники, програмисты, позже — qa. Изменения вносились очень быстро. Проект менялся очень быстро.

    Грамотный лид программист Димусик тогда дочитывал Совершенный Код МакКоннела и смог эффективно внедрить изложенные там идеи, была сформулирована очень четкая и очень простая архитектура из 3 state-ов (вместо сложной и запутанной из 10-20 state-ов). Эти 3 state-а стали ядром движка. Все, начиная от меня, заканчивая QA, знали это state-а.

    Я впервые тогда увидел сам, что правильно задав вопросы заказчику (дизайнеру) можно серьезно помочь дизайнеру лучше понять, что он хочет, можно помочь найти решение намного проще и лучше.
    Мы внедрили скриптовую систему на многих уровнях проектах, настоящий data driven подход. То, что занимало 2 недели и 10 итераций работы дизайнер-программист, сейчас делалось за 3 дня программистом, сразу верно и почти без багов, а дизайнер потом сам очень легко и быстро настраивал фичу за пару дней. Это было настоящим шоком для меня.

    Уже позже мы узнали, что Нивал делает то же самое для скриптования магии в Аллодах Онлайн. Хардкод 200 заклинаний в героях 5 — это был старый неэффективный подход, от которого мы так же ушли.
    Это было 10x. Все мы знаем, что лучшие люди — это 10x средних. Сейчас я смог это очень точно измерить, и действительно это было 10x. Это снова было шоком для меня.

    ТЕМНАЯ СТОРОНА AGILE

    Я и раньше хорошо понимал, каким злом может быть Agile. На проекте я на конкретных примерах увидел, НАСКОЛЬКО большим ЗЛОМ может быть Agile в неправильных руках. Некоторые фичи мы делали в agile стиле, то есть, честно говоря, не сильно думая, что мы хотим и что будет меняться (потом будут итерации для изменений).

    Когда в определенный момент нам предстояло сделать большой следующий пак изменений, лид программист Димусик повёл себя совсем по-другому. Мы оба поняли, что должен быть путь лучше.

    Димусик за 2 дня не написал ни 1 строчки кода. Он очень много и долго говорил с дизайнером, они обсуждали и продумывали разные варианты, Димусик предложил другой способ реализации фичи, который был кардинально проще, порождал заметно меньше проблем, но который, по сути фичи, делал то же самое. Дима рисовал схемки, чертил таблицы разных вариантов взаимодействия, очень детально прорабатывал все нюансы. К счастью, у меня хватило ума понять, что это не «2 дня ничегонеделания», а наш будущий успех.

    После этих 2 дней Дима за 1 день реализовал эту уже простую фичу. И когда она заработала с самой первой итерации, совсем без багов (разве что только с 2 очень мелкими помарками, которые скорее были доработками) вся команда была в шоке. Это было фиксировано 3 дня, из которых только 1 день писался код, это была 1 итерация, вместо 2-3-4 недель и 3-5-10 итераций.

    Для всех стало очевидно, насколько лучше может быть старый добрый забытый(?) всеми(?) Waterfall подход. Только после этого я по настоящему, на своей крови, осознал, насколько важно всегда придерживаться едва уловимого баланса между Agile и Waterfall подходами. Я говорил об этом и раньше, на прошлой КРИ, например, но только сейчас я увидел настолько вопиющий пример.

    «Keep it simple» слоган Димусика, жесткая и очень простая архитектура, отказ от Agile во многих элементах проекта, скрипты и data driven подход практически во всех элементах проекта — это было фундаментом возрождения проекта.

    ГДЕ ЖЕ МЫ

    Я уже потратил на портативный проект для многих платформ 8 месяцев и 50+ человеко-месяцев (умножите на стоимость человека-месяца и получите стоимость). На проекте работают лучшие люди компании, максимум людей, которых я смог «эффективно занять» — это 4 программиста, 4 художника, 2 выделенных команды.

    Сейчас 23:29, четверг 12 февраля. Мы вчера получили 6 разгромных альфа плей-тестов. Никогда еще за все 5 лет и 20+ проектов плей-тесты не были настолько плохими. Все игроки едины в том, что «ничего не понятно, что происходит на экране, не ясна цель, скучно выполнять одни и те же действия».

    Смешно говорить, но мы фактически не прошли альфу, мы уже очень многое сделали по бете, у меня осталось 3.5 недели или 21 рабочий день. Мы в спешке доделываем сабмишн материалы на все ключевые Tier1 американские каналы, иначе мы просто пропустим «своё окно» на запуск.

    Я знаю, что мы опоздаем. Невозможно за 3.5 недели сдать проект, когда еще не пройдена альфа стадия. Мы опоздаем на срок от 1 до 3 недель. Мы будем биться за каждый день, делать всё, чтобы приблизить релиз хотя бы на день, на каждый из дней.

    СЕГОДНЯ ИСПОЛНЯЮТСЯ МЕЧТЫ

    Вовчег 4 часа назад исполнил нечто очень важное для себя — купил хорошую квартиру в Минске, и сейчас, когда я пишу эти строки, Вовчег дома пишет новый пак изменений, которые мы условно называем “Death Changes” (до этого еще был “Mad changes pack”), которые будут дешевыми и которые сильно улучшат игру. Несмотря на разгромные альфа-ревью, мы верим, что есть изменения, которые будут хорошими и дешевыми.

    Наша вера это наш лучик надежды, это наш Vision, мы прошли долгий путь в поисках цели, и мы чувствуем, что мы уже очень близки. Мы уже почти пришли. Наша интуиция подсказывает, что мы уже очень близко. Кажется, мы уже почти Счастливы.



    Есть ли жизнь после deadline? Я не знаю.
    Но я точно знаю, что буду гордиться нашей Игрой, гордиться командой, которая прошла этот путь, я знаю, что, когда мы с Вовчегом вернемся из Сан-Франциско, прослушав Кадзиму и его «Solid Game Design: Making the ‘Impossible’ Possible», мы сделаем наш ‘Impossible’ Possible – мы сделаем наш новый проект намного лучше текущего.

    Денис Войханский,
    Executive Producer, where, at Reaxion, we create games we want to play ourselves.

    P.S. Возможно, после того, как мы анонсируем нашу игру, у вас будет шанс оценить, то, что мы создавали все эти месяцы.
    Поделиться публикацией

    Комментарии 96

      +10
      + за публичную самокритику.

        +10
        Хорошо написано, спасибо. Всплыли в памяти знакомые чувства «потерянных возможностей», когда понимаешь как нужно было делать :).
        ИМХО только так становятся настоящими профи.
        Удачи.
          +3
          Спасибо парни,
          Рядом новый проект сча начинается, я крепко задумался что очень не хочу той же задницы там, задумался что нужно сделать.

          В общем очень рекомендую делать такие ревью.
          Weekly, monthly, в конце проекта.
            0
            Сильно.
            Читал с удовольствием))
            +1
            Тоже понравилось, спасибо за опыт. Одно но — большое количество англицизмов, как колючки разбросанных по тексту, я понимаю — специфика отрасли не позволяет всё переводить дословно, но тут я даже не сразу догадался русский писал, или это переводная статья)
              +1
              во-первых: спасибо автору, заставило задуматься и перепроектировать свою систему контроля и управления проектами, хоть и занимаюсь веб-девом.

              KAFLAN: а по поводу «англицизмов» — тоже автору спасибо, я не имею технического образования (занимаюсь бизнес-процессами, то чего до конца не сделают технари) и мне достаточно тяжело тоже понимать то, что для многих, возможно, сегодня дают в университетах, а вот такие статьи помогают разобраться с хотя бы некоторыми терминами.
            +4
            Отличная статья. Всё честно, правильно и применимо к слишком многим в геймдеве. У нас были все те же самые проблемы и на больших и на маленьких проектах.
            Жалко только, что слишком мало кто из игровых менеджеров может так откровенно и честно все написать, а все пишут постмортемы в стиле «все были хороши и все получилось, как задумано».
            Выложи на dtf, пусть завидуют откровенности.
              +3
              Оно кстати не токо к гейм деву очень хорошо относиться :)
              Возле меня сейчас молодая команда во главе с опытным дядькой сайт ваяют… Я уже вижу и знаю что они опоздают на 3-4 недели. Они тоже видят, но боятся вот такой вот отрытой критики самих себя в открытую.
                +1
                Да, вернутся в нормальный режим работы, когда есть план в которым все верят — без этого никак. И это обычно очень сложно даётся.
                +1
                Спасибо чув.
                Выложил на дтф — но он там кажется мертв, нормальный народ там уже не тусит, по крайней мере в дискуссии не вступает.
                +16
                Ты — мужик.
                  +4
                  Вовчег и Димусик тоже мужики.
                  «Keep it simple» — всегда спасает проекты. Этот принцип вообще в многих проектах нужно изначально считать идеологией
                    +1
                    Вот и ободряющая картинка
                      +3
                      ну только бы ещё KISS все понимали правильно — это не значит не делать сложных вещей, это значит делать сложные вещи простыми способами.
                    0
                    Замечательная статья :) Я думаю, она поможет ещё ни одному начинающему девелоперу, который хочет работать «отдельно» от крупных компаний и творить что-то своё.
                      +3
                      Зря закрытый топик сделал — так он не попадет в ленту хабры и тысячи людей, кто читает только ленту захабренных, ее не прочитают.
                      Лучше убрать замок и запись сразу попадет в rss захабренных :)
                        0
                        Исправил, спасибо за хинт!!!
                          0
                          Всегда пожалуйста :)
                          Я был удивлен, когда узнать, как много народу читает rss хабры. А закрытые топики в него не попадают.
                        –9
                        Зае… л не интернационал в ПО...!
                          +9
                          Жаль что нельзя удалить, не там написал :) (упс)
                          +5
                          Ну вобщем читая это понимаешь, почему в последнее время столько говна в играх. Все эти публичные альфа-бета тесты, закрываемые патчами после релиза. Вы будете гордится этой игрой? Ну флаг вам в руки…
                            +2
                            Публичных тестов не будет.
                            Это всё были корридорные тесты + тесты на знакомых.

                            Мы не ПС рынок. Это на ПС делают как вы говорите.

                            На мобайл всё _очень_ жестко — есть NSTL, есть тестирование Verizon-a (на примере Verizon-a) — и даже если вы каким-то чудом с багом пройдете через тестинг — то 1-2 звонка в суппорт юзвера Verizon-a и игру снимут с продажи, им репутация очень дорога, им так проще, разбираться что там реально произошло они особо не будут.

                            Так что качество это для нас не пустой звук.
                            А это _очень_ большая проблема :)

                            Хотя за 5 лет уже без проблем проходим все эти тесты.
                              –1
                              > то 1-2 звонка в суппорт юзвера Verizon-a и игру снимут с продажи

                              чьи звонки тут имеются в виду?
                                0
                                пользователя, юзвера, покупателя игры.
                                  0
                                  ой, слово, пропустил. кто такой юзер я знаю, конечно.

                                  меня другое смутило: ведь так можно прикинуться пользователем (да, чего там, просто стать легальным пользователем) игры, которую сделал конкурент. и завалить Verizon звонками о том, что игра не работат, что играет падает и т.д. разве не так?
                            +2
                            Спасибо за статью. Прочитав задумался над процессом разработки своих проектов.
                              +3
                              >> Грамотный лид программист Димусик тогда дочитывал Совершенный Код МакКоннела и смог
                              >> эффективно внедрить изложенные там идеи

                              Книга эта, если честно, не сказать чтобы кладезь идей… У нее немного другая направленность — не напичкать идеями, а привести в порядок все, что у программиста накоплено из опыта. Ну да ладно.

                              За статью большое спасибо. Многое напоминает собственный опыт :)
                                +3
                                прочтитала на одном дыхании!
                                с нетерпением будем ждать вашей игры.
                                  +1
                                  на dtf нет желания перепостить?
                                    +2
                                    Ничо не понял, т.к. не фелолог, но читается на одном дыхании, прям экшн какой-то!

                                    :)
                                      +1
                                      Спасибо. Стараюсь. Тренируюсь. Игры всё таки делаем. Ну и по должности положено уметь воздействовать на людей :)
                                        0
                                        Желание то есть, прошлый раз мою статью «Темная сторона Agile» не захотели (вернее не ответили даж).
                                        Напишу конечно, но не уверен что ответят вообще.
                                        0
                                        Не соглашусь по теме Agile. Это семейство методологий не требует тупого написания кода вместо предварительного обдумывания. Суть в том, что команда сама решает когда ей нужно продумать что-то изначально подробно, а потом делать, а когда можно начинать делать, а возможные изменения вносить по ходу.

                                        Вы как раз и работали в Agile, применяя то подход предварительного полного продумывания, то кодирования с учетом непрерывного изменения (аля XP).

                                        Противопоставление Waterfall и Agile уместно на более высоком уровне, то есть на уровне разработки большой части системы, а не конкретной фичи.
                                          +5
                                          Я Agile и Waterfall воспринимаю очень hi-level. (на прошлой КРИ об этом говорил — посмотрите ссылку в этой статье).

                                          Agile и Waterfall для меня, подчеркну — для меня, это то, как вы считаете вам лучше достигать эффективности —

                                          1.Agile. «быстро и почти без процесса сделать маленькую штуку крутым челом, и затем с заказчиком который рядом итеративно довести до релиза» или
                                          2.Waterfall "_очень_ хорошо и долго думать, 2 дня думать, за 1 день и _1_ итерацию реализовать, не особо важно чтобы чувак был крутой или чтоб заказчик был рядом".

                                          Есть разные задачи, разные люди и команды, когда нужно применять разные подходы.

                                          Что бы вы не выбрали, ваши плюсы это одновременно и ваши минусы, в Agile ваш минус это бОльшее количество итераций, в Waterfall подходе — вы вероятно много думаете где можно было б не думать, вы тяжелее отходите от плана.

                                          Есть задачи когда вы не сможете применить Agile подход, есть задачи когда вы не сможете применить Waterfall подход.
                                          Есть команды и заказчики с которыми вы не сможете применить Agile подход как бы вы не стремились, тоже самое с Waterfall-ом.

                                          Любой проект это всегда Waterfall hi-level, уж не знаю, понимает это кто-нибудь или нет. Любой проект состоит из последовательности больших жестких этапов (concept, preprod, production, post-production), а это Waterfall.
                                          Agile, итерации — оно внутри этапов. Это MSF модель. И она правильная.

                                          Я это всё к чему — очень опасно податься хайпу относительно Agile. Agile это безусловно правильные идеи. Просто не нужно считать что всё остальное это отстой. Нужно понимать что как и почему работает, глубоко, замечу, нужно понимать. Нужно выбирать то что работает конкретно для вас, для вашей команды, для вашей текущей задачи, для вашего заказчика и его текущего настроения (да, даже так бывает!).

                                          Ну и зануда же я :)
                                            +1
                                            Большее количество итераций в Agile — это совсем не минус, а то ради чего это все было задумано.

                                            Для сравнения, используя Waterfall на годовом проекте любая ошибка может стоить еще одного года разработки. Изменения, которые накопились в голове у заказчика, будут реализованы только в следующем году, иначе вы сорвете текущий план. Чтобы этого избежать как раз и нужно использовать большое количество итераций с целью повышения прозрачности разработки и получения сходящегося к цели процесса.

                                            Полностью согласен с тем, что всему свое место. Но не понимаю зачем говорить, что Agile ацтой там где его и не имеет смысла применять?

                                            Что касается MSF, то не вижу тут какого-то открытия. Прежде чем что-то делать, нужно понять что, подготовиться, провести исследования. После того как выполнена основная работа, можно заняться вопросами маркетинга, продажами и т.п.

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

                                              Можете четче сформулировать в чем мы с вами расходимся во мнениях?
                                              Мне просто кажется что позиции наши очень близки.

                                              Мы оба с вами считаем что каждому своё место.

                                              >> Но не понимаю зачем говорить, что Agile ацтой там где его и не имеет смысла применять?

                                              Перечитайте статью, я говорил что мы применяли Agile там где Waterfall подход сработал бы лучше.
                                                +1
                                                Судя по описанному, то что у вам происходило, было не совсем Agile, использование этого магического слова не отменяет необходимости думать и проектировать. А то что вы называете Waterfall — и есть нормальный подход к разработке — анализ, проектирование, разработка, тестирование.

                                                Сакральный смысл Agile в том и состоит, что каждая итерация — это маленький Waterfall с законченной фичей как результат, и поэтому если вы ошиблись на стадии анализа, вы потеряли только 1 итерацию, а не про---ли весь проект как при большом Waterfall-e.

                                                Почитайте еще МакКоннела, там об этом хорошо написано.
                                          +1
                                          > гуро гейм-дизайнером
                                          > гуро
                                          Гуро — это несколько другое…
                                            +3
                                            В слово «гуро» я вкладываю то что обычно понимают под этим люди, «крутого чувака».

                                            Спасибо за ссылку, интересно!
                                              +3
                                              «крутой чувак» — это гурУ.
                                                +2
                                                чОрт!
                                                Спасибо, исправился!
                                                +2
                                                «Гуру, в строгом смысле, является не учителем, передающим какую-либо информацию, а тем, кто направляет и питает Пробуждение ученика. Часто словом «гуру» называют профессионалов, виртуозов, мастеров своего дела.»
                                                ru.wikipedia.org/wiki/%D0%93%D1%83%D1%80%D1%83
                                                  +1
                                                  Вот именно :)
                                              +1
                                              по-моему всем уже насрать на что то игра — должна быть в первую очередь игрой. И вопрос «что» всегда должен быть основнопологающим над «как». Собственно, «как» появляется из опыта. Сделать без этого опыта то что задумывалось изначально — анрил.
                                                –2
                                                я к тому что у вас уже не получится то что хотелось.
                                                  +1
                                                  Возможно всем и насрать.
                                                  Но только не команде.

                                                  Мы, надеюсь, хорошо понимаем что мы делаем ИГРУ прежде всего, а не техно-демо с артом звуков и левелами.
                                                  +2
                                                  Кстати Идеальный шторм фильм отличный. Его нужно показывать в обучающих целях для небольших команд в любой сфере деятельности.
                                                    0
                                                    Согласен. Соб-на я поэтому такую аналогию и сделал, фильм классный и полезный!
                                                    –5
                                                    Во первых, что за игра?
                                                    Во вторых, много воды и ничего конкретного. У меня сложилось впечатление, что ваши проблемы были организационного характера и никак не связаны с профессиональными качествами разработчиков. А обилие иностранных терминов также мешает восприятию материала.
                                                      +3
                                                      >> У меня сложилось впечатление, что ваши проблемы были организационного характера и
                                                      >> никак не связаны с профессиональными качествами разработчиков.

                                                      Блог называется «Управление проектами». Что странного? :)

                                                      >> А обилие иностранных терминов также мешает восприятию материала.

                                                      В первый раз читаете подобный материал? Обилие этих терминов вполне обьяснимо.
                                                        –2
                                                        а это вообще характерно ыы
                                                          +1
                                                          Что за игра — пока не могу сказать. Скажу через месяц — другой.
                                                          — 3 области ошибок
                                                          — много организационных ошибок
                                                          — ставка на молодую команду
                                                          — удаленность core team

                                                          + всё то, что я писал выше.
                                                          0
                                                          А «Keep it Simple» разве не из семейства Agile? Вроде, это XP.
                                                            +2
                                                            Этот подход можно и нужно применять вообще безотносительно к Agile XP и проч., там где это, конечно, уместно.
                                                              +1
                                                              Это идеи которые были всегда, которые Agile «подхватили».
                                                              +10
                                                              А кто еще заметил, что последние месяцы Хабрахабр так и пестрит классными статьями, а ныть «Хабр уже не тот» все перестали начисто?
                                                                +2
                                                                В последние время статью интересны. Правда немного напрягают волны связанные с ICQ и Jabber
                                                                  +6
                                                                  ICQ уже не тот
                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                  +2
                                                                  Надеюсь в этом есть и мой скромный вклад, давайте мне обратную связь и я буду продолжать ;)
                                                                    +1
                                                                    Конечно есть, спасибо за это :)
                                                                  +3
                                                                  Такие статьи просто заставляют снова погрузиться в мир геймдева, хоть и не профессиональный, но все же.
                                                                    0
                                                                    Хочется назад в геймдев? :)

                                                                    Поясните,
                                                                    Мир не профессионального геймдев в смысле что мы за это не получаем денег (мы их получаем :) ), или в смысле что нам далеко до профи (с этим то я согласен, писал в статье что удивительно что нас не уволили — вероятно других нет)?
                                                                      +1
                                                                      Я имел ввиду, что возникает желание снова начать изучение графических движков, принципов содания игр, и попыток создать свой мегавелосипед. Но увы, когда реально начинаешь оценивать свои силы, весь энтузиазм заканчивается и приходится с этим завязывать. Но вскоре, читаешь какой-нибудь интересный постмортем и все начинает повторяться. Вроде бы так.
                                                                    +1
                                                                    Классическая часть — приходит новый тим лид программист и говорит, что нужно все переписать :))) В вашем случае это привело, очевидно, к лучшим результатам, но могло дать и другой эффект.
                                                                      +1
                                                                      Не совсем. Его ошибка была в том что он так _не_ поступил. Несколько недель он был на проекте и НЕ переписывал код, хотя нужно придти, посмотреть на код пару дней, что-то попробовать сделать, и сразу код выкинуть. Это был код «быстрого» прототипа который никогда не рефакторился.

                                                                      В целом конечно с вами согласен.
                                                                      Это типичная ситуация :)
                                                                      +3
                                                                      «Совершенный код» надо было сразу читать и ещё кое-какие книжки.
                                                                        0
                                                                        Читать и перечитывать раз в год!!!

                                                                        А какие еще книжки еще?
                                                                        Не то чтобы я не в теме, просто интересен ваш список.
                                                                          +2
                                                                          Другие книжки зависят от того какая стоит задача. «Совершенный код» это же универсальная книга по проектированию и кодированию программ на разных языках и платформах. В ней, кстати, в каждой главе указаны какие конкретно книги нужно читать, чтобы углубиться в тему по разбираемому вопросу.

                                                                          А так можно называть разное. Одним нужно проектировать GUI, другим работать с базами данных, третьим с математикой, завязанной на графику, физику или ещё что. Плюс поправка на платформу и язык. Сейчас из интернета можно накачать очень множество книг, руководств и прочих полезных материалов. Всё это меняет мировозрение не в меньшей степени, чем «Совершенный код».

                                                                          От себя бы я добавил, что в программировании очень важно знать, что хочешь получить, нежели как это получить. Так как программисты очень часто усиливают второе умение, забывая о первом. И это в конечном итоге выливается вот в такие вот топики.
                                                                        +4
                                                                        Автор начитался книг про трагедии в проектах и представил себя героем одного из них.

                                                                        Еще забавляет когда человек, начинает всюду в свою речь вставлять всякие «это не есть issue и наш vision не привел к трагической death в итоге мы стали winnera-ми». Моя клиентка, как-то раз сказала про подобного персонажа: «наш технический директор такой умный, только он так быстро говорит и ничего не понятно».

                                                                        Мысль в том, что можно работать не играя в игры, и разговаривать на чистом и понятном языке.

                                                                          0
                                                                          действительно, статья на каком-то арго написана :(
                                                                          вообще, такое калькирование слов свойственно для покоренных народов, которые находятся под культурным гнетом народа-победителя.
                                                                          хотя на моей прошлой работе также говорили: проперти-пропертя-пропертей и т.п.
                                                                          или у Задорнова когда0то было: «Вам чиза наслайсать или одним писом»
                                                                            –1
                                                                            Спасибо за мнение.

                                                                            Вероятно, просто этот текст написал не для вас.
                                                                            Ничего страшного в этом нету )
                                                                              +1
                                                                              Читать интересно и автору спасибо, но действительно мозг аж наизнанку вывернуло от обилия слов, которым вполне можно найти адекватный аналог в родном языке.
                                                                                –1
                                                                                текст написал для менеджеров проектов, размещен в блог по управлению проектам.

                                                                                да, буду стараться писать что бы и внешние люди с ним справлялись, больше русских слов,

                                                                                только я не уверен что внешние люди какую-то пользу от прочтения получат.
                                                                              0
                                                                              Прикиньте. Я спрашиваю у команды — ну как вам постмортем?
                                                                              И слышу ответы

                                                                              — ну вроде ничего, просмотрел мельком
                                                                              — много букв, я не читал
                                                                              — гхм!, у меня не было на это времени!!! (это говорит сча наш самый крутой художник проекта в 21:20, в субботу, мы с ним вдвоем остались на офисе, и у нас осталось 1.5 часа до deadline по сабмишну в Verizon, срочно доделываем промо флешку, вот она жизнь!!! )

                                                                              чОрт, я не специально!
                                                                                +1
                                                                                Какие, блять, знакомые ощущения.
                                                                                  +1
                                                                                  На самом деле человек очень гордится проделанной работой и его распирает поделиться! Это очень классное чувство — удовлетворение от пройденного пути и гордость за то что получилось! Удачи с выпуском! ;)
                                                                                    +3
                                                                                    Честнагря, когда читаешь такие статьи, становится непонятно что вообще делают менеджеры и дезигнеры в разработках игр? Программеры пишут код, думают над архитектурой — это понятно. Художники рисуют — это понятно. Ну стоит над ними главный архитектор и идеолог. Неужели мало?

                                                                                    Читаю статьи на сайте КРИ.

                                                                                    «Мы сделали игру (какую-то стратегию), и начали тестирование на пользователях. И тут выяснилось, что наш интерфейс пользователи не понимают»! Ёпт а о чем вы раньше думали, спрашивается?

                                                                                    «Пользователь первые пол-часа не мог въехать как управлять игрой. Оказывается, он не понял, что чтобы главный персонаж начал двигаться, его надо вначале активизировать». Конечно, это же главный персонаж, он сразу виден на экране и пользователь ожидает, что его активизировать ненадо.

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

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

                                                                                    Пипец кароче, лучшеб не читал про эти потуги, тошно становится. Тут не гордиться за то что получилось, а плакать нужно. Хотя, статья важна именно этим — хороший пример состояния дел в мозгах и в отрасли.
                                                                                      +1
                                                                                      Спасибо за отзыв. Да в геймдеве дела, мягко говоря не не очень хороши.
                                                                                      В целом в IT всё лучше огранизовано.

                                                                                      В геймдеве слишком много неучей и неумек.
                                                                                      Но и игры это очень сложный софт, сложные проекты, это тоже нужно понимать.
                                                                                      Возьмите WOW или Аллоды Онлайн, это _очень_ сложные проекты.

                                                                                      А откуда взяться профи, если гейм-дизайну у нас в универах еще не учат?
                                                                                      Тоже самое, но в меньшей степени, про менеджеров.

                                                                                      Нужно жить с теми людьми что есть, учиться самому, учить других.
                                                                                        0
                                                                                        «дела в геймдве не не очень хороши» следует читать «дела в геймдеве не очень хороши»
                                                                                          –1
                                                                                          Когда я учился в колледже (10-11 классы) ВКИ НГУ, то там пол года был так называемый вводный проект на котором все аспекты разработки игр освещались (ну или почти все)… правдо было это 8 лет назад, не знаю как сейчас дела обстоят.

                                                                                          А вот в США и Европе геймдизайну учат в специальных колледжах и университетах.

                                                                                            0
                                                                                            О как интересно.
                                                                                            Подробнее расскажите, какие именно аспекты освещались?
                                                                                            Как курс назывался?

                                                                                            Интересует прежде всего единственная уникальная профессия в геймдеве — гейм-дизайн.
                                                                                            Какие аспекты гейм-дизайна вам рассказывали в 10-11 классах 8 лет назад?

                                                                                            В США и Европе учат да, это круто. Даже кто-то что-то у нас пытается изобразить.
                                                                                        +1
                                                                                        Спасибо за статью.

                                                                                        __
                                                                                        Только Agile и Waterfall? RUP с кучей модификаций совсем не катит?
                                                                                          –1
                                                                                          Agile, кстати, какой именно? Scrum?
                                                                                            0
                                                                                            Спасибо вам!

                                                                                            — Я писал выше что Agile и Waterfall я воспринимаю hi-level, как вы достигаете эффективности.
                                                                                            Вариаций методологий тьма, но это мало влияет на то что мы обсуждаем.
                                                                                              –1
                                                                                              вы пишете о выборе между водопадом и гибкими методологиями, так, как будто кроме них ничего нет. хотя весь мир живет по rup или cmm.

                                                                                              :-)
                                                                                                0
                                                                                                Перечитайте, для меня это две разных hi-level идеи как достигать эффективность по конкретным задачам. других принципиально разных идей я не знаю.

                                                                                                rup,cmm,xp,scrum — все что угодно, это конкретные реализации и они нам честно говоря мало интересны,

                                                                                                Ибо в IT — наша методология эта та, которая хорошо работает для нашего проекта команды компании и заказчика.
                                                                                                  –1
                                                                                                  >других принципиально разных идей я не знаю.

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

                                                                                                    0
                                                                                                    не ошибается, кто ничего не делает
                                                                                                      0
                                                                                                      habrahabr.ru/blogs/pm/51929/#comment_1377660
                                                                                                      это кстати не вполне верно

                                                                                                      «принципы agile»

                                                                                                      Наивысшим приоритетом для нас является удовлетворенность заказчика ранними и периодическими поставками ценного для заказчика ПО.

                                                                                                      Приветствуйте изменения требований даже на поздних этапах разработки. Agile-процессы готовы к таким изменениям ради достижения заказчиком конкурентного преимущества.

                                                                                                      Выполняйте частые поставки работающего ПО. При этом продолжительность каждой итерации должна быть от пары недель до пары месяцев, предпочтение отдается коротким интервалам.

                                                                                                      Потенциальные пользователи системы, являющиеся специалистами в предметной области, и разработчики должны работать вместе каждый день на протяжении всего проекта.

                                                                                                      Привлекайте для работы над проектом мотивированных людей. Создайте для них все условия, окажите поддержку во всем, что необходимо, и доверьтесь им — они выполнят работу.

                                                                                                      Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром — непосредственное общение.

                                                                                                      Работающее ПО — главный индикатор продвижения проекта.

                                                                                                      Agile-процессы придерживаются равномерного темпа разработки. Работа спонсоров, разработчиков и пользователей должна все время идти в постоянном темпе.

                                                                                                      Постоянное стремление к техническому совершенству и хороший дизайн системы повышают agility.

                                                                                                      Важна простота — искусство увеличения объема работ, которых удалось избежать.

                                                                                                      Самые лучшие архитектуры, требования и дизайны систем создаются самоорганизующимися командами.
                                                                                                      Периодически команда размышляет о том, как достичь большей эффективности, после чего корректирует свой подход к разработке ПО.

                                                                                                      основной признаки мотивированная самоорганизующаяся команда. положа руку на сердце — она у вас была? и это эжайл? или все-таки путаница в терминах?
                                                                                                        0
                                                                                                        То как я hi-level понимаю Agile это, повторюсь (см так же выше),

                                                                                                        Agile. «быстро и почти без процесса сделать маленькую штуку крутыми челами, и затем с заказчиком который рядом итеративно довести до релиза»

                                                                                                        Выше я привел своё hi-level понимание Agile,
                                                                                                        Если это моё понимание Agile и те выводы что я делаю, кажутся вам (или кому-то) полезными — я рад. Согласен с вами, что обсуждать кто как понимает термины большого смысла нету.

                                                                                                        Я не уверен что текст который вы написали противоречит как-то моему тексту, или моему пониманию Agile

                                                                                                        Спасибо за отзыв!
                                                                                                        0
                                                                                                        >> вообще говоря, как директор it компании могу сказать

                                                                                                        Как директор ит компании и пм с 5+ летним опытом согласен с вами что «опытный» пм в 26 лет это нонсенс.

                                                                                                        Буду рад если вы, более опытный специалист, укажите мне на другие hi-level идеи. Я их действительно не знаю.
                                                                                                          –1
                                                                                                          основная проблема (не Ваша, а вообще )) к сожалению), что люди что то слышали про эжайл, пытаются применить какие -то методологии, а потом говорят «ничего не работает»
                                                                                                          я поэтому спрашивал по конкретную реализацию.
                                                                                                          К примеру, нельзя применять XP частично, потому что осутствие документации заменяет общение в одной комнате, а доп тестрование — парное программирование. Отмените одно — все посыпится. В Вашем случае хорошо мог работать, вероятно, FDD. Он представляет собой иерархическую схему отвтевенности, в отличии от сетвой в XP (что у Вас вообще не могло работать в распределенной команде) или Scrum.

                                                                                                          Многие беды происходят от путаницы в терминах. Ваши hi-level идеи меня вообще слегка шокируют. Я Вам привел основные постулаты Aglie — т.н. Манифест Гибкой Разработки, в котором черным по белому написано о важности команды, Вы в статье пишете о том, что люди «не понимали и не принмали» и после этого удивляетесь провалу.

                                                                                                          Agile — это не анархия.

                                                                                                          >«быстро и почти без процесса сделать маленькую штуку крутыми челами, и затем с заказчиком который рядом итеративно довести до релиза»

                                                                                                          А что, в RUP по-другому???? Это основа всех итеративных процессов разработки.

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

                                                                                                            +1
                                                                                                            p.s.

                                                                                                            Мне, кстати, нравятся Ваши посты. Еще раз, спасибо.
                                                                                                              +1
                                                                                                              p.p.s.
                                                                                                              посмотрел ваш жж.
                                                                                                              вы же все это прекрасно и сами знаете )) на личном опыте.
                                                                                                                +1
                                                                                                                >Как директор ит компании и пм с 5+ летним опытом согласен с вами что «опытный» пм в 26 лет это нонсенс.

                                                                                                                кстати, 5 лет — это уже хороший опыт, но тогда я вам сочувствую, потому, что руководить в 21 — после института, без реального опыта работы, это наверняка было весьма тяжело

                                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                    Самое читаемое