Т.к. среди читающих меня - программистов почти нет, а тем более
занимавшихся управлением работой отдела программирования, включая
игровые проекты, то для интересующихся темой - привожу упрощенную
версию:
Рядовые программисты занимаются ТОЛЬКО 2 вещами: 1) Фичи
(новая кнопка, новый танк). 2) Исправление багов (кнопка вылазит за
экран, у танка не вращается башня).
Другими словами: ИЛИ делают фичи, ИЛИ правят баги.
Менеджмент
IT-компании (вроде "обсидианов") может задавать приоритеты, например: В
ОСНОВНОМ ФИЧИ. - Тогда накапливаются баги, потому что время на
исправление их - НЕ ВЫДЕЛЯЮТ. Если рядовой программист начнет
САМОСТОЯТЕЛЬНО делать то, что лично ему кажется правильным, то его
уволят. Без вопросов.
Если кто-то помнит, то у "обсидианов" был
управленец, вроде Ричарда Тейлора, или как там его звали - который даже
оправдывался, что приоритет стоит на "фичах".
ПОЧЕМУ менеджмент
IT-компании - может так делать? - Потому что так требует заказчик
("Нужно срочно вводить, фигли вы там копаетесь???")
Если заказчик
(другая компания, например, издатель игры) не понимает специфики
программирования (имеет только MBA - это только бизнес-образование, но
не имеет IT-образования) - то ему в принципе сложно понять и
контролировать - чем занимаются программисты и занимаются ли вообще
чем-то. Именно такой заказчик зачастую и требует "фичи", слабо понимая, к
чему это может привести.
К чему же? Читаем далее:
Работа
рядового программиста - на 15% состоит из обдумывания и набирания
программного кода, и на 85% - из попыток запустить это чудо и, по
показываемым, системой, ошибкам - отловить все баги и нестыковки.
Если
программист не может нормально отладить свой же код (чтобы он нормально
работал) - его увольняют. Есть всякие мелкие баги и нестыковки, который
программист видит сам и, 85% своего времени - убирает их. Но некоторые
баги - проявляются позднее, например при попытке соединить свой код - с
кодом других программистов. При таких, например, слияниях кода - растет
сложность анализа проблемы - это твой косяк или другой программист
напортачил? Сложность анализа проблемы - может вырастать в 100 раз, ЕСЛИ
по ходу дела - не убирать уже обнаруженные баги. А если заказчик
требует результат (фичи), слабо понимая, что баги, наслаиваясь друг на
друга - увеличивают сложность исправления их - экспоненциально? Иногда
ресурсов человеческого мозга может не хватать, чтобы понять - что именно
привело к такому-то багу. Повторюсь - если программист не может
совладать со всем этим, то его могут уволить. Отсюда вывод: чем меньше
багов - тем проще с ними разобраться программисту, и тем меньше шансов,
что его уволят. Другими словами: РЯДОВОЙ ПРОГРАММИСТ - крайне
заинтересован в искоренении багов. Иначе он может не справиться со
слишком сложным нагромождением багов. И его уволят. А быть уволенным -
никто не хочет.
- Ситуация упрощена: есть специализированные
должности у программистов, например Архитекторы проектов, которые следят
за грамотным сочетанием кусков кода разных программистов. Или еще одна
должность - Team Lead (старший программист, начальник над рядовыми
программистами, упрощенно говоря) - он работает с самыми сложными
вещами, а так же помогает менее опытным, рядовым программистам. - Эти
должности у программистов - призваны помочь справиться со многими
проблемами. Другими словами - механизм самосохранения, и узкая
специализация - кто за что отвечает.
Но в этот механизм
самосохранения (со своими начальниками, во главе которых, зачастую -
должность Технического директора) - вмешивается другая иерархия власти -
бизнес-направление ("А мы посмотрели в других играх - на рынке очень
востребована карта местности, желательно справа вверху экрана").
Возглавляет бизнес-направление - Продюсер проекта. Продюсер проекта
непосредственно руководит геймдизайнерами-картоделами. И опосредовано -
задает направление работы программистам. При этом программисты могут
"отбрыкиваться" - "У нас это не получается, пока это технически не
возможно". - Тогда продюсер чешет репу и ставится перед фактом, что
технический отдел - пока не может реализовать затребованную им
бизнес-функцию.
На заре IT-индустрии - IT-проекты часто
проваливались, не выдерживались сроки реализации, в частности. Но т.к.
программированием занимаются преимущественно люди с некоторым
определенным интеллектом - то самые умные в IT-области - наконец
догадались, как лучше все организовать. Есть целая область знаний по
этой области - Объектно-ориентированный анализ. А мэтры жанра, в лице в
том числе и Мартина Фаулера - написали учебники и теперь ряд
IT-направлений, например программирование на Java - там даже рядовые
программисты - знают книги этого Фаулера и активно, каждый день,
применяют знания из них - в работе.
Так же, к сожалению, всякие
курсы, предлагающие знания по УПРАВЛЕНИЮ IT-проектами - не дают полноты
знаний по этому вопросу, а это означает, что управленец с
бизнес-образованием вроде MBA - может иметь весьма смутное и сумбурное
представление по этому вопросу, если пройдет ускоренный курс, но сам в
программировании ничего не смыслит.
Отсюда и появляются такие
вещи, как приоритет "фич" над "багами", и, как следствие - повальная
забагованность проекта. Но, как писал ранее - проблема не в рядовых
программистах. У них то - крайняя заинтересованность в убирании багов
(иначе они вообще не смогут ничего добавлять в неработающий код). - Сами
рядовые программисты - это рабы на галерах. Они могут выдавать
рекомендации или информировать о трудностях, их мнения могут авторитетно
подкреплять начальство из IT-вертикали власти - Team Lead и Архитектор
проекта. Или и их начальник - Технический директор (если таковая
должность есть).
Но если заказчик продолжает давить, слабо
понимая о последствиях ("Нужны фичи через 2 месяца, или мы расторгнем
контракт и поищем более квалифицированных исполнителей") - то что
делать? Делать остается "фичи", прекрасно понимая, какие проблемы в
будущем огребет заказчик.
У заказчика тоже могут быть свои договора - ссуда в банке, желающие результатов акционеры (и т.д.)
Поэтому, на первый взгляд - виноватых как бы вообще нет.
На
практике же все решает процент идиотов и гениев. Есть все книги, есть
отдельная область знаний, все расписано - КАК лучше всего нужно сделать и
организовать. Есть специалисты, и даже рядовые программисты - в разной
степени, но понимающие, как правильно, а что не очень. Но если в
руководстве много, мягко так скажем - не очень опытных в вопросе людей,
то и они кадры подбирают под себя, особо умных и БОЛЕЕ знающих, чем
начальник - никто не любит. Вымываются из компании даже те, кто хорошо
все понимает и дело идет в разнос.
Опять же, на практике - иногда
в компаниях занимаются внутренним аудитом/проверкой, в частности такую
операцию сделала одна компания, занимающаяся танковой игрой, примерно
около года назад, такую операцию провела - и, из сообщений в блогах и в
прочих Интернет-ресурсах - можно сделать вывод, что часть управленцев
было заменено.
Даже то, что по результатам проверки - работа вроде 12
отделов была признана неудовлетворительной - само по себе было
удивительной и приятной новостью, т.к. Интернет вообще и Ютуб в
частности - были наполнены негативом по данной игре.
Так же руководитель компании - прилюдно посыпал голову пеплом, признал все ошибки.
В компанию вернули часть руководителей среднего звена, стоявших у ее истоков.
На сколько это решило вопрос, или только частично - лично я сказать не
берусь. Но субъективно скажу, что отвесное падание вниз - возможно и
прекратилось. 2 характерных момента: хотели занерфить бат-чат, но из-за
массового волнения игроков по этому вопросу - этого не сделали. Это
пример в "плюс", просто пример. Другой пример - переделали дизайн
главной страницы сайта, под "плиточный", моим знакомым и мне - не
понравилось. Новости читать стало менее удобно. Это пример в "минус".
Но начало данной публикации - было вовсе не про компанию, разрулившую ситуацию с бат-чатом, совсем не про нее, а про другую.
А теперь представьте ситуацию:
1) Игроки "вайнят" на Баланс 2.0. И на баги.
2) В компании ищут ответственных за это дело. "Крайнего".
3) "Крайним" по определению не может быть босс, т.к. если босс не прав - см. пункт такой-то - босс всегда прав. Т.е. управленцы высшего звена - по определению не правыми быть не могут.
4) Кого-то в итоге "выпихивают". Кстати, что интересно, на днях был ответ от ВГ, на вопрос следующего плана: "Правда ли, что вы взяли на работу программиста из Арматы, связанного с Балансом 2.0 там???" - Ответ был примерно такой: "Да, но это не программист" (далее по ответу - что это что-то вроде руководителя, работавшего с Балансом 2.0).
5) С темой "Кто виноват?" - что-то и как-то (?) решили (могли убрать как самого умного, так и самого глупого, как самого жадного, так и самого порядочного - инсайда у меня нет, да и если бы и был - то не привел бы), далее традиционно у нас люди переходят к вопросу "И че терь делать???"
6) Отдуваться приходится тем, кто сейчас есть и что-то делает. При этом багов куча (последние праздники - один из примеров, посмотрите на официальном сайте о компенсациях игрокам за баги, а то что ввели не более 2 арт в одном бою - на самом деле не более 2 арт - уже более месяца так по факту, возможно "узаконили" хоть какое-то исправление бага, это же не 4 арты -
внезапно так стало работать, вот и узаконили - на правах догадки).
7) При "отдувании" за баги - категорически нельзя показывать пальцем на "заказчика" - это же топ-менеджеры своей компании. За такое кивание на начальников своего начальника - что будет? Будет поиск новой работы. - Палец не может бить руку, частью которой он является. Иначе это палец-мутант какой-то, а такой сразу изничтожат.
8) На кого еще можно спихнуть теперешние баги? - Вариантов всего 2: на "обсидианов" в целом (но так можно на иск нарваться, да и вообще прилюдный скандал в отрасли) и на рядовых исполнителей, типа багоделов, из "обсидианов". - Они то рабы на галерах, но это самый беспроигрышный (и безопасный) вариант. На игроков то баги не спихнуть? - Не, запинают в ответ. - НЛО, пришельцы? - Может не прокатить. Рядовые горемыки из "обсидианов" - вот кто сейчас, оказывается, верховодил всем. Плодил баги. И размножался. Багами.
Ну а пример с другой "танковой" компанией - да, так бывает на рынке публичных компаний (или, как в данном случае - кто пробовал таковой, в какой-то мере, быть). Но это уже из области бизнеса, совсем другая тема.
Пасибо за внимание. :)