Русский
Русский
English
Статистика
Реклама

Менеджмент проектов

Расшифровка почему у монетизаторов нет души, а токсичные члены команды самые эффективные

25.07.2020 12:17:52 | Автор: admin

Наверное, это один из самых откровенных прямых эфиров, которые мы проводили, причем с представителем двух самых ненавидимых профессий в геймдеве: монетизатором и менеджером.

7 июля в нашем инстаграм-аккаунте выступил Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем. Слава работал в игровых подразделениях веб-мани, mail.ru, Фотостраны и принимал участие в более, чем 50 других проектов.

Во время эфира он без буллшита и увиливаний рассказал:

  • как погибают интересные игры с плохой монетизацией и как монетизаторы превращают такие проекты в прибыльные
  • почему иногда монетизация важна самим игрокам
  • почему нельзя делать справедливые игры, где у всех равные возможности
  • почему не стыдно всю жизнь остаться середнячком, а не стать гением
  • почему нельзя отправлять на конференции лучших сотрудников
  • почему игровой программист главный человек в геймдеве
  • что это за люди, вливающие в онлайн-игры по миллиону рублей в месяц
  • почему нельзя увольнять токсичных людей и как они могут быть самыми эффективными людьми в команде
  • как стрессоустойчивость помогает вырасти в зарплате на целые порядки

Делимся с вами расшифровкой.



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

Основная позиция, с которой я начинал это гейм-дизайнер. После этого я вырос до менеджера, некоторое время занимался монетизацией, 3 раза был на позиции продюсера и руководителя направления. Принимал участие в 50+ игровых проектах, на различных площадках мобильных, социалках, браузерках, клиентских играх. Такой у меня опыт. Максимальное количество людей, которыми руководил 32. Основные компании, с которыми я работал MAIL.RU, Фотострана, Аватарика, дочернее отделение WebMoney. И еще много мелких.

Есть ли монетизация после лутбоксов кроме battle pass с лутбоксами?


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

Дальше, если игра забуксовала, то можно выпустить новый ивент и сделать такую монетизацию, чтобы пройти его полностью можно было бы только за 50$, например. В случае, если игрок хочет пройти положить ему первый, самый значимый, приз, если он будет активно играть неделю (столько времени длится эвент) и заплатит всего 1$. В этом моменте ты ему кладешь что-то жизненно важное.

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

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


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

Если игроку кажется, что комьюнити будет небольшим это не значит, что разработчики так видят и так считают.

Они запускают проект, в нем, допустим, 3000 пользователей. Они видят, что возвраты 30-го дня 25%. Это говорит о том, что, если они нальют гораздо больше трафика, у них будет гораздо больше пользователей.

Периодически некоторые из площадок, на которые мы играем кстати, ru-сегмент в них входит нужны для обкатки основных игровых механик. То есть, ты видишь, что игрушка маленькая и обещает быть небольшой значит, разработчики не собираются локализовываться (на Японию, на мобилки, на клиентские игры). То есть, они в Steam выложились и там барахтаются. Но это может быть не так.

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

Второй вариант когда качество комьюнити игры выше всяких похвал. На моей памяти были такие продукты, которые на 2К пользователей делали выручку по 100 миллионов рублей, потому что эти пользователи были очень обеспечены и привыкли играть за большие деньги. Им это нравилось, их все устраивало, и под них и их желания всё делалось. Ну, хочет человек выбрасывать кучу денег каждый день на себя, или даже одевать весь свой клан, если у него столько свободных денег; хотя клан и так уже раздавил всех на сервере, он все еще продолжает этим заниматься.

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

Ну, и третий вариант: человек, который делал монетизацию, некомпетентен. Так нечасто бывает, хотя этот вариант всегда надо отрабатывать, если видишь что-то явно неинтересное. Желательно, чтобы были первые два варианта.

Откуда берутся большие пласты игр, в которые люди с интересом играют, но игра при этом не зарабатывает? Что делает монетизатор с такими играми?


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

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

Недавно был пример: игра была Топ-4 во всем мире среди AR-игр и приносила очень скромные деньги. Идея была в том, что пользователь поиграет в нее, проникнется и сам заплатит. Но пользователь это делает не очень часто, если его не мотивировать.

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

Потом эти ребята приходят к монетизатору и говорят: давай сделаем так, чтобы игра стала приносить деньги на зарплаты и сервера? Пусть она и станет чуть менее интересной.

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

В стартовом пакете будет набор золота и кристаллов с волшебным мечом, это все стоит 2 доллара. Мы смотрим, как часто этот пакет показывается пользователю. Собираем статистику: в игру зашло, например, 12К новичков, и из них только 500 увидело предложение? Это мало. Увидеть должны все 12К, которые зашли. Хотя еще надо сделать поправку на то, чтобы пользователь прошел туториал и увидел предложение после него (допустим, туториал пройдет 9К из 12 все 9К должны увидеть предложение).

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

Дальше мы смотрим на то, что будет после того, как пользователь купит предложение изменится ли качество его игры? Может быть, меч, который входит в него, ничего особенного и не дает игроку тогда надо задать вопрос: Зачем вы сделали такое предложение, которое пользователю неинтересно покупать?

Разработчик отвечает, что не хочет дисбаланса, или что-то подобное. Но ведь он мог дать что-то по-настоящему полезное! Он хотел создать куклу условно-годное предложение, которое на самом деле не годное; думал, что это будут покупать. Это неправильный подход.

Что можно сделать? Пример того, что можно сделать: мы даем пользователю возможность пройти, например первые локации или волны с мобами на удобной и комфортной позиции. Он все легко делает, все красиво.

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

Насколько этична монетизация, влияющая на игровой процесс?


Максимально этична.

Предположим, ты офисный работник. Целыми днями на работе, вечером играешь, чтобы расслабиться. Ты в своем праве, тебе хорошо, ты хочешь получить удовольствие.

Но, если ты напорешься в pvp на школьника, который весь день фармил, то ты будешь раз за разом выхватывать от него. Школьники сильно мотивированы фармить, они это делают все те 10 часов, пока ты работаешь у них будет куча золота и всего остального. Такой процесс тебя будет только злить, а не веселить.

Но если в монетизацию заложено правило типа 1 час фарма = 1 доллар, то через 10 часов школьник хоть и нафармит эти условные 10 долларов (и будет чувствовать, что он молодец), ты придешь и просто вложишь эти 10 долларов, и будешь наравне с ним.

Или, если хочешь его побить с гарантией, вложишь 20. На следующий день он будет более мотивированно фармить.

Ты приходишь с работы, ты устал, тебе плохо ты меньше всего хочешь сейчас проигрывать 4 катки, чтобы настроение падало еще сильнее. Ты хочешь побеждать и релаксировать, и денежка поможет тебе это сделать.

В каких случаях в проекте нужны монетизаторы?


Наверно, в тех, когда игровая модель срослась, у продукта есть известность, и все основные монетизационные методы опробованы.

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

Во-вторых, когда надо повысить доходы. Допустим, они постепенно росли, пока ты прикручивал к продукту функционал это всегда дает рост. Но в один момент они перестают расти допустим, когда контента уже года на 4.

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

В целом, все просто. Если есть проект, и нужно, чтобы он больше зарабатывал то нужен монетизатор.

Четыре архетипа пользователя хардкорщик, школьник, домохозяйка, офисный сотрудник (играет, чтобы отдохнуть): четыре жизни, которые проживает монетизатор с каждой игрой.


Это правдиво. Каждый раз, когда меня приглашают в новый продукт, я запускаю 4 игровые сессии. Мне на это обычно нужно 2-2,5 дня. Я проживаю все эти 4 типа жизни параллельно.

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

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

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

И офисный сотрудник: у меня тяжелый день, я просто хочу отдохнуть. Мне нафиг не нужно еще чем-то нагружать свой мозг, я хочу просто заучить привычные схемы и билды, и побегать. И я ни в коем случае не хочу, чтобы меня нагибали. Так как я добросовестный сотрудник, у меня нет возможности заходить по 10 часов в игру и фармить. Если важные игровые эвенты приходятся, например, на 14 или 16 часов дня, офисный сотрудник сразу отваливается ему игра не будет интересна, он не сможет конкурировать с другими.

Я за день провожу сессию в каждой из этих 4 жизней, и повторяю на следующий день и через день. Я стараюсь определить, насколько продукт соответствует всем четырем типам. Хотя они и принципиально разные, действительно существуют продукты, которые соответствуют всем.

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

Неграмотный сбор аналитики: как нельзя делать, чтобы не остаться с популярной игрой, но в нулях?


С неграмотным сбором аналитики я сталкивался за последние 2 года довольно часто. В моей любимой компании, где я работал раньше, такого слабого отношения к аналитике не было. Но, как правило, людей устраивает общее количество аналитики в Unity Analytics / AppStore Connect / Firebase, и они глубоко не копают.

Допустим, есть эвент, который начинается и заканчивается в пятницу. Мы его запустили, увидели, что в него не играют допустим, из 12К игроков его прошло 300. Вывод эвент непопулярный, больше не запускаем.

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

Едем дальше: может быть, люди зашли, но застопорились на 3 шаге из 12? Надо залезть в баланс и посмотреть, что там. Может, там что-то сложнопроходимое, что нужно переделать или сделать так, чтобы эту штуку можно было пройти за 0.50$. Возможность выбора игроком между днями фарма и небольшим взносом это нормально.

Кроме этого, конечно, есть еще огромное количество аналитики, которая неправильно собирается.

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

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

Почему нельзя делать справедливые игры, где у всех равные возможности?


Попробуйте примерить эту ситуацию на себя. Я к вам подхожу и говорю а заплатите 10$. Вы говорите а что мне за это будет? А ничего не будет, только скин красивенький, и все. Ты не будешь сильнее, ничего не изменится.
Ты скажешь не, не хочу. И будешь прав! Пользователи платят за что-то ощутимое. Женщины хотят быть самыми красивыми, мужчины хотят быть самыми сильными. Вот если я предложу меч, который на 20% сильнее обычного не надо на 200%, 20% достаточно ты заплатишь, и будешь знать, что у тебя одна из вещей комплекта на 20% круче.

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

Ты тогда либо терпишь еще полгода без бонуса, либо покупаешь ее за $40. Конечно, это не должно создавать супер-дисбаланс. Не должно быть такого, что ты что-то покупаешь за 10$ и идешь бить весь сервер. +20% силы за вещь, стоящую денег это нормально: если человек соберет несколько таких вещей, то он сможет побить с гарантией одного другого игрока, но не двух.

И не надо забывать давать простым игрокам возможности фармить какие-то из этих вещей.

Любой игрок должен иметь возможность нафармить на малый комплект, например, за 3 недели на каждую вещь. Допустим, если в нем 3 вещи, то это 2 месяца контента для неплатящего игрока. Это вполне хорошо.

Либо ты тратишь 50$ и два месяца фарма пропускаешь, оказываясь наравне с теми, кто пришел в игру раньше и фармил эти два месяца, либо сам фармишь.

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


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

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

А вот человеку, не находящемуся в мире игр, потребуется не 3 фразы, а 3 страницы ТЗ что делает каждая вещь, каким образом, нужно будет нарисовать кучу картинок, расписать, что делает зелье, что делает меч, в какой слот нужно их совать. И даже тогда, когда ты это все распишешь, человек все равно не поймет сразу это трехлистное ТЗ придется разбирать с ним вместе, отвечать на наводящие вопросы, и после этого он придет к тебе еще раза 3-4.

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

Допустим, человек покупает игру за фуллпрайс. Исторически сложилось так, что игра, стоящая фуллпрайс, предлагает игроку весь свой контент и полноценный игровой процесс. Но если модель игры будет такая, как вы предложили, то баланс будет настроен таким образом, что для комфортной игры нужно будет купить что-то еще сверх фуллпрайса, либо будет ощущение того, что часть контента и механик вынесена в DLC. Сейчас это уже происходит раз за разом. Стоит ли оно того с точки зрения лояльности сообщества и дальнейшей перспективы построения IP?


На самом деле, всякая дальнейшая перспектива IP это красивые слова, имеющие мало общего с реальностью. Денег много не бывает. Видишь, что можешь получить деньги получай деньги.

Дополнительный контент для полноценной игры сравнительно недавно появился как феномен, примерно с очередного Assassins Creed. Там прикрутили к ААА-игре искусственный баланс, который требовал фармить, но можно было заплатить еще и играть комфортнее.

Может, это и не совсем здорово. Но, если это эффективно а, раз так считает Ubisoft, то это должно быть эффективно то они молодцы.

Недостаток такой модели в том, что, действительно, после реализации такой вещи в твоем продукте падает лояльность пользователей. Если следующий продукт сделать хуже действительно получится так, что ты зарезал золотую курицу. Это не повлияет на уже существующие части Assassins Creed, но повлияет на будущие.

Но бывает такая ситуация в компании, когда с деньгами все плохо, и для того, чтобы выгрести и остаться на плаву следующие 5 лет, нужно сейчас заработать больше денег иначе не будет компании и следующих игр. Такое вообще часто бывает в компаниях, которые раздувают свой штат; доходы падают, и возникает такая ситуация, когда неясно, как выплатить неплохие зарплаты 300 людям (с неплохими налогами).

Лояльность сообщества и это измеренная цифра, в неё можно верить выражает мнение всего 5% игроков. Все, кто активен на форуме и нытики, и хвалильщики это 5% от всех игроков.

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

У нас были такие ситуации, когда пользователь громко орал на форуме LITERALLY UNPLAYABLE, В ИСПОРТИЛИ МНЕ ВСЮ ИГРУ, ДА ЧТОБ Я ЕЩЕ ИГРАЛ У ВАС. Тогда я просил программиста отслеживать логи этого персонажа.

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

И я тогда думаю ну ладно, человек погорячился. Может, у него потребность ходить и ругаться, как у бабки в поликлинике. И ничего особенного.

Делать выводы нужно из аналитики. Если ты запускаешь событие, и после этого отваливаются пользователи, платежей становится меньше то это действительно плохо, событие плохое. А если все происходит наоборот, но при этом на форуме кто-то орет ну и пусть орет.

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

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

Если коротко: человек что-то купил и верит, что купил целиком мы его обманываем?


Да. И это не очень хорошо.

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

Были ситуации, когда вводилась, например, коллекция мечей, продаваемая за деньги, и после этого (через полгода) новая коллекция, лучше старой, и тут же пошли иски в суд. Штук 600. Потому что ты тогда, полгода назад, не предупреждал пользователей, что будут мечи еще лучше, и этим нарушил их права.

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

Залезьте в какую-нибудь игру от Blizzard и её EULA, посмотрите, как конкретно игроков обманывают они. Они уже более 16 лет бодаются с исками от пользователей из WoW, из Diablo.

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

Существуют ли люди, которые в одиночку создали игры мирового уровня?


Да, существуют.

Когда-то давно, на заре становления индустрии, был IceFrog создатель DotA. Первая DotA была просто картой, созданной в редакторе для WarCraft III там можно было самому дизайнить, прописывать скрипты.

У него была идея, и он создал шедевр мирового уровня. IceFrog на каждом обновлении (где были бы, допустим, два новых героя) зарабатывал по 50 тысяч долларов. Потом этого он ушел, игра развилась и спасла WarCraft III от загибания. Самого IceFrog перекупили Valve, и он создал DOTA 2 но на старте он был один.

Специалисты сейчас поправят, что на самом деле разработчик изначально был другой, он исчез в неизвестном направлении, а IceFrog его карту присвоил но это частности.

Второй пример это Notch. Это программист, который создал Minecraft по большей части, один. До Minecraft он сделал 50 продуктов, о которых никто ничего не знает и не слышал, но только Minecraft загремел на весь мир, и в 2012 Notch вошел в десятку самых влиятельных игровых компаний мира (будучи одним человеком), на седьмое место.

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

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

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

Есть одиночки мирового уровня, есть те, кто просто выживает сам по себе. Важно понять вот что: компания из 300 людей, где самый низкооплачиваемый сотрудник получает 3000 евро (и это все умножается на налоги) обязана зарабатывать огромные суммы, чтобы просто существовать. А маленькая команда из одного человека может запускать мелочь, которая приносит 200 тысяч рублей в месяц в течение, допустим, трех лет.

Если ты всего один, то это хорошо. А такой продукт может быть и не один, а три, например. А еще один из них может выстрелить даже до 10 миллионов рублей в месяц. Если ты платишь только налоги и аренду сервера, то есть, не снимаешь офис, не содержишь штата сотрудников то это вообще круто.

Успешные одиночки существуют: программисты, художники, гейм-дизайнеры. Даже маркетологи: он заказывает какой-нибудь проект и знает, как наливать на него трафик. Сейчас много контор, которые собирают под ключ, допустим, игры типа три в ряд по 10 тысяч долларов. Ты такую купил, знаешь, как работать с трафиком и льешь его. Если видишь косяки студия быстро апгрейдит проект в тех местах, которые ты называешь. Одиночки гораздо лучше выживают, потому что они более гибки, и их не интересуют миллиарды им достаточно небольших денег, чтобы быть на плаву и считаться успешными.

Можно ли создать игру почти бесплатно?


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

После этого, если ты гейм-дизайнер, то ты должен хотя бы немного разбираться в скриптах и остальном, и теперь ты должен идти и брать готовую кожуру от продукта. Условно говоря, можно посмотреть на тот же редактор WarCraft

Кто такой хороший менеджер, как им стать?


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

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

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

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

Иногда бывает позиция, в которой надо хорошо себя показывать перед инвесторами. Ты у них на ковре сидишь и должен каждые 2 недели отчитываться за каждый чих на проекте. Это совсем не то, что работа с командой или аудиторией. Это очень высокий уровень, и к каждому отчету надо готовиться так, как ни к чему больше. Мусора не должно быть ни в голове, ни в бумагах.

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

Нужно быть всегда готовым к неприятным вопросам: почему выпуск продукта задержан, почему выручки мало? Вы же могли сделать продукт быстрее?

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

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

Как набрать крутую команду?


Во-первых, ты должен понимать, каких людей тебе надо. Для этого нужно понимать, какой продукт вы делаете.

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

Как правило, команда у тебя уже есть, и ты в ней живешь и работаешь. Ты должен понимать, кто в неё входит: допустим, есть 8 программистов 4 клиентских и 4 серверных, 2 аниматора, 2 иллюстратора, 2 дизайнера, 2 геймдиза (один проджект), плюс 1 тестировщик и левел-дизайнер.

И надо понимать, какую игру можно делать такими силами. Допустим, игру уровня WoW такой командой не сделать слишком мало гейм-дизайнеров, но зато есть сильная программистская составляющая (8 программистов это круто) и достаточно средний арт (6 человек). Поэтому можно делать игру со сложной логикой, с хорошей графикой, но с не слишком большим количеством игровых механик.

В случае, если программистов 2, художников 6 и 4 геймдиза, можно делать что-то казуальное с донатами для мобилок: пусть все будет красиво, ярко, вылетают каждую секунду призы и поздравления. Графики много, гейм-дизайнерской составляющей много, логики мало. И вот так, учитывая нужды, надо набирать команду.

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

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

Но при этом необязательно самому быть великим программистом, чтобы завлечь крутого программиста: нужно просто быть крутым человеком, знающим продукт от и до. Допустим, есть программист, который начинает: я твой код делал, я игровой программист! Ты говоришь: Хорошо, ты способен сделать весь продукт? Ты можешь в него надо добавить гейм-дизайнерские составляющие, монетизацию, маркетинг прикрутить? Нет. Но я это могу. Давай работать в команде. Ты делаешь свою часть работы хорошо, я свою часть. Тогда проект выстрелит, и каждому из нас капнет достаточно денег, чтобы мы не чувствовали себя обманутыми. Человек понимает, что он действительно хороший программист, но при этом не шарит в маркетинге и дизайне, поэтому он скажет: да, давайте работать.

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

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

Два самых главных качества менеджера?


Вы сейчас сильно удивитесь. Когда вы на собеседования приходите, вам задают два вопроса и предъявляют два требования, которые вас, наверно, уже достали. Когда слышишь про коммуникабельность и стрессоустойчивость в 60-й раз, перестаешь относиться к ним серьезно. Но ведь это и есть два главных качества для менеджера.

Стрессоустойчивость. Она определяет то, насколько высоко вы подниметесь, не только в работе, а вообще в жизни. Вот вы поднялись до команды из 5 человек и на вас обрушился новый уровень стресса, которого раньше не было. И, может быть, вы и остались на этом уровне или откатились на команду поменьше (и зарплату поменьше), потому что вы не в состоянии перерабатывать стресс, вам слишком некомфортно.

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

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

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

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

И всегда нужно брать ношу по себе. Я часто коммуницирую с людьми, которые сидят на позициях топ-менеджеров, и большинство из них сидит еще и на антидепрессантах. Они когда-то взяли груз, который не могут вынести. Ведь как работает продвижение по карьерной лестнице: у тебя есть команда, допустим, из 20 человек, и вы даете какой-то результат. У вас есть 7 проектов, вы их ведете, все хорошо, компания получает деньги. И тебе говорят: возьми теперь не 7, а 10 проектов, и в команду добавляют 40 людей. Но для того, чтобы вести 20 людей и 7 проектов, ты уже тратил в день не 8, а 12 часов, только не говорил никому. Ты много работал, тебе работа даже нравилась. А теперь придется работать еще больше. На первых порах ты радуешься: вау, я получил повышение, я крут. А потом ты осознаешь, что у тебя 16 рабочих часов на дню. Ты где-то берешь эти дополнительные часы, и тебя это начинает пожирать. Уровень стресса взлетает. Люди, которые наверху, вынуждены работать каждую секунду. Они головой всегда на работе, и, если появляется свободная минута, они тут же пытаются вернуться на нее же. Их уровень стрессоустойчивости обязан быть высоким.

Второй момент коммуникабельность. Это то, насколько вы хороши в общении с командой, с сопутствующими отделами, с инвесторами, с пользователями, и в представлении своей компании. Если вы коммуникабельны, энергоемки, позитивны и радостны, самый главный бонус это создание связей вокруг себя. Тогда, если приходят проблемы, вы идете к людям, которых к себе расположили, и спрашиваете совета.

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

У меня был пример, когда мне давали команду из программистов-джунов, их было 5, плюс 1 миддл. Периодически мы сталкивались с проблемами, на которые джуны тратили дня по 4 именно от нехватки опыта. В этом случае спасало то, что у меня остались связи с мощными игровыми программистами из моей предыдущей компании. Я просто иногда спрашивал у них, как они решают у себя ту или иную проблему. За 5 или 10 минут давался такой ответ, после которого джуны говорили вот, это то, чего не хватало, через 2 часа все сделаем. И делали. То же с художниками; если у вас накоплен пул из удаленных художников, можно в любое время, когда собственный художник заболел, перегружен и т.д., обратиться к ним и получить качественный материал за денежку.

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

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

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

Поначалу гендир, может, и не поверит, что без упыря ничего не развалится. Но ты настоишь на своем, делаешь рокировочку упырь пусть в Ашане тележки катает, а к тебе приходит твой человек, с которым ты уже долго работал, он классный, тут же подхватывает работу. И говорит: тут на самом деле работы не так много, я делал и получше. Кадровые перестановки качественных людей здорово экономят деньги компании и помогают команде; сейчас удаленные HR-команды берут за приведенного человека одну-две его зарплаты, но ты таким образом оставляешь эти деньги внутри компании, получаешь нормального человека в команду, и заодно статус человека, который умеет экономить.

Что делать, если проработал в индустрии 8 лет, но нет особых достижений? Какие выводы по себе делать, как анализировать свою работу? Стоит ли продолжать? Нужны ли такие люди компаниям?


Ну, допустим, я сам ненамного выше стою, чем этот уровень. Я как раз простая крепкая серединка как менеджер, монетизатор и геймдиз, имею какой-то опыт, делюсь им с удовольствием.

Я работал на прибыльных проектах, но я их не создавал: просто работал в составе команды, которая работала на результат. 2 раза я повышал продукт на 50% (то есть, один и тот же продукт заставил приносить на 50% больше через месяц, и еще раз его же через полгода). Каких-то суперуспехов у меня нет. Я был генеральным продюсером, но только небольших проектов. Я был руководителем игрового направления (одного из трех, там было 9 проектов, за которыми надо было следить, чтобы они приносили денежку).

Очень часто люди делают вывод, что, если они ничего великого не добились, то им нужно куда-то уйти в другое место. Это неправильно. В компании, допустим, из 150 человек, для успешной работы требуется человек 90 как раз крепких середняков не гениев-супергероев-мега-работяг.

Такие люди и делают основную, фундаментальную работу. Если вы такой человек, значит, на вас держится кусок компании. Если в компании будет 150 авантюристов, которые каждый день будут выдавать какие-то новые идеи, хотеть зарабатывать не меньше 5 миллионов долларов за игру в месяц, требовать, чтобы все продукты были мирового уровня и так далее компания развалится. За спиной каждого инициативного человека должны стоять те, кто действительно умеет доделывать работу до конца, и делать ее качественно. Если вы такой человек, то это хорошо. В этом нет ничего зазорного, и вы нужны компании.

По статистике, примерно 85% молодых с горящими глазами успокаивается и становятся такими же крепкими серединками. А еще, тоже по статистике, один человек в своей жизни может создать только один гениальный продукт. Все гении, единожды создавшие что-то крутое, не могут повторить свой успех. Вы можете сами это проверить при более глубоком рассмотрении. Да, есть компании, чей учредитель когда-то создал продукт 1, а через 8 лет появился продукт 2, который стал не хуже; но, если присмотреться, то получится, что второй продукт по большей части создавали другие люди. Может быть, он их обучил, или они уже пришли в компанию крутыми, но создавали именно они.

Если вас радует ваша работа, если вы вращаетесь в хорошем коллективе, то не надо никуда уходить. Быть просто одной из крепких опор компании не зазорно. Лично я очень благодарен таким людям, которые у меня есть я знаю, что на них можно положиться, что они всегда всё сделают качественно. Если вы чувствуете, что это ваше, продолжайте работать. Не обязательно хватать звезды с неба. По статистике, немного проектов выходит на мировой уровень, но компании и люди нормально живут. По той же статистике в футбол играют не только в Высшей лиге; во всех лигах люди пинают мячи и замечательно чувствуют себя, потому что любят то, чем занимаются.

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

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


Я расскажу историю. В геймдев я пришел в 2008 году, до 2009 работал удаленно; я приехал в Москву и в августе был принят на работу в Аструм Онлайн, а до этого не был в штате.

До 2016 года современного понятия офисной этики, и других вещей, не было. Был просто набор энергичных людей, которые любили игры и хотели сами сделать себе крутую игру, чтоб другие игроки им деньги приносили. Это логика всех игроков, которые до этого вкладывались в другие проекты.

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

Никто не видел во всем этом проблемы. Большинство компаний, с которыми я коммуницировал, считали, что все это не плохо и не хорошо просто есть.

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

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

Да, действительно, токсичные люди есть. Но большинство людей на этой модной волне начали, не разбираясь, записывать в токсичных всех. Если человек не высыпается из-за того, что у него дома ребенок маленький, и приходит на работу мрачным, и вякает раз на кого-то всё. Он токсичный, с ним не надо дружить. У другого человека кошка умерла он тоже в подавленном настроении приходит, а к нему лезут: жизнь веселая, не грусти! Он в ответ делает посыл, и результат тот же.

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

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

Я часто привожу еще и такой пример. Представьте себе большой красивый лайнер. На борту играет музыка, люди в белых фраках, всё красиво, танцуется мега-вальс. Все хорошо, шампанское, атмосфера полной гармонии. Вдруг в палубе открывается люк, и оттуда со словами КАКОГО ХРЕНА вылезает грязный, одуревший от духоты механик. Из люка валит дым, механик матерится на всех. Он восемь часов что-то чинил на этом корабле по уши в мазуте, чтобы весь корабль не утонул, и не понимает этих людей. И они все такие: Ой, какой же ты токсичный, ты не понимаешь, что весь мир состоит не только из негатива? Смотри на позитивную сторону!
А теперь представьте, что на корабле будут только красивые люди во фраках с блестками, а механика не будет. Либо корабль пойдет ко дну, либо половине красивых людей придется спуститься под палубу и работать вместо механика.

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

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

Если бы он начал говорить: Послушай, пожалуйста, Сережа, сейчас я не могу, давай соберемся потом ты бы уже выиграл. Ты бы сказал: Миша, ты же понимаешь, как это важно, давай сделаем сейчас, у нас все горит. А он снова Сережа, я не могу, мне своих задач навесили. Но вот один раз рявкнул другой убежал, человек снова занимается своими задачами. Удобно.

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

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

Зачастую они являются самыми хорошими сотрудниками. Они со словами ДА ВАШУ МАТЬ чинят то, что понаделали позитивные люди в белых рубашечках, которые в случае косяка хлопают глазками и говорят: Ой, мы же одна команда, давай, ты нам поможешь?

Какие книги и лекции надо почитать перед тем, как делать свою игру?


Когда мне задают этот вопрос, я всегда говорю так: если ты задаешь этот вопрос, то ты не готов делать свою игру.

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

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

На моем старте карьеры, примерно через 3 года после того, как я начал заниматься геймдевом у нас была студия из нескольких команд. Менеджеры сидели в одном кабинете, и туда, как правило, приходил генеральный продюсер, и говорил: Ребятушки, а кто в этом месяце делает план по баблу? Одни говорят: Мы делаем. Другие говорят: О, а мы еще больше делаем. А третьи: Ой, а у нас все плохо. Генеральный и говорит третьим: Вы-то, родные, и поедете на конференцию, людей учить будете! А остальные работайте, к вам нет претензий.

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

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

Самое главное: во-первых, пока ты готовишь из программиста медийного представителя, он теряет в скилле; во-вторых, он на этой конференции тут же получит штуки 4 предложений о работе с удвоением зарплаты, потому что хорошо подал себя и рассказал историю успеха, которую другие желают повторить. Еще он тут же создаст канал на YT, где повторит прочитанные лекции и у него уже канал будет зарабатывать. Дальше он будет не код писать, а учиться делать новые конференции. И на побуждение вернуться к работе он ответит: слушай, у меня тут канал уже приносит почти мою зарплату, да и предложения вот лежат Давай, я просто уволюсь? Все, ты потерял этого человека. Компании, которые по первости отправляют на конференции лучших людей и обжигаются понимают эту схему, и в следующий раз присылают людей похуже, хотя и более представительных.

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

Как считать баланс игр? Баланс и псевдобаланс, 2 типа псевдобаланса (pve, pvp), почему надо считать сложный баланс, как надо это делать?


Идея в том, что есть баланс, который считается людьми с математическим образованием, и есть псевдобаланс, который считается на коленке. Псевдобаланс не хорош для игрока; игрок будет чувствовать неинтересность игры. Допустим, в игре есть белые, зеленые, синие и фиолетовые вещи; с точки зрения правильного баланса ты будешь долго считать характеристики, но с точки зрения поверхностного присваиваешь белым 100 единиц статов, зеленым 1000, синим 10000, фиолетовым 50000. По-быстрому сделав это, ты знаешь, что игрок с фиолетовым обвесом не победим никаким другим игроком. Это считается быстро, делается быстро, и играть в это неинтересно. Еще есть вариант: большая локация в pve-играх; ты знаешь, что игрока надо заставить пройти последнего босса. И нужно, чтобы игрок перед этим не выскакивал на другие локации. Поэтому ты делаешь так, чтобы на другие локации можно было пройти только в том случае, если у игрока есть меч, потому что на этот меч будет повешен эффект уменьшения защиты орков полностью, а на второй локации будут стоять орки с непробиваемой (другим оружием) защитой без меча игрок просто не пройдет. И, собственно, доставать это меч ему нужно будет из последнего босса первой локации. Вот это псевдобаланс, он плохой. Я ответил коротко, более развернуто не думаю, что будет интересно.

Математика стоимости товаров в играх. Как рассчитать стоимость каждой плюшки и сделать так, чтобы покупали?


Куча факторов. Например, регион, в котором ты работаешь; условно говоря, для Филиппин и Франции один и тот же пак должен иметь очень разные цены. Филиппинцы всей семьей выживают на 10 долларов месяц.

В целом, для стоимости каждой плюшки можно применять универсальную математику: когда игрок фармит, один час времени фарма это доллар. То есть, то, что можно нафармить за час времени, можно продавать за доллар. Взрослый человек не будет тратить час своей жизни, чтобы не тратить доллар, но школьник будет фармить с утра до вечера и они будут примерно уравниваться после того, как взрослый заплатит $10. Это довольно универсальная схема. Есть еще немного других, их мы сейчас не будем затрагивать.

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


Я немного повторюсь, потому что по этой теме уже разворачивался.

Да, может. Я сам тоже являюсь таким специалистом. У меня не всегда есть такая работа, которую я работаю, сидя в офисе, но моя квалификация в некоторых вещах подтверждена, и, когда люди хотят получить результат в тех вещах, в которых не могут его получить самостоятельно (геймдиз, монетизация, оптимизация команды: собрать новую, проредить старую, спланировать бюджет, перепроверить архитектуру проекта), они приходят ко мне.

Периодически, рано или поздно, у каждого из людей возникает вилка дальнейшего развития.

Допустим, ты хороший художник, поднимаешься до артлида, у тебя 5 своих художников, ты ставишь задачи. Ты растешь дальше, у тебя становится больше денег и полномочий, ты уже арт-директор, у тебя 30 человек, больше задач, но меньше художества. Твоя деятельность из творческой стала управленческой, но ты не хотел управлять. Ты теперь должен создавать комфортные условия для других людей, чтобы они хорошо рисовали, но ты хотел сам рисовать. Тебе это не нравится. После этого ты принимаешь решение, покидаешь компанию и становишься высокооплачиваемым удаленным сотрудником.

То есть, тут два пути рост управленца либо удаленный специалист. Удаленных специалистов очень много, это могут быть программисты, те, кто настраивают тебе безопасность, и художники, и гейм-дизайнеры. Их прелесть в том, что большая компания может позволить себе такого человека, который запросит полторы-две зарплаты за разовую работу. Компания не держит такого человека в штате, если у нее бывают для него задачи только 2 раза в год (допустим, настройка безопасности серверов или пересмотр баланса). То есть, вместо того, чтобы вхолостую кормить его большую часть года, она два раза в год обращается к нему с заданиями, за которые хорошо платит.

Я довольно высокооплачиваемый сотрудник, и, если у компании перебои с деньгами, то мне самому некомфортно находиться там, если я чувствую, что она меня не вывозит. В то же время, если мне предлагают разовую работу, я на нее соглашаюсь, и все получается.
Для того, чтобы стать таким специалистом, нужно наработать себе пул компаний, которые хотят с вами работать. То есть, вы периодически что-то делаете, у вас все хорошо получается, и к вам обращаются люди, потому что знают, что вы даете результат.



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.

Подробнее..

Руководитель о двух головах

26.06.2020 16:08:22 | Автор: admin
В IT характерно идти путем оптимизации и получать максимум от имеющихся ресурсов. Владельцы бизнеса тщательно подбирают топ-менеджеров, а HR-специалисты стараются не раздувать штат. Поэтому, например, в отрасли распространены многоэтапные собеседования, с целью взять лучшего кандидата по сочетанию положительных и отрицательных качеств, подходящего для выполнения конкретных задач, с учетом особенностей конкретной команды. При этом в каждой IT-компании есть своя история развития и примеры управленческих решений, которые также помогли оптимизировать работу талантливых ребят и внедренные ими процессы.

В статье мы рассказываем о системе, реализованной в Plarium Krasnodar: она предполагает разделение полномочий, ответственности и зон влияния между руководителем и координатором. Материал может быть полезен менеджерам разного уровня, а также специалистам по управлению, которые интересуются темой или планируют реорганизацию.

image

Привет, Habr. Меня зовут Дарья Меньшикова, я Head of Customer Experience & Support Division студии Plarium Krasnodar.

7 лет назад я начала работу с небольшой командой из 5 человек. Сейчас структура состоит из 83 сотрудников в офисе и около 100 удаленных специалистов, которые формируют 14 команд и выполняют функции для покрытия разных потребностей бизнеса в зоне post-production.

Хочу поделиться опытом создания системы управления на примере моего подразделения. Эффективность системы была проверена временем и получила положительную оценку от топ-менеджмента студии.

Вот как это работает

Управление предполагает наличие у руководителя одновременно навыков стратегического и тактического планирования. Но если мы обратимся к классике менеджмента, например к Ицхаку Адизесу и его книге Идеальный руководитель. Почему им нельзя стать, то увидим, что невозможно быть талантливым во всем.

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

Стратегия и тактика это функции, предполагающие противоположные взгляды на цели и результат.

Когда я поняла, что эти функции не могут быть равновелики в одном человеке, стало очевидно, что их нужно разделить между двумя разными специалистами. Любой руководитель департамента или команды в дивизионе должен брать на себя стратегическую функцию, то есть выбирать, куда и зачем идет его команда. Также он должен передавать это видение своему помощнику координатору (не путать с помощником руководителя в классическом понимании), который будет искать, каким образом команда туда придет, отвечая на вопросы: с помощью чего, используя какие ресурсы?

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

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

Зачем это нужно? Мы помним, что у них зачастую противоположные взгляды на одну и ту же проблему, процесс, идею. Лид оценивает, как это будет выглядеть через полгода, год, два года, как может развиваться. Координатор же смотрит, какой это дает профит прямо сейчас, как ломает существующий уклад, какие шаги необходимы для реализации и много ли требуется на это ресурсов.

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

При синергии стратега и тактика качество принятия управленческого решения намного выше, чем если бы это решение принимал только стратег или только тактик.

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

Кто же он координатор?

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

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

Не PM. Project Manager в большей степени выполняет функции администратора: фасилитирует процессы, распределяет и собирает задачи, контролирует их реализацию и сроки выполнения, иногда налаживает коммуникацию между отделами или специалистами. Классическая зона принятия решения у PM ограничена по сравнению с координатором: последний помимо перечисленного несет полную ответственность за тактическое развитие команды.

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

Координатор это руки, лид это голова.

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

Простая аллегория: если в пути сломался велосипед, это ошибка в зоне ответственности координатора, а если велосипед доехал, но мы приехали не туда это ошибка в зоне ответственности лида.

Если ругают, то обоих, если хвалят, то тоже обоих. Если команда добилась успеха эти двое круто отработали и вместе с командой достигли больших результатов.

Что же входит в должностные обязанности координатора? Зависит от его грейда. Посмотрим на должностную сетку.

image

Чем выше в иерархии должность координатора, тем большими полномочиями он наделен. Здесь есть один важный нюанс, касающийся стратегии и тактики. Поскольку Executive Director работает на уровне всего дивизиона, его зона ответственности шире, чем у Executive Lead, который работает на уровне департамента. Так как масштаб стратегии дивизиона больше стратегии входящих в него департаментов, тактика дивизиона очень часто перекликается со стратегией департаментов (соотношение дивизиона, департаментов и команд см. в схеме ниже).

image

Рассмотрим обязанности координатора на высшей в карьерной сетке должности Executive Director. Его функции можно разбить на 5 больших групп.

  1. Стратегия и тактика управления. Планирование работ с руководителями департаментов для достижения целей дивизиона. Изучение трендов и новых подходов в управлении сотрудниками, командообразовании и эффективном ведении бизнеса.
  2. Организация. Координирование при выполнении общих задач департаментов внутри дивизиона.
  3. Развитие команд. Участие в адаптации новых сотрудников и развитие молодых руководителей в дивизионе. Работа с сеньорами, лидами команд. Участие во всех этапах подбора сотрудников и присутствие на собеседованиях. Создание рабочей атмосферы в командах дивизиона и ее мониторинг. Руководство вспомогательными командами дивизиона.
  4. Взаимодействие. Ситуативная работа с топ-менеджментом краснодарской студии. Налаживание коммуникаций с другими студиями Plarium. Регулярное общение и консультации с юристами, в том числе по вопросам пользователей.
  5. Контроль. Участие в подготовке отчетности для вышестоящих руководителей. Определение и контроль сроков по стратегическим задачам дивизиона.

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

Какой минимальный набор качеств должен быть у координатора? Как разглядеть эти качества в сотрудниках или кандидатах?

  • Умение видеть суть вещей, обладание внутренним ощущением того, как правильно выстраивать процесс, исходя из формулировки задачи и требований руководителя, внимательность и пунктуальность.
  • Поскольку на этой должности процессы касаются разных людей, команд или даже департаментов, необходим хорошо развитый навык коммуникации. Компания большая, в ней работают специалисты с разным характером, строем психики и жизненным опытом. Чтобы эффективно выстраивать процессы, координатору нужно уметь находить общий язык со всеми. Тут может помочь знание типологий личности например, типов информационного метаболизма человека (соционика), типов личности по В.Пономаренко (профайлинг) и др.
  • При этом каждый координатор должен иметь эмоциональный стержень, быть психологически зрелым. Несмотря на то, что он работает с процессами, ему необходимо обладать определенным уровнем эмпатии и владеть этическими нормами. Большинство процессов в зоне ответственности координатора завязано на людях, поэтому отношение к ним должно быть базово хорошим. При наличии эмоциональной зрелости и хорошего отношения формируется частичная психическая абстрагированность от внешней фрустрации, то есть стрессоустойчивость. Это и позволяет при коммуникации чаще оставаться эмоционально нейтральным и достигать нужных целей для бизнеса.
  • А чтобы понимать, с кем и когда следует коммуницировать, необходимо хорошо понимать приоритеты. Видеть, в какой последовательности лучше выполнять задачи. Для правильной приоритизации нужно обладать наиболее важной информацией по каждой выполняемой задаче, чтобы внезапное появление новых данных не привело к переносу срока или потере в качестве. Это возвращает нас к первому пункту списка умение выделять суть.

Это для вас? Действуйте!

Система лид координатор предполагает диалог. Если вы любитель монологов, координатор вам не требуется.

Чтобы разделить свою власть с кем-то, нужно не бояться этой властью делиться и обладать достаточной уверенностью в себе. Нужно быть готовым к тому, что координатор по многим вопросам может быть с вами не согласен, а такой формат взаимодействия по душе не всем руководителям.

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

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

Перевод Вс, что вам нужно знать об управлении релизами

14.12.2020 18:12:07 | Автор: admin
В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании Hike, рассказывает о трейн-релизах и о стратегии ветвления, вводя в курс дела тех, кто хочет расширить свою зону компетенции и получить представление об управлении проектом.




Что это такое управление релизом?


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

  1. Планирование релиза
  2. Сборка релиза
  3. Приемочное пользовательское тестирование
  4. Подготовка релиза
  5. Развертывание релиза.


Планирование релиза


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

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

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

  1. Отсечение: начинается 1-й день.
  2. Внутреннее тестирование версий альфа/UAT: Три дня.
  3. Поэтапное развертывание [1%] Представление на ревью.
  4. Продолжительность ревью: 3 дня.
  5. Один день при 20% пользователей.
  6. Один день при 50% пользователей, в тот же день рост до 100% пользователей.

В соответствии с приведенным выше примеромв общей сложности потребуется 10 дней, пока новая версия приложения не будет общедоступна.



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

Рабочий процесс сразу объясняет, как устроен весь релиз и какую роль играет каждый член команды. Мы используем инструмент Асана для отображения этих деталей, перечисленных ниже:

  • Сроки
  • Сроки поставки
  • Требования
  • Общий масштаб проекта

После разработки плана мы представляем его на рассмотрение всех заинтересованных сторон (релиз-группы, продакт-менеджера и руководителей высокого уровня). Затем получаем их отзывы о любых пробелах или проблемах, которые они видят в требованиях или в сфере применения.



Как только план утверждается и окончательно оформляется, начинается самое интересное!

Важные аспекты планирования релизов


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

  • Релиз-менеджер управляет релизом и координирует его.
  • Мы принимаем только код с проведенным ревью и протестированный код.
  • В процессе есть этап внедрения.
  • Мы мониторим выпущенную версию приложения.

Построение релиза


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

В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.

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



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



Релиз веток и контроль версий


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



Именно здесь на помощь приходит хитрая стратегия ветвления, в которой есть концепция разветвления. Как следует из названия, ветвление кода означает, что точно так же, как у веток дерева, код веток до определенной точки совпадает, а затем разбивается на две копии.

Каждая ветвь может развиваться независимо от другой. В этом случае одна копия ветка релиза остаётся замороженной на том месте, где вы завершили разработку. Это то, что мы называем отсечённой веткой. Другая ветка (ветка разработки) может быть изменена новым кодом и исправлениями ошибок, не затрагивая ветку релиза вообще. Если ошибка найдена в релиз-кандидате, исправление может быть разработано и добавлено в ветку релиза. Таким образом, следующая сборка, которую вы снова соберёте из ветки выпуска, может быть идентична первой, за исключением исправления одной ошибки. Таким образом, вы можете минимизировать риск появления новых ошибок в выпуске и изолировать баги от нового кода. Исправление также применяется к ветке разработки, чтобы гарантировать, что та же самая ошибка не попадёт в следующий релиз. Другое преимущество релиз-ветвления состоит в том, что как только вы действительно публикуете код, у вас есть замороженная ветка, которая представляет собой точную копию опубликованной кодовой базы. Вы можете вернуться к этому коду в любое время для справки.



Пользовательское приемочное тестирование


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



Как следует из названия, когда речь идёт об этом виде тестирования, ключевая фигура пользователь. Пользователи это именно те люди, которые будут пользоваться приложением. Поэтому крайне важно сделать пользователей частью всей стратегии обеспечения качества в процессе разработки программного обеспечения. Вот где пригодится UAT. Этот тип тестирования, как никакой другой, ставит потребности пользователей в центр работы над продуктом. Вот некоторые из вопросов, на которые такое тестирование пытается ответить:

  • Могут ли пользователи работать с приложением?
  • Соответствует ли поведение приложения ожиданиям?
  • Решает ли приложение проблему пользователей?

Без эффективного UAT (User Acceptance Testing) шансы на успех разрабатываемого проекта значительно снижаются. Именно поэтому пользовательское является такой важной частью процесса поставки. Как отмечалось ранее, UAT часть итеративного процесса. По мере выявления ошибок команда возвращается, чтобы исправить их. Ошибка исправляется в ветке релиза, а затем мержится обратно в ветку разработки. Сборка должна пройти стадию UAT, чтобы её можно было изучить на предмет окончательного внедрения и выпуска.

Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!

Одним из способов ускорить UAT релиза для нас было использование внутренних тестовых треков, предоставляемых Google. Это помогает нам быстрее распространять тикеты среди коллег и фиксировать их отзывы посредством автоматического создания тикетов JIRA. Перед отправкой финального теста команда также следит за тем, чтобы отзывы были учтены.

Подготовка и релиз


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

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



Развертывание релиза


Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения What's New (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:

  • Создание окончательной сборки [с указанием ветки и названия версии].
  • Добавление Whats New в релизе.
  • Добавление процента развертывания.
  • У каждого этапа есть ручной ввод сигналов (красный/зеленый) от каждой из команд [UAT, бенчмарк, производительность, автоматизация].

Как только сигналы разрешают сборку, сборка автоматически загружается в Play Store с определенным процентом развертывания. Внутренние шаги коммита и прописывания тега версии, сохранение сборок в Dropbox, публикация и обновление в соответствующем канале Slack также выполняются через тот же конвейер.



В данном случае мы начинаем с развертывания для 1%. На каждом этапе необходимо следить за ревью, а также за инструментами мониторинга падений релиза, чтобы выявить возможные проблемы.

Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.

Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают нормальную разработку.

Анализ после релиза


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

Кроме того, ревью приложения дают представление о вашем продукте, которое гораздо труднее получить при других подходах. И Google Play, и App Store предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.

Подведем итоги


Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз это возможность уточнить всё от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:

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


image

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


Подробнее..

10 полезных книг для менеджера и лидера в IT секторе

26.12.2020 20:23:24 | Автор: admin


Я работаю много лет в индустрии разработки программного обеспечения и последние несколько лет я активно вовлечен в консалтинг и pre-sales фазы. И я заметил, чтобы быть успешным лидером как для менеджера проектов, представляющего бизнес-сторону, так и для архитектора технического представителя необходимо совмещать в себе технические и лидерские качества.
Для меня наиболее полезным и эффективным источником обучения являются книги. И я бы хотел поделиться с вами топ 10, по моему мнению, книг полезных для начинающих и не только лидеров в разработке программного обеспечения. Эти книги помогут развить и улучшить лидерские качества необходимые в данной индустрии. Я не буду перечислять знаменитые менеджерские бестселлеры такие как Laws of Leadership или Good to Great. Я порекомендую более целевые книги, которые будут, несомненно, полезны именно лидерам в индустрии разработки программного обеспечения.
Название всех книг будут указаны на языке оригинала, но вы без труда сможете найти многие из них и в переводе.

Mythical Man-Month, The: Essays on Software Engineering




Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition

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

Death March




Death March (2nd Edition)

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

Consulting Outbreak: Manager and Software Architect Could be Friends




Consulting Outbreak: Manager and Software Architect Could be Friends

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

The Deadline: A Novel About Project Management




The Deadline: A Novel About Project Management

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

Waltzing With Bears: Managing Risk on Software Projects




Waltzing With Bears: Managing Risk on Software Projects

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

Herding Cats: A Primer for Programmers Who Lead Programmers




Herding Cats: A Primer for Programmers Who Lead Programmers

Эта книга будет полезна разработчикам, которые хотят развить лидерские качества. Если вы уже начали этот путь, то сможете улучшить и расширить свои знания. Автор очень последователен и точен. Он помнит, что вы еще разработчик и общается с вами как с разработчиком, в то же время улучшая ваши менеджерские и лидерские качества. Структура этой книги очень точная. В начале объясняется как примерять на себя роль лидера, а только потом рассказывается о правильном общении с командой и менеджерами высшего звена.

The Art of Project Management




The Art of Project Management (Theory in Practice (OReilly))

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

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity




The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (2nd Edition)

Разработчики стремятся создать лучшее инженерное решение, постоянно улучшая функционал и производительность приложения, но забывают о главных бизнес-целях проекта и удобстве использования, которое прежде всего важно для пользователя. Вследствие чего в проекте появляется множество бесполезного функционала для обычного пользователя. Автор считает, что на первом месте должно быть удобство использования и только потом сама разработка.

Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers




Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers

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

Inspired: How To Create Products Customers Love




Inspired: How To Create Products Customers Love

Если вкратце эта книга о менеджерах проекта, которые ищут компромисс между удовлетворенностью пользователей и эффективность в бизнесе. Какие основные навыки должны быть присущи менеджеру проектов, дизайнеру, и маркетологу. Автор рассказывает, как найти главный функционал продукта наиболее важный для пользователя и не тратить время на остальные детали не нужные пользователю. Это пособие о том, как создать минимальный продукт полезный для пользователя и прежде всего тот продукт, который пользователь полюбит по настоящему.
Подробнее..

Мы компания в айти нам всё равно, куда идти

17.02.2021 22:18:17 | Автор: admin

Забудь дедукцию, давай продукцию, эту формулу я усвоил сразу после окончания института. Тогда я ещё был финансистом и мир науки и образования меня буквально выкинул в мир бизнеса. Я ждал матриц, проектных структур, менеджмента строго по Мескону и Хедоури, а получил твою мать, какого х** бюджет не сводится, давай, подрисуй цифирь и отправим это уже главнюкам. Вооот, а это была компания на 120 человек с чистой прибылью в пару сотен миллионов. Это было начало 2008 года, который компания пережила, сократив 23 человека. А вот декабрь 2014-го стал последним месяцем существования всего холдинга. Я, уже большой чувак, понимал, что это всё результат череды управленческих ошибок. К тому времени я работал сисадмином в ИТ-компании и был уверен, что здесь всё будет круто. Сменив три ИТ-компании, я понял, что айтишники при всей инженерной стройности управляют и развиваются без вектора. И знаете, сейчас меня это тревожит.

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

Так что меня тревожит?

Когда у компании нет вектора, она выглядит беззащитной. 2020 год вдарил по многим компаниям с ноги, ИТ-компании пощадил и всего лишь ударил кулаком в грудь. Но это мог быть нокаут.

О каком векторе идёт речь?

В теории менеджмента это называется стратегией. Эта штука есть у крупных компаний, корпораций, зарубежных гигантов. И она же начисто игнорируется большинством остальных. И правда зачем тратить силы, время, деньги на работу над этим вектором, когда можно развиваться и так? Увы, так не получится. Вот что выпадает из поля зрения нашей ИТ-среды.

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

Мы человекоориентированные. Фиг там! Провозглашённая HR-ами человечность разбивается о первый же кризис: если компании нужна оптимизация штата и нужны сокращения, те же улыбчивые девушки из отдела работы с персоналом будут выдавать вам трудовые книжки и прогибать вас под уход по собственному, ведь на любого человека статья ТК РФ найдётся, ты в октябре три раза опоздал.

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

Мы лояльные. Наш офис настоящий социальный объект: правильное питание и фрукты, тренажёры, уголки шахмат и музыки по интересам, живые стены и даже капсульные спальные места. Нет, ребята, спасибо: я лучше залью чайный пакетик кипятком в офисе небольшой компании, где не будут пытаться выстроить конвейер по выкачиванию моего личного времени и удержания на мотивации нигде так не будет. Индексируйте заработную плату, вводите справедливую систему KPI, управляйте моим развитием и тогда я сам чуть дольше задержусь в офисе, куплю мясо и фрукты, отдохну и схожу на танго. К сожалению, лояльность заканчивается при первом же кризисе и вы очень быстро находите поводы избавиться от хорошего, но неудобного сотрудника: токсичный, опоздал, проболел спринт

Мы развиваемся и развиваем сотрудников. Куда вы развиваетесь? А сотрудников как развиваете? Думаете, три билета на конференции и подписка на книги с Amazon (Питер, OZON) это развитие сотрудника? Нет. Развитие сотрудника это чёткое понимание каждого работника, кем он будет в конце года, через два года, через пять. Любой человек склонен планировать и не очень разделяет ванильные статусы про живи одним днём, потому что если пережить один день, потом ещё один и ещё пару недель, приходят платежи за коммуналку, школу, вуз, стоматолога и т.д. И вот тогда хочется очень чётко понимать: моя компания надёжная, она планирует развиваться на рынке AR/VR, есть MVP продуктов и стратегические исследования, я сейчас прямо займусь вопросами инфобеза и через 2 года впишусь в новый проект как DevSecOps. Вот это план развития. И знаю компании, где всё примерно так и работает. Да, они чуть более бюрократизированы и авторитарны, но безусловно надёжны (если сам себе не нагадишь).

И что в итоге получается? Я обмениваю свой мозг, свой опыт на все эти комфортные условия и деньги, но у меня пропадает ощущение собственного развития: я работаю в моменте, меня отжимают, высасывают и в конце концов выбрасывают. И так же происходит с тысячами опытных профессионалов, в то время как они могут расти вместе с компанией и делать её супер сильной и прибыльной. Но нет, мир придумал фигню про срок ротации в пять лет: отработал 5 лет, не вырос, меняй работу. Им выгодно нанять послушную и управляемую молодёжь, и снова начать их ротировать. А вы, дорогие управленцы компании, даёте себе отчёт в том, а компания-то за 5 лет изменилась, чтобы нам в ней вырасти? Или топчется на месте? А вдруг ползёт назад? Ведь прибыль не всегда признак прогресса. Что там по стратегии?

Учат в вузе, учат в вузе и внезапно используют

Моё первое образование очень классный экономический и управленческий вуз. Там просто чумово преподавали менеджмент организации, настолько круто, что я, круглый отличник, ловящий всё на лету, сдал этот предмет на 4, группа на 3 и 4, потому что всё было слишком по-взрослому. Конечно, после экзамена мы пили яблочный и забродивший виноградный сок на набережной, заедали сыром-косичкой и матерно кричали, на чём мы вертели эту преподшу-практика и её Мескона, Хедоури, Друкера, Хонду и канбан Тойоты. Там были матрицы компаний, стратегии по каждому пункту, анализ конкурентов и поиск себя на рынке. Мы рисовали то, что сейчас принято узнавать в магическом квадранте Гартнера, создавали выдуманные фирмы и разрабатывали стратегию. Такая теория. И я думал, что это мне никогда не пригодится.

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

  • Матрицы KPI мы все их немного ненавидели, но в целом это была справедливая система ежемесячной оценки труда каждого сотрудника, зависящая от выполнения задач. Были субъективные моменты, но их исключили после нескольких жалоб коллег и совместного обсуждения.

  • Стратегия на 1, 3 и 5 лет. Компания и каждый в ней примерно знали точку будущего развития. Поясню на своём примере: я работал в коммерческом отделе, увидел переход на собственные вычислительные мощности, переучился на долгосрочных корпоративных курсах по системному администрированию и разработке, переместился в отдел АСУ, а затем и в разработку. У каждого был шанс на маневры. Всё это оформлялось в виде тех самых матриц и SWOT-анализа, которые мы разбирали на курсе менеджмента в вузе.

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

  • Регламенты взаимодействия помогали нам точно знать, кто за что отвечает и в какие сроки был обязан отработать. У нас не было формализованных автоматических бизнес-процессов, но были алгоритмы, по которым мы успешно двигались и выполняли работу вовремя. В случае срыва сроков коллеги не топили друг друга, а решали задачу слабого звена сообща.

  • Отличный самописный корпоративный портал помогал быстро и качественно информировать всех, благодарить коллег, поддерживать нормативную базу и чат (это был самописный чат, один из первых корпоративных). Там же мы пересылали друг другу ТЗ, создавали рабочие группы и проч. Короче, мы изобрели Битрикс до Битрикса и даже круче, но не придали значения этой разработке.

  • Совещания и сборы были инструментом оперативной работы: ежедневные 5 минут, еженедельные 15 минут, ежемесячные 1 час, периодический общий сбор на ногах по исключительным поводам. Каждый от коммерческого директора до делопроизводителя знал, что происходит в компании и что планируется в ближайшее время. Соответственно, каждый мог определить свою функцию или спросить, что от него требуется.

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

  • Централизованное бюджетирование. Каждое подразделение могло спланировать свои доходы. Благодаря этому отношения с клиентами и партнёрами были более чем нестыдные. Полученный на расходы бюджет положить в карман было нельзя.

Итог

За 5 лет сокращены 3 человека с полными выплатами + 3 оклада сверху, исполнены все бюджеты, компания трижды была ключевым налогоплательщиком региона, успешно пройдены 2 аудита. После продажи и реструктуризации (по инициативе головной конторы) за сотрудников дрался весь узкий рынок. Другие региональные центры просто распустили.

Восприятие

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

Нафига козе баян?

В общем, сейчас я иногда общаюсь с компаниями (больше по контенту, чем по аутсорсу админства, конечно, времена такие) и вижу, что многие процессы устроены ужасно и у компаний нет стратегии не то что развития, но даже блога на Хабре, например. Жить одним днём для компаний категорически опасно, потому что этим она изводит сотрудников и ставит под удар все свои ресурсы в случае возможного форс-мажора.

Итак, что может дать внятная стратегия?

Устойчивость компании: краткосрочные выгоды уйдут в сферу рутины, большинство ресурсов будут направлены на достижение 1-2 глобальных целей. Главная задача сделать так, чтобы текущие мелкие задачи не замедляли развитие компании в будущем (например, компания на фоне экономического спада сокращает несколько сотрудников, но в скором будущем придётся набирать, обучать и адаптировать новых а это лишние траты и уход с основной оси развития).

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

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

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

Актуализация самосознания бизнеса обеспечивается за счёт того, что компания трезво смотрит на себя, осознаёт свои плюсы и минусы, видит себя внутри рынка. И здесь самое крутое не найти себя среди лидеров рынка, а точно оценить и понять своё место и ту точку, к которой стоит двигаться. Чем объективнее и честнее анализ, тем быстрее получится выстроить стратегию перехода в желаемую группу компаний на рынке.

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

В общем, скажу честно, я загрузился. Ближе к сорока осознаёшь, что у тебя должен быть путь, должен он быть и у компании. Но не тот бредовый путь, который проповедуют всякие там, не помню как их А путь как стратегия настоящая игра с картами, планами, аналитикой. И чем больше я понимаю, как функционируют ИТ-компании, тем интереснее мне кажется эта тема. Что-то мне подсказывает, ИТ способно что-то изобрести на этом пути.

Ну что, загрузил я вас или норм?

Подробнее..

Фактор демотивации 1 Отсутствие стратегии в головах сотрудников

28.05.2021 08:05:31 | Автор: admin
image

Введение



Дорогие читатели, в моей картине мира существует 48 демотиваторов, которые влияют на работу сотрудников компании. И, так как каждый человек уникален, одни демотиваторы могут оказывать на него сильное влияние, другие среднее, а некоторые могут быть практически незаметными. Поэтому, нумерация демотиваторов никак не отображает их мощность и влияние на сотрудника. Это просто нумерация.
Cейчас вы ознакомитесь с демотиватором под номером 1 в моем списке. Через какое-то время я выложу второй, потом третий,. Когда вы ознакомитесь со всеми, каждый сам для себя сможет определить правильную приоритетность и выбрать, какой будет на первом месте, какой на втором и так далее.

Итак, начинаем серию. Приятного чтения!

Covid-19 Карантин Кризис Компании закрываются Бюджеты сокращаются...


Все это видят сотрудники. Они видят сокращения. Они видят, как компании начинают усиленно наблюдать за бюджетом. Они видят, как с рынка уходят крупные компании.
Что сотрудники чувствуют, глядя на все это? Они чувствуют опасность и страх. Они начинают сомневаться в своей компании. Компания может быть большой, известной, статусной, но это было вчера, а сейчас и впереди нестабильность. Кто его знает, как завтра все повернется? Вот, Иван Сергеевич вчера тоже работал в большой компании. А сегодня ищет новую работу так рассуждает сотрудник.


Сотрудники видят, как люди остаются без заработка
Компании сокращают расходы. Одни отправляют людей за свой счет, другие увольняют. Специалисты, которые перестали быть актуальными в условиях удаленки (офис-менеджеры, администраторы, клининг-менеджеры, официанты, ...) отправляются домой. Компании начинают пересматривать свои бизнес-процессы и оптимизировать их. В ходе таких оптимизаций, наружу вылазят функции, которые:
давно не нужны и не несут никакой ценности;
можно автоматизировать.
Соответственно, людей, которые эти функции выполняли, увольняют.


Люди боятся
С одной стороны, летит информация: массовые сокращения достигли x%, а с другой стороны: компании приостановили поиск новых кандидатов на y%. Они ощущают страх, они находятся в состоянии стресса. Вот-вот, и их позовет руководитель и сообщит о прекращении сотрудничества.


К чему это приводит?


Люди теряют задор и снижается продуктивность. Во-первых, это естественная реакция организма на состояние страха, стресса и давления. Сотрудник, особенно интеллектуально труда, не может эффективно работать в таком состоянии. Он быстро устает, у него меньше энергии, он не может творить. Он не может собрать мысли и сконцентрироваться. Во-вторых, а зачем напрягаться, если компания завтра пойдет на дно, если меня завтра уволят, если компания мне не заплатит? Если сотрудник и до этого был не очень вовлечен и раньше пытался увильнуть от работы, то сейчас у него для этого есть прекрасный повод и аргумент. Чем он с удовольствием и воспользуется.
И это все происходит во время кризиса!!! В то время, когда нужно мобилизоваться и увеличить эффективность! Вы понимаете всю абсурдность и печальность ситуации? Когда компании нужно увеличить свою эффективность, чтобы выжить люди уменьшают эффективность своей работы. Это усугубляет ситуацию и приводит к логичным последствиям.


Кто виноват в этой ситуации?


Начнем с сотрудников. Разве они виноваты? На чем строят они свои выводы? На том, что говорят руководители и как они об этом говоря. Но, проблема в том, что не говорят. Тогда, приходится пользоваться всем остальным: слухи, новости, друзья, свои умозаключения (мол, глядя на трещину в стене, мне кажется, что нам трындец), . Более рациональные попробуют логически рассуждать в разрезе компании и ее результатов, и попытаются вспомнить:


  • какие у нас были раньше результаты?
  • что раньше говорило руководство о положении компании?
  • всегда ли вовремя платили зарплаты?
  • были ли раньше проблемы?

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


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


Если бы сотрудник владел всей необходимой для адекватной оценки информацией, он бы, либо перестал боятся, либо осознанно боялся. А осознанный страх это совершенно другое состояние. Оно заставляет выходить на вопрос: Как это изменить? Как этого избежать? Как на это повлиять?.


image

.


Что делают руководители?


Они никак не коммуницируют с сотрудниками. Почему? Выделяю три популярные причины:


1) Мы сами ничего не знаем.


Руководители, вместо того, чтобы включаться и работать над антикризисными мерами ждут. Ждут, когда все рассосется само, когда все стабилизируется, когда закончится карантин. Ждуны!


Самые популярные фразочки:


  • Нас это не затронет.
    Фраза опирается, либо на безумную самоуверенность, либо на специфику деятельности. Мол, если мы работаем в IT, значит нам кризис не страшен. У нас все процессы настроены и готовы для удаленной работы. Нам нечего боятся!.
    Да, вы можете работать с клиентами удаленно. Но, нужны ли вы вашим клиентам? Кризис же это не только проблема процессов, но и проблема уменьшения потребительской составляющей. Прекрасно, что вы готовы предоставлять свои услуги в удаленном формате. Но, ваши клиенты для этого должны иметь деньги. Если их убьет этот кризис он убьет и вас.
  • Мы уже 2 кризиса пережили и этот переживем.
    То, что компания пережила несколько кризисов (хоть десять) не делает ее бессмертной. Кризисы, как и болезни, разные. Каждый новый кризис это новая болезнь, с новыми условиями, с новыми симптомами, с новыми побочными эффектами. Мы не знаем, какая комбинация этих условий сейчас будет работать против компании. И, как раз, возможно, именно эта комбинация станет роковой.
  • Давайте подождем месяцок-другой. Если ничего не изменится начнем действовать.
    Достаточно популярный выжидательный вариант. Чаще всего встречается в негибких компаниях, руководители которых понимают насколько сложно будет попытаться изменить движение этой махины. Решения в таких компаниях принимаются всегда запоздалые и сильно затянутые. Им проще выждать, чем это все перенастраивать.

Вернемся к вопросу незнания.
Вы ничего не знаете и делаете с этим незнанием что-то? Или ничего не знаете и праздно ожидаете развязки? Если первый вариант выйдите с ним в люди. Расскажите людям, что вы в процессе разработки стратегии, которая позволит компании остаться на плаву. И будете готовы озвучить всем эту стратегию тогда-то. Это уже будет хороший шаг! Как минимум люди поймут, что шанс есть еще и что их руководители работают над тем, чтобы рабочие места были сохранены.


2) Руководители не считают это важным.


Первый вариант: руководители просто не думают об этом. Раньше никогда подобная коммуникации не проводилась, нет такой практики. Да и времени сейчас нет на совещания: Работать нужно, а не совещаться!.
Работать нужно, но вместе с этим работа должна быть точной и эффективной. Люди должны понимать, какая ситуация сейчас, что их ждет завтра и куда мы бежим и почему. Это снимет страх и повысит точность выстрелов (правильных решений и действий).
Но, скажу больше. Состояние турбулентности, в котором находится компания во время кризиса, укорачивает период заряженности сотрудника. То есть, если вы провели мотивационную беседу с людьми, эффект такой мотивации будет в разы короче, чем в спокойное время. Поэтому, во время кризиса, время на коммуникацию должно выделяться в большем объеме, чем это было ранее! А если ранее не выделялось самое время начать.


Второй вариант: руководители считают, что стратегия это такой манускрипт, который могут трактовать, понимать и использовать только избранные. Что штатные люди настолько тупы, что не поймут: ни схем, ни цифр, ни терминологии. А раз так, зачем на это тратить время?
Все правильно. Стратегия, в ее исходном варианте, написана на языке достаточном для понимания верхней ланки руководителей (создателей стратегии). И в таком виде она, конечно, может быть непонятна штатным сотрудникам. При этом, стратегию же все равно нужно спускать вниз. Ибо как она по другому будет реализовываться? Можно, конечно, попробовать не доносить стратегию и реализовывать ее исключительно на ручном плотном управлении (через приказы), но это малоэффективный вариант. Стратегию нужно спускать вниз, и для этого документ должен быть переведен на такой язык, который будет доступен и понятен всем сотрудникам компании. А, что невозможно понятно описать нужно объяснить устно.


3) Руководители боятся, что люди негативно отреагируют.


Попросту говоря, руководители боятся, что люди услышав какое-то непопулярные решения начнут сопротивляться в его реализации. Начнут бунтовать, саботировать и увольняться.
Могут и будут :) Никогда не будет ситуации, когда все сотрудники спокойно примут неприятные для них новости. Но, вопрос в масштабах сопротивления. Если вы вообще не выйдете к людям, они все равно все додумают сами и этот их вариант будет еще страшнее выглядеть. Поэтому, я считаю, что, если даже в стратегии есть плохие новости их все равно нужно озвучить публично. Это, во-первых, действие сильного человека и руководителя не бояться и говорить все, как есть. Во-вторых, у вас же все равно есть вариант выхода из этой плохой ситуации. Правда? А если так, то вы его также озвучите и люди увидят: Да, есть проблемы. Но, компания знает, как с ними бороться и что для этого нужно делать. И есть план И есть сроки. Это выглядит сильно!


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


Рассматриваю ли я эту компанию как ту, в которой я планирую долго работать?


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


К вам в компанию приходят разные люди. Одни с самого начала настроены на режим от работы кони дохнут, а другие ищут плацдарм для старта своей карьеры. Но, вот вопрос: увидят ли они в вашей компании те нужные характеристики плацдарма, которые убедят их разделить большой кусок своей карьеры именно с вами? А это все стратегия. Даже если ваша компания маленькая, ваша стратегия, которая имеет амбициозные и реальные цели, убедит с вами работать хороших специалистов.
P.S. Развитие компании с нуля часто является драйвером для амбициозных.


Рассмотрим еще один пример. Есть молодой амбициозный человек, который только что закончил Университет. Он хорошо учился, во время учебы подрабатывал и имеет неплохие софт скилы. Сейчас он выбирает для себя компанию, в которой начнет свою карьеру. Он понимает, что на высокую позицию ему пока претендовать рано, так как нет, ни опыта, ни знаний, да и годков ему маловато. Он это понимает и готов начать с нуля. И вот, он попадает в вашу компанию и начинает работать. Проходит два месяца, и он прекрасно понимает, насколько долго он с вами. Как он делает этот выбор? На основе стратегии компании! Он сопоставляет перспективы развития компании со своими планами на карьеру. Если стратегия никакая либо ее нет он не будет рассматривать компанию, как такую, в которой можно долго работать и расти.


Итоги


Если у сотрудников нет информации о состоянии компании и ее будущем, они будут испытывать страх и будут переживать за свое будущее. Это касается, как кризисного периода (о котором я детально рассказал), так и спокойного.


image

.
Руководители, с достаточной для этого регулярностью, должны коммуницировать с сотрудниками о:


  • текущем состоянии компании;
  • успехах;
  • проблемах;
  • перспективах;
  • стратегии (изменениях в стратегии).

Как следствие: люди должны быть уверены, что у руля компании находятся профессионалы, которые прекрасно понимают, куда они ведут компанию, что им можно доверять, и, что с ними они будут в безопасности.


Лирическое отступление
Кризис 2020 я считаю полезным, в части того, как он повлиял на управление в компаниях. Компании пересмотрели свои бизнес-процессы, компании оптимизировались, компаниям пришлось разработать стратегию, компаниям пришлось пересмотреть отношение к бизнесу. Абсолютно все компании, которые остались на плаву, зашли в 2021 более подготовленными и более подтянутыми. Управленцы стали более профессиональны и более мудры.
Подобный опыт я приравниваю к выживанию в экстремальных условиях. Ведь, прохождение экстремальных испытаний, которые грозят ему смертью это опыт, который позволит ему будущем справляться с любыми трудностями. Опыт антикризисного управления. Он бесценен!


Продолжение серии и другие статьи о менеджменте находите в моем telegram-канале: https://t.me/OS_management
Подписывайтесь! Далее будет
.
.
.

Подробнее..

Экономим ресурсы и успеваем в срок зачем подключать QA-инженера в начале работы над фичей

19.02.2021 18:05:42 | Автор: admin

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

А в чем собственно проблема? Зачем тестировщику проявлять еще какие-нибудь качества помимо качеств мануального тестировщика?

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

Так зачем переделывать задачу и факапить сроки, если можно предотвратить большинство ошибок? Есть один вариант: QA-инженер. Специалист который будет влиять на качество процессов и продуктов на каждом этапе работы над фичей и служить связующим звеном между всеми этапами и подразделениями. В итоге вы получите качественный результат.

*Что мы подразумеваем под качественным результатом?

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

  2. Мы добились адекватного соотношения затраченных ресурсов и пользы, которую принесли бизнесу.

Чтобы прийти к качественному результату, нужно, чтобы QA участвовал на каждом этапе разработки фичи при:

  • поиске оптимального подхода к реализации функционала;

  • утверждении дизайна интерфейса;

  • выставлении сроков.

Почему этим связующим элементом гипотетически должен стать QA?

Приведем несколько аргументов:

  • У QA хорошо прокачаны софт-скиллы.

  • QA это адвокат пользователя в продуктовой команде, мост между продуктом и пользователем и самый частый пользователь в одном лице.

  • QA последний оплот перед релизом, поэтому именно в его интересах минимизировать количество недоработок на ранних этапах. Получается, чем больше багов он предотвратит на старте, тем легче будет его жизнь на финишной прямой, и, как следствие, дешевле обойдется разработка бизнесу.

  • Если этого всего недостаточно, есть еще один аргумент: QA достаточно хорошо знаком как с технической стороной продукта, так и с интерфейсной. Короче говоря, он может подружить аргументы программиста, дизайнера и менеджера, если они не будут матчиться.

Давайте рассмотрим гипотетический процесс, на каждом этапе которого, предположим, участвует QA.Ремарка: это состояние идеального газа. Конечно, может быть много вариаций, в зависимости от специфики продукта, структуры компании и много чего еще.

История разработки одной фичи

Шаг 1. Знакомство команды разработки с новой фичей

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

Зачастую это может поменять видение менеджера на то, как нужно решать проблему. Фича может приобрести совершенно другой вид.

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

Шаг 2. Обсуждение UX/UI-решения

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

Когда перед глазами у тестировщика есть UX/UI-решение, он может увидеть все белые пятна в пользовательских сценариях. Этот вклад QA позволяет выявить те места, где в будущем появятся дополнительные требования. Те самые "доп.требования", из-за которых часто сдвигаются сроки релиза. Надо зарелизить фичу в срок и минимизировать затраты бизнеса.

Будьте готовы к тому, что UX/UI-решение возможно придется переделать. Это может быть кнопка, текст на кнопке или вся фича целиком. Этап может повториться несколько раз, пока команда не придет к лучшему возможному решению.

Совет: Чтобы к QA начали прислушиваться, покажите пример улучшения фичи, которую сделали без QA на этом этапе и расскажите, что история могла сложиться иначе. Найдите, как можно улучшить какой-нибудь user story в какой-нибудь уже реализованной фиче или задаче, которую вы тестируете сейчас.

И еще один совет: разберите базовые вещи об UX/UI науке. Изучите простейшие критерии качественного интерфейса.

Шаг 3. Декомпозиция задачи и оценка сроков

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

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

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

Роль QA проговорить еще раз каждую подзадачу с разработчиком и пропустить все это через тест-кейсы и user story. Найти оставшиеся подводные камни. Отловить нотки неуверенности в голосе разработчика, которые показывают, достаточно ли изучили задачу, чтобы выставлять срок.

Также QA нужно определить глубину и объем затронутого новым функционалом кода, который предстоит тестировать перед релизом.

Часто на этом этапе приходят всякие озарения по саб-таскам, а сроки становятся более предсказуемыми. Бросать такую огромную работу на разработчика нечестно, и круто, если он это делает в паре с QA, который дополняет картину мира и смотрит с другого ракурса.

Совет: QA надо качать технические скилы, чтобы лучше понимать разработчиков и быть с ними на одной волне. И в целом не помешало бы выстраивать дружеские отношения с разработкой, чтобы было к кому обратиться за более глубокими разъяснениями о том, как работает фича под капотом.

Шаг 4. Обсуждение подводных камни и поиск компромиссов

Команде из QA и разработчика нужно рассказать менеджеру обо всех найденных технических проблемах. Например, если поняли, что функционал не удастся реализовать в том виде, в котором предлагают дизайнеры, или если на это потребуется гораздо больше времени, чем предполагалось. А потом уже всем вместе (разработчик, QA, менеджер и дизайнер) прийти к решению, как поступить в этой ситуации:

  • увеличить ресурсы, например, выделить больше времени или добавить разработчиков в команду;

  • упростить функционал;

  • ну, или смириться с реальностью.

Гипотетический результат от гипотетического внедрения этого подхода:

  1. Сроки становятся более предсказуемыми.

  2. Качество продукта повышается.

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

Ну и несколько тривиальных советов QA-специалисту, который хочет быть полезен на каждом этапе работы над фичей:

  • Знать идею продукта, фичи.

  • Иметь представление о пользователе.

  • Иметь понимание, что бизнес хочет от пользователя.

  • Иметь понимание, что пользователь хочет от продукта.

  • Иметь понятия об UX/UI.

  • Иметь базовое понимание в программировании.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru