Т.к. среди читающих меня - программистов почти нет, а тем более
занимавшихся управлением работой отдела программирования, включая
игровые проекты, то для интересующихся темой - привожу упрощенную
версию:
Рядовые программисты занимаются ТОЛЬКО 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: на "обсидианов" в целом (но так можно на иск нарваться, да и вообще прилюдный скандал в отрасли) и на рядовых исполнителей, типа багоделов, из "обсидианов". - Они то рабы на галерах, но это самый беспроигрышный (и безопасный) вариант. На игроков то баги не спихнуть? - Не, запинают в ответ. - НЛО, пришельцы? - Может не прокатить. Рядовые горемыки из "обсидианов" - вот кто сейчас, оказывается, верховодил всем. Плодил баги. И размножался. Багами.
Ну а пример с другой "танковой" компанией - да, так бывает на рынке публичных компаний (или, как в данном случае - кто пробовал таковой, в какой-то мере, быть). Но это уже из области бизнеса, совсем другая тема.
Пасибо за внимание. :)
Рядовые программисты занимаются ТОЛЬКО 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: на "обсидианов" в целом (но так можно на иск нарваться, да и вообще прилюдный скандал в отрасли) и на рядовых исполнителей, типа багоделов, из "обсидианов". - Они то рабы на галерах, но это самый беспроигрышный (и безопасный) вариант. На игроков то баги не спихнуть? - Не, запинают в ответ. - НЛО, пришельцы? - Может не прокатить. Рядовые горемыки из "обсидианов" - вот кто сейчас, оказывается, верховодил всем. Плодил баги. И размножался. Багами.
Ну а пример с другой "танковой" компанией - да, так бывает на рынке публичных компаний (или, как в данном случае - кто пробовал таковой, в какой-то мере, быть). Но это уже из области бизнеса, совсем другая тема.
Пасибо за внимание. :)
0 коммент.:
Отправить комментарий