Найти в Дзене
Дима Т

Как распределять роли в IT команде. Примеры.

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

Принцип уменьшения лишнего общения между членами команды:

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

Например хорошей коммуникации:
-Художник сам рисует и собирает интерфейс в приложении. Если он видит дублированный арт, то просто удаляет лишний.

Принцип сосредоточение компетенций, ответственности и возможностей в одних руках.

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

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