Хочу поделиться мыслями по поводу эффективности разработки игр. Об
эффективности начинаешь задумываться когда работаешь в крайне неэффективной
системе, возникает вопрос- "а как надо сделать чтобы такого не
было?". Всё будет рассказано на примере компании, где я работал рядовым
наемным программистом и выполнял задачи лида. Это сравнительно маленькая компания, всегда меньше 10 программистов( эти 10 человек всегда разные, из-за большой текучки) и порядка 15 художников. В этой компании допущены все возможные ошибки управления, о которых только можно представить, поэтому хорошо расссматривать её как кононический пример. Все мои наблюдения касаются исключительно геймдевелоперских компаний и я не стремлюсь обобщать и
экстраполировать опыт и выводы на другие типы компаний. Итак, приступим.
Теперь оценим сколько денег съедает бесполезная трата времени в эти 20 часов еженедельно. Именно бесполезная, т.к. я имел опыт обходится без этих модных методик и всё работало замечательно. Введем некую среднюю стоимость часа сотрудника компании 250р. Умножаем на 20 часов в неделю, получаем 5 тыс. рублей. Умножаем на приблизительное кол-во сотрудников конторы 30 человек. Получаем 150 тыс. в неделю. Или 600 тыс. в месяц. Это количество денег которые теряет компания ежемесячно из-за плохой организации. И это еще без учета ущерба, который получается косвенно, в результате неэффективной работы (незданные вовремя проекты, плохая репутация компании, немотивированность сотрудников и как следствие плохая работа). Косвенный ущерб еще больше, но его не так просто грубо посчитать. Итак, 600 тыс. эти деньги при идеальной организации можно вообще не терять. Идеал не достижим, но при грамотной организации эти потери можно уменьшить на две трети. Бережливое производство, аджаил (произносится мерзким булькающим голосом)!
Как я уже писал к программисту сходятся все ниточки и он выдаёт конечный продукт, поэтому расходование времени программиста наиболее критично. И чем меньше программистов (особенно хороших), тем более расточительно для компании не думать о его времени в особом режиме. В связи с этими утверждениями мои 20 часов в неделю на дорогу можно превратить в 15-16 часов посвященных проекту. т.е. 2 дополнительных рабочих дня в неделю. Если исключить бесполезный базар, под названием "коммуникация" и интегрировать её в процесс разработки, это ещё + 15-16 часов экономии (это из 20 часов которые описанные в предыдущем абзаце, их можно сократить легко на 75%). Говорить об опозданиях и махать грозно пальцем это вообще смешно, на фоне того глобального пиздеца, который творится в компании. Да, я знаю что это раздражает людей, когда я прихожу позже остальных. Потому что я предпочитаю работать в тишине, которая возможна только вечером, соответственно ухожу позже всех и работаю в среднем 9 часов в сутки. Я так понимаю гибкость. У вас нет других проблем, кроме моего прихода на 40 минут позже рекомендации? У вас больше 90 (!!!) процентов программных проектов сдаются не в срок и с нарушениями условий, у вас больше 20 (!!!) программистов уволились меньше чем за два года. А вы прессуете тех, кто героически устоял и хорошо работает, благодаря своим внутренним силам. Флаг вамв жопу в руки.
Мысль 1
О модных методологиях разработки
Существуют различные методы ведения разработки такие как agile,
lean, kanban, scrum, gamification, hive mind. Это не только методы разработки, но
различные списки рекомендаций, концепций управления, системы организации
производства. Всё это есть и всё это где-то работает. Все эти методы были опробованы творческим руководством компании на простых сотрудниках. Но всё мимо, эффективность отрицательная, методы не работают. Почему?
- Все методологии применяются только потому, что они есть, они
модные, и они где-то работают. Принцип выбора
очередной методики "а давайте попробуем, у них-то
работает". Реальной необходимости использования нет.
- Методологии применяются не в попад и неуместно. Любым инструментом надо уметь пользоваться и у него есть область применения.
Молоток - хороший инструмент, им удобно забивать гвозди. Но надо уметь
забивать, знать где забить, а иногда лучше воспользоваться
шуруповертом.
- Методологии применяются как "магический ящик".
Нужно понимать на что направлен тот или иной процесс, какая задача у него
стоит и для чего он был создан. Без вникания в
проблемную область конкретных проектов - все методы превращаются во
внешнюю мишуру, которая мешает и раздражает участников. Метода - не магическое заклинание, которое решает все проблемы стоит лишь прочесть его каждый полдень. Метода
лишь перечень рекомендаций, к которым можно обратиться когда встаёт
спорный вопрос. И даже в этот момент, это всего лишь рекомендация,
на которую надо смотреть в контексте проблемной области (данного проекта). Рекомендация - совет, пожелание или предписание,
высказанное в необязательной форме.
- Эмоциональная оценка -
унылость и бесполезность действия. Все процессы проистекают с унылыми
рожами и скучными рутинными действиями, людям плевать что происходит, на
лицах читается нулевая вовлеченность и участие. Иногда не на лицах,
а по репликам и поверхностным суждениям. При том эпицентр безучастности -
те, кто призван управлять всем действием. Это естественное отражение
бесполезности методики и её неэффективности. Сотрудники участвуют
потому что "надо", потому что "попросили". Люди
воспринимают так - надо потерпеть, и потом я пойду работать. Я говорю о
тех людях, которые работают и нацелены на результат и профессиональное
саморазвитие. Паразитные сотрудники очень хорошо маскируются за спинами тех, кто реально работает и они не различимы с позиции руководства.
Существующие процессы предрасполагают к паразитированию. Люди
работают не благодаря процессу, а вопреки ему. А для тех, кто не работает созданы тепличные условия.
- Методологии применяются ко всем поголовно и ко всем одинаково.
Методология это не вакцина от гриппа, которую надо всем вколоть (кстати,
даже на вакцинах это не прокатывает). Нужно применять только под
конкретный проект, для разных участников (программист, офис манагер,
художник) по-своему, и только там, где это продиктовано необходимостью.
Разная организация досок и таблиц (если нужны), разные коэффициенты и разные способы
контроля исполнения и поощрения. Универсального
инструмента не существует.
- Если хотите чтобы все эти методы работали ими надо серьезно заниматься. Не просто ковырять, а проводить результативную умственную работу. Посвящать значительное время, анализировать, прорабатывать в деталях, отлаживать механизмы работы. "Из коробки" решений подобного рода не существует. Только глупый человек может мечтать получить на халяву прирост эффективности. Или добиться того, что люди будут сами платить за возможность работать, как это декларируют некоторые методики.
Получается как в басне Крылова "Мартышка и очки", за тем исключением, что в басне мартышка поняла, что очки ей не подвластны и выкинула их. Руководство компании, в отличии от мартышки, упорно продолжает ходить с очками надетыми на задницу и нахваливать их, как классно они помогают. От чего помогают абсолютно не важно и неизвестно, а результат такой помощи никому не интересен и не виден (потому что его нет).
Мысль 2
Об обратной связи и общении
В этой замечательной компании помимо принципов "бережливого производства" используется agile (гибкие процессы). По поводу "бережливости" я напишу далее, в мысле 7. Бережливость сводится к тому, что генитальный директор компании экономит по мелочам (на нервах сотрудников и их мотивации) и проёбывает сотнями тысяч в месяц. Чего стоит пример, когда со мной торговались за оплату выходного дня, в который я сделал прототип. Потратил 2 дня, оплатили один и по ставке обычного рабочего дня. Зато специалист с зарплатой в 2 раза больше чем у меня, потом сидел 2 недели писал этот прототип в рабочее время, по сути ничего не добавив нового. То, что специалист по серверному программированию (а на деле специалист пускать пыль в глаза) писал игру на юнити, это тоже отдельная история. Но не будем отвлекаться, сейчас у нас аджайл.
Согласно принципам agile, общение с глазу на глаз предпочтительней полной документации и других формальных подходов. С общением в компании всё хорошо (сарказм). Ничто не располагает к эффективному общению, как условия опенспейс. Когда все сидят друг на друге в одной большойклоаке комнате. Это идеальные условия для творчества (сарказм). На практике рекомендация отказаться от полной документации преобразовалась в полный отказ от документации. Один хрен, звучит почти одинаково. Разжую, отказ от полной документации означает, что не нужна всеобъемлющаяя документация, покрывающая всё, вплоть до мелочей. Но это не означает что она вообще не нужна. Это означает что она нужна только там, где нужна, в ключевых, особо важных местах. Но каждый понимает как ему выгодно и трактует в силу своей фантазии, зачастую больной и не привязанной к реальности.
Рекомендуемое аджайл общение, преобразовалось в базар. Базар в смысле ярмарки, - носятся люди, голдят по любому поводу, чаще всего на темы не относящиеся или косвенно относящиеся к работе. Все люди равны, коммунизм. Каждый мальчик-одуванчик и девочка-припевочка может поучаствовать в разработке игры, в том смысле, в котором они понимают это. Каждый думает что он компетентен рассуждать на любую тему. Бесконечные собрания и болтовня, которые ни к чему не приводят. Вопросы не решаются. На моей памяти (за 2 года) ни разу не была решена какая-то проблема. Проблемы принято записывать на бумажку и забывать о ней. И это не ирония.
Директор и учредитель компании нихрена не смыслят в играх, но считают что они профессионалы и учат всех как делать игры. Хотя нет ни одного примера выпущенной ими (не то что успешной или популярной, а хотя бы выпущенной) игры до работы в компании. А то что выпущено внутри компании, выпущено не благодаря, а вопреки им. Зачем нам профессиональный подход? Мы будем учить профессионалов как им делать игры, для этого мы их наняли. От того что перед моим рабочим местом обсуждают нечто отдалено относящееся к проекту, я должен получать бенефит, как участник команды. Чаще всего передо мной обсуждают вообще другой проект. Статистически, чем больше разных проектов, тем меньше каждый отдельный человек участвует в каждом из них. А у нас до 4-6 одновременно идущих проектов. Иногда мне гораздо полезнее сосредоточится и посидеть в спокойной(!) и тихой(!) рабочей обстановке. Особенно если я программист, мне иногда надо думать. Сарказм! Иногда - это почти всегда.
Доведем ситуацию до абсурда для наглядности представления ситуации. Представим математика, пытающегося доказать теорему на рок концерте.
Вот сидишь ты доказываешь теорему, пытаешься воспользоваться радикальным признаком сходимости Коши, чтобы проверить сходимость ряда. Но тут, внезапно, начинается слэм (слэм - действие публики на музыкальных концертах, при котором люди толкаются и врезаются друг в друга. Слэм также часто сопровождается стейдж дайвингом и хэдбэнгингом). Ничего, потерпим, всё таки аджайл. Надо быть гибким, думаешь ты, пытаясь взять интеграл. Но тут, хуяк, слэм плавно совмещается с хэдбэнгингом. Во имя канбана, нельзя отбиваться от коллектива! Начинаем методично мотать головой в такт со всеми. Позже когда концерт окончен и все разбредуться по домам, мы, наконец, сможем довести начатое до конца. На следующий день спрашивают:
- Ну чо как там теорема, Эйнштейн, решил?
- Я доказывал, а не решал.
- Это очень плохо, доказательство это не product value согласно нашему кодексу, надо нечто, что можно потрогать руками и положить в рот.
- ???????
- PROFIT
Это всего лишь метафора, но она передаёт ощущение от работы в такой среде. По факту пустая болтовня ни к чему не приводит, т.к. у людей нет ответственности за решения и желания её брать на себя. Да и как потом ссылаться на решение? Вася предложил, когда я у кофемашины салат нарезал? Для решения конкретного вопроса должно быть выделено время (если вопрос объемный и серьезный), инициатива должна исходить от человека, которому надо решить проблему и этот человек несёт ответственность за решение перед, например, лидом. Неважно с кем он обсуждал, важно что ответственность за решение привязана к нему. Локальные проблемы реашаются на месте, в общении между специалистами. И участие менджеров с печатью безразличия на челе для этого не нужно.
Мысль 3
О гамификации
О да, наш директор хедлайнер гамефекации в России!
Гамификация - это применение игровых механик в неигровом контексте. Направленное на дополнительную мотивацию сотрудников, в теории. Выглядит это так - всем выдают бумажные медали, бумажные псевдо-деньги, и продают бонусы и подарки за эти деньги. Особенно эпично выглядят девочки-припевочки имеющие больше всех медалей и псевдо-денег. Т.е. они самые ценные и самые полезные для компании сотрудники с точки зрения гамифекации в редакции наших гениев директоров.
Хорошо бы если эта "система" была где-нибудь сбоку и я её не видел и не слышал. Так нет же, меня вынуждают участвовать в этом театре абсурда каждый день. Я каждый день слушаю кто получил бумажную медаль и кто сколько заработал псевдо-денег, мне это запредельно интересно. Я серьезный дядька и я ориентирован на результат и на профессиональное саморазвитие. У меня от 1-го до 3-х проектов одновременно, в них полный хаос, по причинам вашего генитального менеджмента. Я пытаюсь разгрести этот хаос. У меня всегда куча работы, которую невозможно выполнить доступными ресурсами. Меня дергают постоянно, переносят с проекта на проект, я слушаю постоянный галдеж в условиях опенспейса, пишу в этих условиях код, наблюдаю некоторых паразитов, которые нихера не работают. Поэтому я немного раздражен и моя нервная система немного напряжена. И ваш идиотский детский сад с бумажными медальками каждый гребанный день это то, чего я жду меньше всего в этих условиях. Ежедневная дележка вонючих бумажек, от которых блевать тянет. Еще мне очень интересно каждый день слушать кто в какую игру играл вчера вечером (обязательный вопрос на стендапе, по всей видимости направленный на то, чтобы люди интересовались играми, очень тонкий и изящный ход! Кстати, сам директор очень слабо ориентируется в играх). Кто молодец и хорошо нарисовал клумбу, за это получает орден на стикере и жидкие аплодисменты, кто получил псевдо-денег за рвение, а кто выторговал на аукционе набор для чаепития. Такое шапито каждый день. В условиях полного хаоса в организации всегда приятно слышать что кто-то, оказывается, работает, получает медаль за расчистку доски от бумажек, тренирует бадди капитана (помошника капита), и успешно капитанствует (капитаны каждую неделю новые) на стендапах. Вот она, бурная деятельность, а я то думал, что я работаю.
Это надо очень постараться придумать такой маразм, из худших возможных сценариев применения гамификации выбрать наихудший, криво его применять и не видеть что пользы это не приносит, а приносит только вред. В таком виде гамификацию можно применять только в школе, или в кружке самодеятельности, но никак не в профессиональной среде программистов, художников и геймдизайнеров. Все эти свистелки и перделки выглядят как откровенное позорище и не вызывает ничего кроме раздражения и отторжения у меня и некого процента сотрудников ( ОК, этот процент я считаю примерно равным 85 ). Пустая трата времени и источник раздражения для реально работающих людей, которые знают, как и что им делать.
Чуть ниже я покажу как в условиях компании подобного масштаба и профиля можно было бы применять гамификацию. Если задействовать немного мозга. Но в любом случае наладить хорошо подобную систему достаточно накладно, а плохо - мы получим то, что я описал. На мой взгляд в очень редких ситуцаиях может возникнуть реальная необходимость использования подобных механик.
Мысль 4
Об обратной связи и общении
В этой замечательной компании помимо принципов "бережливого производства" используется agile (гибкие процессы). По поводу "бережливости" я напишу далее, в мысле 7. Бережливость сводится к тому, что генитальный директор компании экономит по мелочам (на нервах сотрудников и их мотивации) и проёбывает сотнями тысяч в месяц. Чего стоит пример, когда со мной торговались за оплату выходного дня, в который я сделал прототип. Потратил 2 дня, оплатили один и по ставке обычного рабочего дня. Зато специалист с зарплатой в 2 раза больше чем у меня, потом сидел 2 недели писал этот прототип в рабочее время, по сути ничего не добавив нового. То, что специалист по серверному программированию (а на деле специалист пускать пыль в глаза) писал игру на юнити, это тоже отдельная история. Но не будем отвлекаться, сейчас у нас аджайл.
Согласно принципам agile, общение с глазу на глаз предпочтительней полной документации и других формальных подходов. С общением в компании всё хорошо (сарказм). Ничто не располагает к эффективному общению, как условия опенспейс. Когда все сидят друг на друге в одной большой
Рекомендуемое аджайл общение, преобразовалось в базар. Базар в смысле ярмарки, - носятся люди, голдят по любому поводу, чаще всего на темы не относящиеся или косвенно относящиеся к работе. Все люди равны, коммунизм. Каждый мальчик-одуванчик и девочка-припевочка может поучаствовать в разработке игры, в том смысле, в котором они понимают это. Каждый думает что он компетентен рассуждать на любую тему. Бесконечные собрания и болтовня, которые ни к чему не приводят. Вопросы не решаются. На моей памяти (за 2 года) ни разу не была решена какая-то проблема. Проблемы принято записывать на бумажку и забывать о ней. И это не ирония.
Директор и учредитель компании нихрена не смыслят в играх, но считают что они профессионалы и учат всех как делать игры. Хотя нет ни одного примера выпущенной ими (не то что успешной или популярной, а хотя бы выпущенной) игры до работы в компании. А то что выпущено внутри компании, выпущено не благодаря, а вопреки им. Зачем нам профессиональный подход? Мы будем учить профессионалов как им делать игры, для этого мы их наняли. От того что перед моим рабочим местом обсуждают нечто отдалено относящееся к проекту, я должен получать бенефит, как участник команды. Чаще всего передо мной обсуждают вообще другой проект. Статистически, чем больше разных проектов, тем меньше каждый отдельный человек участвует в каждом из них. А у нас до 4-6 одновременно идущих проектов. Иногда мне гораздо полезнее сосредоточится и посидеть в спокойной(!) и тихой(!) рабочей обстановке. Особенно если я программист, мне иногда надо думать. Сарказм! Иногда - это почти всегда.
Доведем ситуацию до абсурда для наглядности представления ситуации. Представим математика, пытающегося доказать теорему на рок концерте.
Вот сидишь ты доказываешь теорему, пытаешься воспользоваться радикальным признаком сходимости Коши, чтобы проверить сходимость ряда. Но тут, внезапно, начинается слэм (слэм - действие публики на музыкальных концертах, при котором люди толкаются и врезаются друг в друга. Слэм также часто сопровождается стейдж дайвингом и хэдбэнгингом). Ничего, потерпим, всё таки аджайл. Надо быть гибким, думаешь ты, пытаясь взять интеграл. Но тут, хуяк, слэм плавно совмещается с хэдбэнгингом. Во имя канбана, нельзя отбиваться от коллектива! Начинаем методично мотать головой в такт со всеми. Позже когда концерт окончен и все разбредуться по домам, мы, наконец, сможем довести начатое до конца. На следующий день спрашивают:
- Ну чо как там теорема, Эйнштейн, решил?
- Я доказывал, а не решал.
- Это очень плохо, доказательство это не product value согласно нашему кодексу, надо нечто, что можно потрогать руками и положить в рот.
- ???????
- PROFIT
Это всего лишь метафора, но она передаёт ощущение от работы в такой среде. По факту пустая болтовня ни к чему не приводит, т.к. у людей нет ответственности за решения и желания её брать на себя. Да и как потом ссылаться на решение? Вася предложил, когда я у кофемашины салат нарезал? Для решения конкретного вопроса должно быть выделено время (если вопрос объемный и серьезный), инициатива должна исходить от человека, которому надо решить проблему и этот человек несёт ответственность за решение перед, например, лидом. Неважно с кем он обсуждал, важно что ответственность за решение привязана к нему. Локальные проблемы реашаются на месте, в общении между специалистами. И участие менджеров с печатью безразличия на челе для этого не нужно.
Мысль 3
О гамификации
О да, наш директор хедлайнер гамефекации в России!
Гамификация - это применение игровых механик в неигровом контексте. Направленное на дополнительную мотивацию сотрудников, в теории. Выглядит это так - всем выдают бумажные медали, бумажные псевдо-деньги, и продают бонусы и подарки за эти деньги. Особенно эпично выглядят девочки-припевочки имеющие больше всех медалей и псевдо-денег. Т.е. они самые ценные и самые полезные для компании сотрудники с точки зрения гамифекации в редакции наших гениев директоров.
Хорошо бы если эта "система" была где-нибудь сбоку и я её не видел и не слышал. Так нет же, меня вынуждают участвовать в этом театре абсурда каждый день. Я каждый день слушаю кто получил бумажную медаль и кто сколько заработал псевдо-денег, мне это запредельно интересно. Я серьезный дядька и я ориентирован на результат и на профессиональное саморазвитие. У меня от 1-го до 3-х проектов одновременно, в них полный хаос, по причинам вашего генитального менеджмента. Я пытаюсь разгрести этот хаос. У меня всегда куча работы, которую невозможно выполнить доступными ресурсами. Меня дергают постоянно, переносят с проекта на проект, я слушаю постоянный галдеж в условиях опенспейса, пишу в этих условиях код, наблюдаю некоторых паразитов, которые нихера не работают. Поэтому я немного раздражен и моя нервная система немного напряжена. И ваш идиотский детский сад с бумажными медальками каждый гребанный день это то, чего я жду меньше всего в этих условиях. Ежедневная дележка вонючих бумажек, от которых блевать тянет. Еще мне очень интересно каждый день слушать кто в какую игру играл вчера вечером (обязательный вопрос на стендапе, по всей видимости направленный на то, чтобы люди интересовались играми, очень тонкий и изящный ход! Кстати, сам директор очень слабо ориентируется в играх). Кто молодец и хорошо нарисовал клумбу, за это получает орден на стикере и жидкие аплодисменты, кто получил псевдо-денег за рвение, а кто выторговал на аукционе набор для чаепития. Такое шапито каждый день. В условиях полного хаоса в организации всегда приятно слышать что кто-то, оказывается, работает, получает медаль за расчистку доски от бумажек, тренирует бадди капитана (помошника капита), и успешно капитанствует (капитаны каждую неделю новые) на стендапах. Вот она, бурная деятельность, а я то думал, что я работаю.
Это надо очень постараться придумать такой маразм, из худших возможных сценариев применения гамификации выбрать наихудший, криво его применять и не видеть что пользы это не приносит, а приносит только вред. В таком виде гамификацию можно применять только в школе, или в кружке самодеятельности, но никак не в профессиональной среде программистов, художников и геймдизайнеров. Все эти свистелки и перделки выглядят как откровенное позорище и не вызывает ничего кроме раздражения и отторжения у меня и некого процента сотрудников ( ОК, этот процент я считаю примерно равным 85 ). Пустая трата времени и источник раздражения для реально работающих людей, которые знают, как и что им делать.
Чуть ниже я покажу как в условиях компании подобного масштаба и профиля можно было бы применять гамификацию. Если задействовать немного мозга. Но в любом случае наладить хорошо подобную систему достаточно накладно, а плохо - мы получим то, что я описал. На мой взгляд в очень редких ситуцаиях может возникнуть реальная необходимость использования подобных механик.
Мысль 4
О различии классов сотрудников, об отношении к программистам и об управлении всеми ими вместе взятыми
Геймдевелоперская контора всегда состоит из разных классов людей создающих контент: программисты, художники, дизайнеры, звуковики. Из далека может показаться, что все они просто делают игру. При близком рассмотрении становится понятно, что по сути они занимаются разными вещами.
Художники. Художник линейно выполняет работу. Далекому от геймдева человеку может показаться, что работа художника очень творческая, в реальности они работают почти как на конвейере. Минутки креативности и творческой свободы составляют пренебрежимо малое количество времени. Ну, условно говоря, 1 час в неделю. И это всюду так, не только у нас. Это нормальная практика, линейная предсказуемость, линейная работа, оценка работы с погрешностью в часы. Рисуешь монстра в два раза дольше, он получает в два раза детальнее и красивее. Оценить объем работы достаточно легко, попасть в оценку тоже. Грубо говоря, всегда можно оставить тот уровень детализации, который уже наработан и считать работу завершенной, а потом сказать "ну вы видите что нарисовано, на это мы потратили 16 часов". Вся работа налицо и легко сопоставить затраченное время с результатом, отсюда линейность. Если результат не совпадает с затраченым временем, значит художник медленно работает и его выживают. Такова проза гейдева. Единственная тонкость это оценка работы по фидбеку, тут большое поле для менджеров потратить деньги в пустую. Проблема решается внесением времени переделок и условий переделок в договор. Еще раз резюмирую - работа художников достаточно легко и предсказуемо прогнозируется и управляется.
Гейм дизайнеры. Здесь совершенно отличная ситуация. Со стороны трудно понять чем занимается гейм дизайнер и оценить качество его работы. Качество работы геймдизайнера можно оценить на двух этапах, программистами в процессе написания игры и в финальном продукте когда игроки играют в игру. Для того чтобы управлять геймдизайнерами нужен совершенно отличный (от художников) процесс. Цена ошибки гейм дизайнера самая высокая. Простая метафора - ошибка инженера-проектировщика при строительстве моста привела к тому, что мост впадает в резонанс при сильном ветре и саморазрушается. Отстроенный мост просто сносят в подобной ситуации. В такой ситуации происходят максимальные материальные потери и становится бесполезно рассуждать, о том на сколько хорошо работали строители, прорабы, менеджеры и как классно они уложились в срок при строительстве такого моста. Вот такие мосты достаточно часто строят геймдизайнеры и задача руководства не допускать проектирования таких мостов. Понятно что тут должны действовать специальные метрики оценки работы и особые методы руководства.
Программисты. Тут тоже диаметрально противоположная ситуация в отличии от художников. Линейность работы и предсказания результатов достижима только в отдельных очень малочисленных случаях ( я бы назвал эти случаи контентным программированием). В случае с программистами нужно обладать максимальной менеджерской гибкостью. Результат работы программиста виден практически в реальном времени( игра не работает, выдаёт ошибки, появляются новые фичи, исправляются баги). Но, тем не менее, запланировать работу программиста, успешно её контролировать в условиях неполных данных (не готов гейм дизайн, не ясно что за игру хотим сделать) это большое мастерство. Быстрые внешние результаты чаще свидетельствуют не о крутизне программиста, а о том, что код написан одноразовый и неподдерживаемый. Не все это понимают.
В пайплайне разработки все ниточки сходятся к программистам. Новая графика, новая музыка, новая логика поведения, любая другая мысль - всё стекается на реализацию к программистам. Программисты выдают конечный результат, по которому можно сделать вывод как все работали( художники, дизайнеры, звуковики). В примере с мостом из предыдущего абзаца в нашей компании будет виноват программист. Хреновый мост построил. Это не правильно. Очевидно, к программистам должен быть отдельный и очень хорошо проработанный подход в управлении. Бить по ним общей пушкой эфемерного аджайла и не прилагать никаких усилий в отдельный организационный процесс это в высшей степенидолбоебизм безрассудство и глупость. В этой замечательной компании у программистов даже нет формального лида. Это всё равно что армия без генерала. Солдаты не то что не выполняют приказ командира или обсуждают его, у них тупо нет командира. Все умственные изыскания руководства свелись к такой же карточке на доске как для художников, с метрикой ценность для продукта (product value). Всё, проблемы решены. Аджайл всё за нас разрулит. Так, наверное, думает генитальное руководство. Финансовое процветание компании и всеобщее счастье уже близко. Вот-вот появится...
Ну и до кучи скажу еще про манагеров. Очевидно, что качество работы менджеров должно оцениваться по количеству сданных в срок проектов, по проектам без овербюджета, по успешным переговорам о продаже проектов ( с удачно заключенными и выгодными контрактами для компании), по эффективности поиска новых клиентов. По совокупности достижений на областях в ответственности данного менджера. Плачевная статистика компании, 95% проектов не в срок (реальный подсчёт!!!), с перерасходом и т.д., показывает что менджеры работают плохо, мягко говоря. Никакой оценки эффективности не проводится вообще, никаких выводов не делается. Как продавали "то, не знаю что" и обещали клиентам не выполнимое, так и продолжают это делать. Некоторые умные люди умудряются учиться на чужих ошибках, наши же манагеры с завидным постоянством даже на своих не учатся. Но это отклонение от основной мысли.
Художники. Художник линейно выполняет работу. Далекому от геймдева человеку может показаться, что работа художника очень творческая, в реальности они работают почти как на конвейере. Минутки креативности и творческой свободы составляют пренебрежимо малое количество времени. Ну, условно говоря, 1 час в неделю. И это всюду так, не только у нас. Это нормальная практика, линейная предсказуемость, линейная работа, оценка работы с погрешностью в часы. Рисуешь монстра в два раза дольше, он получает в два раза детальнее и красивее. Оценить объем работы достаточно легко, попасть в оценку тоже. Грубо говоря, всегда можно оставить тот уровень детализации, который уже наработан и считать работу завершенной, а потом сказать "ну вы видите что нарисовано, на это мы потратили 16 часов". Вся работа налицо и легко сопоставить затраченное время с результатом, отсюда линейность. Если результат не совпадает с затраченым временем, значит художник медленно работает и его выживают. Такова проза гейдева. Единственная тонкость это оценка работы по фидбеку, тут большое поле для менджеров потратить деньги в пустую. Проблема решается внесением времени переделок и условий переделок в договор. Еще раз резюмирую - работа художников достаточно легко и предсказуемо прогнозируется и управляется.
Гейм дизайнеры. Здесь совершенно отличная ситуация. Со стороны трудно понять чем занимается гейм дизайнер и оценить качество его работы. Качество работы геймдизайнера можно оценить на двух этапах, программистами в процессе написания игры и в финальном продукте когда игроки играют в игру. Для того чтобы управлять геймдизайнерами нужен совершенно отличный (от художников) процесс. Цена ошибки гейм дизайнера самая высокая. Простая метафора - ошибка инженера-проектировщика при строительстве моста привела к тому, что мост впадает в резонанс при сильном ветре и саморазрушается. Отстроенный мост просто сносят в подобной ситуации. В такой ситуации происходят максимальные материальные потери и становится бесполезно рассуждать, о том на сколько хорошо работали строители, прорабы, менеджеры и как классно они уложились в срок при строительстве такого моста. Вот такие мосты достаточно часто строят геймдизайнеры и задача руководства не допускать проектирования таких мостов. Понятно что тут должны действовать специальные метрики оценки работы и особые методы руководства.
Программисты. Тут тоже диаметрально противоположная ситуация в отличии от художников. Линейность работы и предсказания результатов достижима только в отдельных очень малочисленных случаях ( я бы назвал эти случаи контентным программированием). В случае с программистами нужно обладать максимальной менеджерской гибкостью. Результат работы программиста виден практически в реальном времени( игра не работает, выдаёт ошибки, появляются новые фичи, исправляются баги). Но, тем не менее, запланировать работу программиста, успешно её контролировать в условиях неполных данных (не готов гейм дизайн, не ясно что за игру хотим сделать) это большое мастерство. Быстрые внешние результаты чаще свидетельствуют не о крутизне программиста, а о том, что код написан одноразовый и неподдерживаемый. Не все это понимают.
В пайплайне разработки все ниточки сходятся к программистам. Новая графика, новая музыка, новая логика поведения, любая другая мысль - всё стекается на реализацию к программистам. Программисты выдают конечный результат, по которому можно сделать вывод как все работали( художники, дизайнеры, звуковики). В примере с мостом из предыдущего абзаца в нашей компании будет виноват программист. Хреновый мост построил. Это не правильно. Очевидно, к программистам должен быть отдельный и очень хорошо проработанный подход в управлении. Бить по ним общей пушкой эфемерного аджайла и не прилагать никаких усилий в отдельный организационный процесс это в высшей степени
Ну и до кучи скажу еще про манагеров. Очевидно, что качество работы менджеров должно оцениваться по количеству сданных в срок проектов, по проектам без овербюджета, по успешным переговорам о продаже проектов ( с удачно заключенными и выгодными контрактами для компании), по эффективности поиска новых клиентов. По совокупности достижений на областях в ответственности данного менджера. Плачевная статистика компании, 95% проектов не в срок (реальный подсчёт!!!), с перерасходом и т.д., показывает что менджеры работают плохо, мягко говоря. Никакой оценки эффективности не проводится вообще, никаких выводов не делается. Как продавали "то, не знаю что" и обещали клиентам не выполнимое, так и продолжают это делать. Некоторые умные люди умудряются учиться на чужих ошибках, наши же манагеры с завидным постоянством даже на своих не учатся. Но это отклонение от основной мысли.
Для чего я кратко описал классы сотрудников? Чтобы указать на очередное глобальное упущение в управлении. Помимо прочего раздолбайства в нашей компании, художников, программистов и дизайнеров считают одним классом - чуваки, которые клепают игру. Все равны, соответственно, все методы управления и оценки работы - общие. Эти методы - ущербны, неразвиты, крайне неэффективны и применяются не по назначению. Ладно, они кое-как работают для художников из-за линейной природы их работы. Но для всех остальных нет. Для адекватного человека такое положение дел должно казаться странным. Для наших космонавтов всё впорядке - "у нас всё заебись", - повторяют они как заклинание.
Дополнено. Оказывается тоже стали замечать что не всё хорошо в королевстве. Видно когда денег стало мало, наконец дошло. Но в реальную причину проблем верить не хотят. Виноваты-то программисты!
Дополнено. Оказывается тоже стали замечать что не всё хорошо в королевстве. Видно когда денег стало мало, наконец дошло. Но в реальную причину проблем верить не хотят. Виноваты-то программисты!
Мысль 5
Об участии, вовлеченности, заинтересованности
Об участии, вовлеченности, заинтересованности
Для чего можно было бы применить все эти методолгии? Чтобы люди раскрывались многогранно и приносили максимально пользы. Взять, например, меня - я считаю, что я обладаю хорошими умениями и талантами в геймдизайне, при том, что я программист. Я инди разработчик и делаю игры самостоятельно от начала до конца и делаю хорошо, на инди-сцене мои игры оценивали достаточно высоко. Было бы классно если система могла задействовать меня всесторонне, применять мои навыки геймдизайнера. Возможно я бы даже перевоплотился в геймдизайнера из программиста. Это была бы истинная гибкость системы. Если бы хоть малая толика от этого сценария работала, я бы был счастлив.
Включить меня в отдел геймдизайна (при этом на 80% я по прежнему оставался бы программистом), где я бы отвечал за некоторые геймдизайнерские решения, под управлением геймдизайнерского лида. Но у нас нет геймдизайнесркого лида, нет отдела геймдизайна, нет ответственности за решения. Все равны, коммунизм. Реально этого даже отдаленно, нет. Общий паттерн - всем пофиг, люди это исполнители или материал (хавмайнд, наверное), новых программистов найти не проблема (угу, вон 20 штук нашли (не преувеличение!!!), только они поувольнялись все). Программист это чувак с клавиатурой, который фигачит код, когда ему скажут. В понимании начальства. Хайв майнд - разум роя, все равны и решения приходят благодаря ментальной энергии толпы. Одному мне кажется что это звучит как бред маразматика?
Я хочу инвестировать в своё развитие и чтобы люди видели как я развиваюсь и приношу пользу, что интересные решения исходят от меня, я продумал их и отвечаю за них. Придумать внятное дизайнерское решение - это не в лужу пёрнуть :) Всё это невозможно в текущей организации (кроме манипуляции с лужей). Вся инициатива тонет в безразличии, какой смысл придумывать интересные решения, если ты частичка улия. Как результат никто, ни за что не отвечает, не знает где-что лежит и как работает. Зато рой жужжит и у нас "всё хорошо".
Хочешь проявить творчество, придумал что-то новое в геймплее, придумал полностью игру? Молодец, нам похуй. Мы процессы улучшаем.
Включить меня в отдел геймдизайна (при этом на 80% я по прежнему оставался бы программистом), где я бы отвечал за некоторые геймдизайнерские решения, под управлением геймдизайнерского лида. Но у нас нет геймдизайнесркого лида, нет отдела геймдизайна, нет ответственности за решения. Все равны, коммунизм. Реально этого даже отдаленно, нет. Общий паттерн - всем пофиг, люди это исполнители или материал (хавмайнд, наверное), новых программистов найти не проблема (угу, вон 20 штук нашли (не преувеличение!!!), только они поувольнялись все). Программист это чувак с клавиатурой, который фигачит код, когда ему скажут. В понимании начальства. Хайв майнд - разум роя, все равны и решения приходят благодаря ментальной энергии толпы. Одному мне кажется что это звучит как бред маразматика?
Я хочу инвестировать в своё развитие и чтобы люди видели как я развиваюсь и приношу пользу, что интересные решения исходят от меня, я продумал их и отвечаю за них. Придумать внятное дизайнерское решение - это не в лужу пёрнуть :) Всё это невозможно в текущей организации (кроме манипуляции с лужей). Вся инициатива тонет в безразличии, какой смысл придумывать интересные решения, если ты частичка улия. Как результат никто, ни за что не отвечает, не знает где-что лежит и как работает. Зато рой жужжит и у нас "всё хорошо".
Хочешь проявить творчество, придумал что-то новое в геймплее, придумал полностью игру? Молодец, нам похуй. Мы процессы улучшаем.
Мысль 6
Об ответственности и иерархии
Помимо того что нужен разный подход к разным классам работников (программисты, художники, дизайнеры), считаю полезным иметь ранжирование специалистов. Один программист может сделать в 10 раз больше и лучше другого за то же время. Они не могут и не должны быть равны. Коммунизм уже пытались построить, не получилось. С чего вы взяли что у вас получится? Не надо считать себя умнее других, для этого нет никаких поводов. Как отражение естественного неравенства, можно ввести ранжирование специалистов. Как раз тут можно было бы использовать вашу гамефекацию, пусть программисты имеют уровни как в RPG. Пусть они имею карточки, абилки, классы. Вот где можно применить свою креативность, сделать интересный и эффективный подход, мотивировать людей на саморазвитие и результат. А не бумажные деньги пихать всем на ежедневном стендапе. Ладно, если не хватает ума продумать в деталях баланс такой системы, сделай хотя бы 4-5 уровней, со своими диапазонами зарплаты и условиями перехода на уровень выше. Это гораздо проще, но уже работает и будет давать результат.
Про разграничение ответственности я уже писал. Считаю недопустимой плоскую иерархию. Обязательная древовидная иерархия, разграничение сфер ответственности, лиды, отделы.
Об ответственности и иерархии
Помимо того что нужен разный подход к разным классам работников (программисты, художники, дизайнеры), считаю полезным иметь ранжирование специалистов. Один программист может сделать в 10 раз больше и лучше другого за то же время. Они не могут и не должны быть равны. Коммунизм уже пытались построить, не получилось. С чего вы взяли что у вас получится? Не надо считать себя умнее других, для этого нет никаких поводов. Как отражение естественного неравенства, можно ввести ранжирование специалистов. Как раз тут можно было бы использовать вашу гамефекацию, пусть программисты имеют уровни как в RPG. Пусть они имею карточки, абилки, классы. Вот где можно применить свою креативность, сделать интересный и эффективный подход, мотивировать людей на саморазвитие и результат. А не бумажные деньги пихать всем на ежедневном стендапе. Ладно, если не хватает ума продумать в деталях баланс такой системы, сделай хотя бы 4-5 уровней, со своими диапазонами зарплаты и условиями перехода на уровень выше. Это гораздо проще, но уже работает и будет давать результат.
Про разграничение ответственности я уже писал. Считаю недопустимой плоскую иерархию. Обязательная древовидная иерархия, разграничение сфер ответственности, лиды, отделы.
Мысль 7
Время, как метрика эффективности
Время, как метрика эффективности
- Дорога - 4 часа ежедневно, 4 часа * 5 дней = 20 часов в неделю.
- Ежедневный стендап 20 минут * 5 дней = 1 час 40 минут в неделю.
- Еженедельное собрание (ретроспектива, доклад с пирожками и т.д.), 2 часа в неделю
- Постоянные отвлечения (время переключения контекста) и шум в помещении (спасибо опенспейсу) + 1 час в день * 5 дней = 5 часов в неделю.
- Также в среднем часа 2-3 в день уходит на браузер и скайп по статистике собранной со среднего программиста. Могу сказать что лично я вообще не отвлекаюсь на нецелевые развлечения в течении рабочего дня. Поэтому возьмем это значение как 2 часа (учитываем необходимое использование браузера и скайпа с легкой надбавкой в 30%). Вообще это значение больше, и оно тем больше, чем больше хаоса в компании.
Теперь оценим сколько денег съедает бесполезная трата времени в эти 20 часов еженедельно. Именно бесполезная, т.к. я имел опыт обходится без этих модных методик и всё работало замечательно. Введем некую среднюю стоимость часа сотрудника компании 250р. Умножаем на 20 часов в неделю, получаем 5 тыс. рублей. Умножаем на приблизительное кол-во сотрудников конторы 30 человек. Получаем 150 тыс. в неделю. Или 600 тыс. в месяц. Это количество денег которые теряет компания ежемесячно из-за плохой организации. И это еще без учета ущерба, который получается косвенно, в результате неэффективной работы (незданные вовремя проекты, плохая репутация компании, немотивированность сотрудников и как следствие плохая работа). Косвенный ущерб еще больше, но его не так просто грубо посчитать. Итак, 600 тыс. эти деньги при идеальной организации можно вообще не терять. Идеал не достижим, но при грамотной организации эти потери можно уменьшить на две трети. Бережливое производство, аджаил (произносится мерзким булькающим голосом)!
Как я уже писал к программисту сходятся все ниточки и он выдаёт конечный продукт, поэтому расходование времени программиста наиболее критично. И чем меньше программистов (особенно хороших), тем более расточительно для компании не думать о его времени в особом режиме. В связи с этими утверждениями мои 20 часов в неделю на дорогу можно превратить в 15-16 часов посвященных проекту. т.е. 2 дополнительных рабочих дня в неделю. Если исключить бесполезный базар, под названием "коммуникация" и интегрировать её в процесс разработки, это ещё + 15-16 часов экономии (это из 20 часов которые описанные в предыдущем абзаце, их можно сократить легко на 75%). Говорить об опозданиях и махать грозно пальцем это вообще смешно, на фоне того глобального пиздеца, который творится в компании. Да, я знаю что это раздражает людей, когда я прихожу позже остальных. Потому что я предпочитаю работать в тишине, которая возможна только вечером, соответственно ухожу позже всех и работаю в среднем 9 часов в сутки. Я так понимаю гибкость. У вас нет других проблем, кроме моего прихода на 40 минут позже рекомендации? У вас больше 90 (!!!) процентов программных проектов сдаются не в срок и с нарушениями условий, у вас больше 20 (!!!) программистов уволились меньше чем за два года. А вы прессуете тех, кто героически устоял и хорошо работает, благодаря своим внутренним силам. Флаг вам
Главным показателем работы программиста является то, что он сделал, на сколько качественно он это сделал и насколько быстро. Контроль исполнения обязательно должен присутствовать со стороны лида. Поэтому раздражение некоторых манагеров, по поводу того, что программист работает из дома, надо преобразовать в эффективную систему контроля и эффективную систему управления проектом и подарить компании условно + 2 рабочих дня этого программиста в неделю. Понятно, что для этого существующий подход с хайв майндами не подходит (когда никто не отвечает ни за что). Тут надо не на самотек пускать( и удобно подводить модные методологии под свое нежелание или неумение работать), а работать и думать как наладить процесс с точки зрения эффективности для компании.
Для маленькой компании в 30 человек, вполне можно применять и индивидуальный подход для отдельных людей, чтобы достичь максимальной производительности и эффективности. И это по настоящему гибко (agile). Даже в крупных компаниях опускаются до такого, и даже в крупных компаниях не тратят столько времени на "околопроектные" нужды, которые у нас занимают 20 часов в неделю на человека.
Для маленькой компании в 30 человек, вполне можно применять и индивидуальный подход для отдельных людей, чтобы достичь максимальной производительности и эффективности. И это по настоящему гибко (agile). Даже в крупных компаниях опускаются до такого, и даже в крупных компаниях не тратят столько времени на "околопроектные" нужды, которые у нас занимают 20 часов в неделю на человека.
Мысль 8
Самоорганизующаяся система
Отсутствие организации приводит к самоорганизации. В теории аджайла. В реальности самоорганизацию не дают сделать сверху. Изнутри тоже проблема, на попытку расставить приоритеты или поставить задание можно сказать:
- я не считаю это важным
- я не буду этого делать
- я за это не отвечаю
- а я захотел так
- схуяли ты тут раскомандовался
Да и смысл брать на себя дополнительные обязанности если ты пчелка в улье. Ты подчиняешься общему процессу и, нежно покачиваясь на его волнах, несешься к процветанию компании. Во славу аджайла!
Организовывать процесс самостоятельно без каких либо рычагов - бесполезное занятие. Заставить людей плясать под твою дудку, без дудки. Тем более когда это никому кроме тебя не нужно. Система находится в энергетическом балансе, зачем дергаться, создавать дисбаланс. На тебя смотрят как на идиота, ну ладно надо тебе свою систему сделать, сделай. Нам пофиг, как вы внутренне у себя это пасёте (почти цитата). Главное на доске бумажку двигай - это наша главная система, она полностью покрывает все потребности компании, благодаря ей всё работает. А если не работает так это потому, что вы не правильно ей пользуетесь. Главное верить в это и выдавать желаемое за действительное.
В итоге самостоятельно наладить процесс можно только по договоренности и в малых кругах. При этом всё равно надо тратить время на клоунаду для начальства, которое верит что их система работает. Это намного больше энергозатрат( своя система + клоунада) и подходит только людям, которые знают что им нужно от работы в компании и как управлять разработкой самостоятельно. А самое главное, кто-то берет на себя роль неформального лида за бесплатно. Т.е. получается это должен быть человек без амбиций. Этакий лид без амбиций, или лид подавляющий в себе амбиции. Как показывает статистика и здравый взгляд на ситуацию - это невыполнимые сочетания условий.
В итоге, те кто тупо подчиняются аджайлам и канбанам в версии компании - тупо сливают все проекты и потом увольняются. Самоорганизация, в свою очередь, разрушается об стену тупости руководства. Вот такой негибкий аджайл.
Мысль 9
Результаты такой "деятельности"
За мои неполные 2 года работы уволилось больше 20 программистов. Средняя скорость увольнения 1.2 человека в месяц. Моё терпение тоже лопнуло и всё таки уволился, но я проработал дольше всех. 15 проектов не сданы в срок или сделаны с крупными нарушениями, овербюджетами или другими нарушениями. 1 проект сдан в срок - двухнедельный флеш-проект на 70% артовый, школьного уровня. Статистика достойная уважения и гордости! Ещё раз повторю, что я рассматриваю только проекты, где участвуют программисты, артовые проекты сдаются нормально, по причинам, о которых я писал - для них линейная система управления вполне приемлема. Эту статистику подвел я сам, есть предположение, что манагеры даже не задумывались в этом направлении. Всё и так хорошо.
Так вот. В полном хаосе люди начинаю обвинять друг друга ( явно и не явно ). Программисты плохо работают, у них много багов, они не успевают в сроки. Сарказм! Все 20 не успели в сроки, никто, блеать, работать не умеет. Всё потому, что не умеют работать по канбану, по отточеному мастером и доведеному до совершенства аджайлу, надо было внимательнее следовать указаниям настоятеля. Манагеры же продолжают пиарить себя на конференциях, вставлять умные словечки в презенташки. Когда смотришь на эти конференции сидишь либо с фейспальмом, либо сгораешь от стыда. Третьего не дано. Договоры по прежнему заключаются на заранее невыполнимые условия. Получается порочная зависимость, долги по одним проектам отбиваются авансами за новые взятые проекты. Ну и бедные художники, как на конвеере, держат ситуацию.
Наши сказочные друзья по прежнему продолжают талдычить своё без всякой привязки к реальности. Вводить кардинальные изменения пропорционально масштабам бедствия никто не собирается. А еще более яростно канбанят и гамифигачат. Наверное сделали вывод, что не достаточно насадили свой процесс, поэтому всё плохо. Рука ладонью сползает по лицу моему, фейспальм мой печален.
Вырезано. Убрал примеры из разработки, нет смысла и так много сказано. Смысл вырезанного, - если бы мне не мешали работать с их "процессами" я бы сделал всё в 3 раза лучше и быстрее.
Самоорганизующаяся система
Отсутствие организации приводит к самоорганизации. В теории аджайла. В реальности самоорганизацию не дают сделать сверху. Изнутри тоже проблема, на попытку расставить приоритеты или поставить задание можно сказать:
- я не считаю это важным
- я не буду этого делать
- я за это не отвечаю
- а я захотел так
- схуяли ты тут раскомандовался
Да и смысл брать на себя дополнительные обязанности если ты пчелка в улье. Ты подчиняешься общему процессу и, нежно покачиваясь на его волнах, несешься к процветанию компании. Во славу аджайла!
Организовывать процесс самостоятельно без каких либо рычагов - бесполезное занятие. Заставить людей плясать под твою дудку, без дудки. Тем более когда это никому кроме тебя не нужно. Система находится в энергетическом балансе, зачем дергаться, создавать дисбаланс. На тебя смотрят как на идиота, ну ладно надо тебе свою систему сделать, сделай. Нам пофиг, как вы внутренне у себя это пасёте (почти цитата). Главное на доске бумажку двигай - это наша главная система, она полностью покрывает все потребности компании, благодаря ей всё работает. А если не работает так это потому, что вы не правильно ей пользуетесь. Главное верить в это и выдавать желаемое за действительное.
В итоге самостоятельно наладить процесс можно только по договоренности и в малых кругах. При этом всё равно надо тратить время на клоунаду для начальства, которое верит что их система работает. Это намного больше энергозатрат( своя система + клоунада) и подходит только людям, которые знают что им нужно от работы в компании и как управлять разработкой самостоятельно. А самое главное, кто-то берет на себя роль неформального лида за бесплатно. Т.е. получается это должен быть человек без амбиций. Этакий лид без амбиций, или лид подавляющий в себе амбиции. Как показывает статистика и здравый взгляд на ситуацию - это невыполнимые сочетания условий.
В итоге, те кто тупо подчиняются аджайлам и канбанам в версии компании - тупо сливают все проекты и потом увольняются. Самоорганизация, в свою очередь, разрушается об стену тупости руководства. Вот такой негибкий аджайл.
Мысль 9
Результаты такой "деятельности"
За мои неполные 2 года работы уволилось больше 20 программистов. Средняя скорость увольнения 1.2 человека в месяц. Моё терпение тоже лопнуло и всё таки уволился, но я проработал дольше всех. 15 проектов не сданы в срок или сделаны с крупными нарушениями, овербюджетами или другими нарушениями. 1 проект сдан в срок - двухнедельный флеш-проект на 70% артовый, школьного уровня. Статистика достойная уважения и гордости! Ещё раз повторю, что я рассматриваю только проекты, где участвуют программисты, артовые проекты сдаются нормально, по причинам, о которых я писал - для них линейная система управления вполне приемлема. Эту статистику подвел я сам, есть предположение, что манагеры даже не задумывались в этом направлении. Всё и так хорошо.
Так вот. В полном хаосе люди начинаю обвинять друг друга ( явно и не явно ). Программисты плохо работают, у них много багов, они не успевают в сроки. Сарказм! Все 20 не успели в сроки, никто, блеать, работать не умеет. Всё потому, что не умеют работать по канбану, по отточеному мастером и доведеному до совершенства аджайлу, надо было внимательнее следовать указаниям настоятеля. Манагеры же продолжают пиарить себя на конференциях, вставлять умные словечки в презенташки. Когда смотришь на эти конференции сидишь либо с фейспальмом, либо сгораешь от стыда. Третьего не дано. Договоры по прежнему заключаются на заранее невыполнимые условия. Получается порочная зависимость, долги по одним проектам отбиваются авансами за новые взятые проекты. Ну и бедные художники, как на конвеере, держат ситуацию.
Наши сказочные друзья по прежнему продолжают талдычить своё без всякой привязки к реальности. Вводить кардинальные изменения пропорционально масштабам бедствия никто не собирается. А еще более яростно канбанят и гамифигачат. Наверное сделали вывод, что не достаточно насадили свой процесс, поэтому всё плохо. Рука ладонью сползает по лицу моему, фейспальм мой печален.
Вырезано. Убрал примеры из разработки, нет смысла и так много сказано. Смысл вырезанного, - если бы мне не мешали работать с их "процессами" я бы сделал всё в 3 раза лучше и быстрее.
Мысль 10 - заключительная
Как сделать эффективно или как бы я сделал для своей компании
Как сделать эффективно или как бы я сделал для своей компании
Иерархия взаимоотношений вместо плоской должна быть древовидной (как это сделано в нормальных конторах). Плоская не работает, она ведёт к тому, что никто ни за что не отвечает и, как говорил Ленин, приводит к разброду и шатаниям. Есть лид программер, который отвечает за своих программистов и за общее видение проекта, он отвечает за сроки реализации фичей, контроль исполнения и укладывание в сроки по спринтам. Есть продюсер, который общается с заказчиком и служит как бы передаточным звеном между заказчиком и гейм дизайнерами, художниками, программистами. Продюсер - также связующее звено между креативной составляющий проекта и формальным воплощением идей. Продюсер, лид программер и лид геймдизайнер обязаны знать в деталях как и что делается на проекте. Только лид программер больше в технической плоскости а продюсер и гейм дизайнер более поверхностно, по всем областям. Все вместе они держат фокус и не дают проекту развалиться. Этого, например, нельзя требовать от простого программиста. На схеме показано кто с кем непосредственно общается и кому подчиняется. Непосредственно с заказчиком общается продюсер, вырабатывает требования и обрабатывает данные, адаптирует их для исполнения. Все остальные участники проекта получают эти данные в обработке продюсера. Лид программер поставляет билды совместно с QA. Определяющие решения для желтых прямоугольников исходят от продюсера (после совместного обсуждения или после требований заказчика). Желтые прямоугольники тесно взаимодействуют между собой и обработанные решения спускаются исполнителям их подчиненным -белым прямоугольникам.
Также не исключены взаимодействия не отображенные стрелками (стрелки лишь строгое обозначение информационных потоков в идеальном мире). Например, художники могут выяснять непосредственно у дизайнеров как должны выглядеть некоторые элементы или у программистов как подготовить данные. Гейм дизайнер может общаться непосредственно с заказчиком вместе с продюсером. Программист может участвовать совместно с геймдизайнером и продюсером в обсуждении каких-то деталей с заказчиком. И так далее практически в любых комбинациях. Строгих ограничений нет, возможность проявить себя есть у каждого (вот она реальная гибкость). Но ответственность за решения несут лиды перед продюсером. Тот в свою очередь ответственен за решения команды перед заказчиком.
Что касается инструментов : редмайн + краткий отчет в несколько предложений в конце рабочего дня в гуглотаблицу.
PS Это уже вторая редакция статьи. Первую я убрал по этическим соображениям, т.к. во-первых там было много мата и злости, а во-вторых меня попросило наше руководство лично. Я перед увольнением дал почитать руководству первую версию статьи (с матом :) ), в надежде, что буду услышан, что будут сделаны выводы. Итогом стало, что на меня обиделись, никаких выводов сделано не было, руководство продолжает гнуть свою линию, невзирая на очевидные и катастрофические результаты такой деятельности. Более того, эффект получился обратный, методологии стали применяться ещё яростнее, убрали редмайн, что хоть как-то позволяло иметь вижн процесса разработки.
Поэтому, отдохнув и очистившись от чувства несправедливости и накопившегося разрдрожения (хотя не до конца), я сильно отредактировал статью, убрав оскорбительные фразы. Постарался добавить больше конструктива и убрать эмоции. Конкретики как не было так и нет, я явно не тычу пальцем. Учитывая что мой блог объективно никто не читает (посещаемость почти нулевая), я не наношу никакого ущерба компании, более того, я не раскрываю никаких конкурентных преимуществ компании и т.д. В реальности я просто обозначил свою позицию для коллег и задокументировал события на память для себя, - это и есть текущая цель статьи.
Также не исключены взаимодействия не отображенные стрелками (стрелки лишь строгое обозначение информационных потоков в идеальном мире). Например, художники могут выяснять непосредственно у дизайнеров как должны выглядеть некоторые элементы или у программистов как подготовить данные. Гейм дизайнер может общаться непосредственно с заказчиком вместе с продюсером. Программист может участвовать совместно с геймдизайнером и продюсером в обсуждении каких-то деталей с заказчиком. И так далее практически в любых комбинациях. Строгих ограничений нет, возможность проявить себя есть у каждого (вот она реальная гибкость). Но ответственность за решения несут лиды перед продюсером. Тот в свою очередь ответственен за решения команды перед заказчиком.
Что касается инструментов : редмайн + краткий отчет в несколько предложений в конце рабочего дня в гуглотаблицу.
PS Это уже вторая редакция статьи. Первую я убрал по этическим соображениям, т.к. во-первых там было много мата и злости, а во-вторых меня попросило наше руководство лично. Я перед увольнением дал почитать руководству первую версию статьи (с матом :) ), в надежде, что буду услышан, что будут сделаны выводы. Итогом стало, что на меня обиделись, никаких выводов сделано не было, руководство продолжает гнуть свою линию, невзирая на очевидные и катастрофические результаты такой деятельности. Более того, эффект получился обратный, методологии стали применяться ещё яростнее, убрали редмайн, что хоть как-то позволяло иметь вижн процесса разработки.
Поэтому, отдохнув и очистившись от чувства несправедливости и накопившегося разрдрожения (хотя не до конца), я сильно отредактировал статью, убрав оскорбительные фразы. Постарался добавить больше конструктива и убрать эмоции. Конкретики как не было так и нет, я явно не тычу пальцем. Учитывая что мой блог объективно никто не читает (посещаемость почти нулевая), я не наношу никакого ущерба компании, более того, я не раскрываю никаких конкурентных преимуществ компании и т.д. В реальности я просто обозначил свою позицию для коллег и задокументировал события на память для себя, - это и есть текущая цель статьи.
Комментарии