×
Фото 5 ролей разработчиков

5 ролей разработчиков

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

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

Итак, в Dota в одной команде 5 человек, теперь попытаемся извратить роли Dota, чтобы они начали подходить для разработки!

Итак, у нас 5 игроков и 3 линии:

Терминологию Dota не буду объяснять — просто поверьте, это не относится к сути.

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

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

В «сложной линии» стоит опытный игрок. Подцепить его — сложно, развести на что-то — почти не реально. Он давит свою линию — он чинит баги. Он знает 100500 вариантов, как баги могут попытаться проникнуть — он стоит на стрёме!

Следующая позиция — роумер. Он не находится на одной линии слишком долго: помог, ушёл в лес, вылез в другом месте — там помог. Более всего он  мне напоминает вездесущего devops или, говоря менее пафосно — инфраструктура его призвание! Забодали баги — держи автотесты, рефакторинг не в радость — держи код-анализатор, линтеры, фичи непонятные — держи очередную супер-пупер систему для [по факту] общения с заказчиком!

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

Конечно, это всего лишь глупая модель, которая навеяна какой-то командной игрой… Но стоп, ведь разработка у нас тоже нынче командная… Быть может оно работает?

P.S. Часто — да smiley

Будь первым – оставь комментарий!

Фото Ещё один миф: рекомендации не важны
Предыдущая запись:
Ещё один миф: рекомендации не важны
Фото Антипаттерн «Охота на ведьм», руководство к эксплуатации
Следующая запись:
Антипаттерн «Охота на ведьм», руководство к эксплуатации

Интересное на «Цифре»

Фото 5 причин не исправлять "ошибки"
5 причин не исправлять "ошибки"
Сразу оговорюсь, речь пойдёт не о критических ошибках. Если ваш сервис лежит бездыханный, то конечно — ноги в руки и фиксить.
"Чайка-менеджмент". Опасности и злоумышленники
Не так давно мы рассмотрели анти-паттерн “Чайка-менеджмент”, однако, совсем забыли рассмотреть опасности для такого менеджера
Фото «Методологическое безумие» и «Scrum»
«Методологическое безумие» и «Scrum»
Пока в Москве повальное увлечение методологией “скрам” меняется на “бирюзу”, в регионах так и продолжают внедрять “скрам”. Оба эти увлечения обычно не приводят ни к чему хорошему. В конце концов всё приходит к “у нас скрам, но не совсем” или “скрам — говно”
Противление методологиям как методология
Забавное нынче время. Попы освящают дата-центры, детям преподаётся креационизм, а в командах разработки появилось новое обзывательство: “теоретик”