Привязать к результатам вместо навыков никак?
А то бывают менеджеры, которые вроде всеми навыками обладают, а с проектами не могут справиться.
Ага, я про это же.
С играми бывает то же самое. Например, выпуститься надо самое позднее через год. Или надо игру спортировать на Switch, но при этом бюджет $0.5 млн и не больше. С такими ограничениями получается выпустить только сырой проект, с низким качеством. Если это «достаточно хорошо» с точки зрения бизнеса - ОК, пошли делать.
Приоритеты в треугольнике качество-сроки-бюджет ещё могут меняться в процессе работы над проектов, приходится менять планы.
Ну вот классический треугольник качество-сроки-бюджет - это про вот эту работу, на уровне управления проектом. А у вас в статье речь всё-таки про другое, что работать надо хорошо)
Как раз моя мысль в том, что не надо путать качество на уровне проекта и на уровне выполнения конкретных работ.
"Низкое качество - это дополнительные операции" - это про то, что работы делаются некачественно, а не про качество проекта.
Я из геймдева и честно говоря это довольно частая вещь, когда с точки зрения бизнеса выгодно выпускать некачественную игру, чтобы уложиться в бюджет или сроки. Это вообще ничего не говорит про качество самой разработки этой игры.
Про ревью UI - я в работаю в геймдеве уже лет 10, у нас 3 ревью UI это очень мало, обычно на сложный игровой UI нужно минимум с десяток итераций ревью :) Смысл не в том, сколько нужно этих итераций, а в том, что тут можно сэкономить на качестве, если так надо бизнесу.
В статье подмена понятий.
Очевидно, что чем больше качество работы конкретных сотрудников, тем лучше. Не имеет никакого смысла снижать качество конкретных работ.
Но при этом, треугольник качество-сроки-бюджет на уровне проекта вполне имеет место, и этим надо управлять.
В IT низкое качество это может значить, что мы не фиксим некоторые не самые важные баги, не оптимизируем время выполнения части операций программы, ревью UI делается 1 итерация вместо 3х, и т.д.
Спасибо за интересные статьи, Константин. Много важных мыслей почерпнул для своей карьеры!
Что касается этой статьи - я работаю в сфере разработки игр, где обратная связь от рынка по эффективности команд гораздо быстрее, 1 год для небольших проектов, 2-3 года для крупных ААА проектов. Увидев эту разницу, я стал лучше понимать многие особенности рынка труда в геймдеве и чем он отличается от остального IT.
Игры надо уметь не только делать, но и продавать. Это очень долгий и очень сложный путь.
Начните с того, чтобы выполнять на заказ какие-то части игр других студий. Потом можно будет с кем-то организовать совместную разработку игры. Потом уже поймёте, как тут всё устроено, заведёте нужные знакомства, и, если останется желание - то вперёд, делать свои игры.
FPS drops to 10 (это кошмар из геймдева)
Столкнулся с тем же. Нашёл решение в том, чтобы из джунов делать помощников опытных людей, которые уже сами отвечают за проекты/задачи. Джуны просто помогают, не хотят/не готовы отвечать за большее - и ладно.
Wheely не дороже Яндекса в 5 раз, а нелегалов там нет.
А с зарплатой больше 500к и кредитка "100 дней без %" тоже не выгодна :)
Антон Васильев
Интересно, что в моём опыте незаменимый сотрудник - это не про bus factor, а про эффективность его работы. Например, это программист, чтобы заменить которого, потребуется целая команда из 5 программистов, менеджер для них, пара тестеров, и ещё на отдельные задачи придётся привлекать сторонних экспертов.
Bus factor там сам собой образуется - никто не будет держать отдельную команду просто чтобы дублировать работу этого сотрудника.